ProxySU: a root SSH installer for Xray and Trojan, not a client

ProxySU installs over SSH as root, it does not proxy your own machine

The name suggests a proxy client. It is not one. ProxySU is a WPF desktop program, compiled with Visual Studio 2022, that connects to a remote host with SSH.NET and installs proxy software there. The installable set is V2ray, Xray, Trojan, Trojan-Go, NaiveProxy, Brook and related plugins, and the project description also names Shadowsocks, ShadowsocksR, Shadowsocks-libev and MTProto over TLS. The GUI is available in English, Simplified Chinese, Traditional Chinese and Persian, and BBR can be enabled in one click on CentOS 8, Debian 9 and 10, and Ubuntu 18.04 or above.

Have these in hand before the first run:

Microsoft .NET Framework 4.8 or higher
https://github.com/proxysu/ProxySU/releases
Debian 9/10/11/12
Ubuntu 18

The release page is the only source the project asks you to trust: it states that downloads from anywhere else carry no guarantee, that the source is open, and that no personal data is collected. The three libraries it uses are SSH.NET, Newtonsoft.Json and QRcoder, the last one for generating the client QR codes.

The OS floor is Debian 9 or Ubuntu 18, and older releases are declared unusable

Two distributions are supported, with a clear preference between them.

Debian 9/10/11/12
Ubuntu 18

Below that line the project does not negotiate. CentOS 7, Debian 8 and Ubuntu 16.04 are described as having a high failure rate on install, and anything older than those cannot use ProxySU at all. Debian 10 is the version it was tested against, on a Vultr VPS, and the documentation is explicit that the same Linux version from a different VPS provider or cloud service is not the same environment, which is why no exhaustive matrix exists.

Two more constraints sit in the same list. Memory of 256M or more is recommended, because a small machine leaves some proxy configurations unable to start. And the install flow assumes a clean system with no other proxy software already present, so a reused box is the most likely way to hit a failure.

There is no uninstall button, and the project explains why

A request to uninstall proxies installed by other methods was turned down, and the two reasons are worth quoting because they shape how you should use the tool. The first is that adding it invites disputes. The second is that a partial uninstall leaves the machine in a state where a later ProxySU install can itself fail. Cleaning up after someone else's installer is not something this project will do.

The practical consequence is a policy rather than a feature: first-time users are told to start on a fresh system, and if a proxy program was installed before, the advice is to reinstall the VPS operating system to avoid conflicts. That advice repeats in three separate places on the page, which is a fair signal of how often it matters.

One related habit is worth keeping: ProxySU installs the latest version of whichever proxy tool you pick, so the client side should be on a current version too, for compatibility.

NAT-type hosts and throttled VPS plans both fail before the proxy starts

The most common wall is not the proxy, it is the certificate. On a NAT-type VPS the host cannot take ports 80 and 443 exclusively, so a proxy running in TLS mode may fail to obtain a certificate and the install breaks at that point.

A second failure looks like a crash in Caddy. Some providers limit the resources a VPS may use, and the symptom is a startup error reading "failed to create new OS thread", which shows up often on free plans. The workaround the documentation gives is a change of proxy mode rather than a change of machine: leave the camouflage URL empty and the tool will not use web camouflage.

Both of these produce confusing errors, because in each case SSH login worked and the remote install started. The low-memory case is the same story with a different cause, and the 256M recommendation exists to keep it from happening.

The project asks for the failing log before it asks for anything else, and points at three places:

https://github.com/proxysu/windows/wiki/CommonError
https://github.com/proxysu/windows/issues
https://t.me/proxysuissues

A pure IPv6 host gets a temporary NAT64 gateway that is deleted after deployment

IPv6-only hosts are supported, with a mechanism and a warning attached. During installation ProxySU sets a NAT64 gateway temporarily, then removes it once the deployment finishes. If you configure a camouflage website, that site must be reachable over IPv6 or it does nothing.

The warning is the part to remember: a pure IPv6 host cannot reach pure IPv4 networks directly, which breaks a large part of the internet for anything running there. The project says so and recommends against using a pure IPv6 machine as a proxy node.

So the IPv6 support is real but narrow. It covers the setup path where the machine has no IPv4 address at all, and it handles the address translation for the install itself. It does not make an IPv6-only host a good general purpose proxy node, and the gateway does not survive: if a later step needs NAT64 again, it has to be set up again.

Key formats are capped by the SSH.NET library, not by your server

Login goes through SSH.NET, so the accepted key formats are the ones that library supports.

RSA in OpenSSL PEM and ssh.com format
DSA in OpenSSL PEM and ssh.com format
ECDSA 256/384/521 in OpenSSL PEM format
ECDSA 256/384/521, ED25519 and RSA in OpenSSH key format

A private key may be encrypted with one of these ciphers:

DES-EDE3-CBC
DES-EDE3-CFB
DES-CBC
AES-128-CBC
AES-192-CBC
AES-256-CBC

If your key is in another format, the documented route is puttygen, which converts it, with a walkthrough for that conversion on the project wiki. This is a client-side restriction: a server will happily accept a key that ProxySU cannot offer, so a key generated by a tool you like may still need converting.

Since the program logs in as root, a working key format is the first thing to sort out, before you pick a proxy at all.

Let's Encrypt rate limits explain most certificate failures, and a new domain is the fix

Certificates come from acme.sh and Caddy, free Let's Encrypt certificates that renew automatically every three months with nothing for the user to do. Renewal does not need you, but issuance does, and Let's Encrypt's limits are the reason a retry fails. The ones that bite here are specific: one main domain can take 50 certificates in a week, an account gets 5 failed validations per domain per hour, only 5 duplicate certificates can be created in a week, one account on one address can create 10 certificates every 3 hours, and a multi-domain SAN certificate holds at most 100 subdomains.

Renewals are not counted against a limit of their own, but they are still subject to the duplicate certificate rules. When an application fails, the documented move is to try a different domain, and adding or swapping a second-level domain counts as a different one. If the same address has been requesting certificates too often, changing the domain does not help: you wait, or you change IP.

There is a way around the whole system. Package your crt and key files into a zip and choose the upload your own certificate option in the install interface, and no Let's Encrypt request is made at all.

Editorial conclusion

ProxySU fits the case where you have a bare Debian or Ubuntu VPS, root SSH access and a willingness to let a graphical tool rewrite the machine: the installer fetches the latest proxy release itself, renews certificates through acme.sh and Caddy without help from you, and speaks four languages. It does not fit a host you care about, since it logs in as root and the documentation asks you not to point it at production machines, and it does not fit a machine that already carries another proxy installation, because the project declined to uninstall proxies installed by other methods and the documented answer is to reinstall the OS. Check three things before the first run: that your key format is one SSH.NET accepts, that your provider lets you hold ports 80 and 443 if you want TLS, and that the OS is Debian 9 or newer or Ubuntu 18 or newer. The newest tagged release is v4.3.0 from 2025-09-21 and the last push on master was 2026-08-12, so the tool is still changing under a MIT licence.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. proxysu/ProxySU on GitHub
4. README
5. Releases