ProxySU: A Windows WPF Tool That Deploys Xray and Trojan on a Fresh VPS

What ProxySU actually does, and who it is built for

ProxySU is a Windows desktop program, written in C# with a WPF interface, that turns a bare VPS into a proxy node. The README lists V2ray, Xray, Trojan, NaiveProxy, Trojan-Go, Brook, Shadowsocks and ShadowsocksR among the installable options, plus BBR acceleration on CentOS 8, Debian 9/10 and Ubuntu 18.04 or newer. It also supports IPv6-only hosts, where it temporarily sets a NAT64 gateway during deployment and removes it afterwards. The interface ships in English, Simplified Chinese, Traditional Chinese and Persian.

The intended user is someone with no shell experience. The README points beginners at the Xray project's own level-0 tutorial before they start, which is a fair signal about the assumed baseline. You supply the server IP, root credentials and a domain, choose a proxy type, and the program does the rest over SSH.

The scope is deliberately narrow: Windows only, since the build environment is Visual Studio 2022 and the UI is WPF. There is no Linux or macOS build of the tool itself, even though the machines it manages are Linux. The related searches include "Proxysu android", but nothing in the repository describes an Android client; the program is a Windows deployment utility, and the phone side is handled by separate client apps such as v2rayNG or Shadowrocket, which appear only as topic tags. That distinction matters when you are choosing where to spend your setup time: ProxySU is the server half of the problem, and it assumes you already have a client you like.

How the deployment works: SSH, root, and a fixed set of supported systems

The mechanism is remote command execution, not an agent. ProxySU calls the SSH.NET library to log into the target host, and the README is explicit that it uses the root account for deployment convenience. Everything the program does on the server happens through that session, which is why the README warns against running it on hosts that carry important or production workloads.

The supported server operating systems are Debian 9, 10, 11 and 12, with 10 or newer recommended, and Ubuntu 18 and above. The README states that CentOS 7, Debian 8 and Ubuntu 16.04 fail often enough that they are not recommended, and anything older cannot be used at all. That is a narrower matrix than the tag list suggests, and it is worth reading the tag list as aspiration rather than support.

Certificate handling is delegated to acme.sh and Caddy, both of which request free Let's Encrypt certificates. Renewal is described as automatic, with no user action required. If you already hold a certificate, the program accepts an uploaded one: you package the crt and key files into a zip and select the upload option in the install dialog.

There is no rollback path. The README explains that an uninstall feature for proxies installed by other means was considered and rejected, on the grounds that it invites disputes and rarely cleans up completely. The practical consequence is that ProxySU expects a system it installed itself, and the README recommends reinstalling the OS if a previous proxy setup exists. For anyone used to configuration management tools with idempotent apply and destroy steps, this is a meaningful gap, not a missing convenience.

Installing ProxySU on Windows and running a first deployment

ProxySU ships as a compiled Windows executable. There is no package manager entry and no source build described for end users; the README directs you to the releases page for the official build and warns that copies obtained elsewhere carry no guarantee.

The only prerequisite is the .NET Framework. The README states version 4.8 or higher is required.

# Download the current release from the official releases page:
# https://github.com/proxysu/ProxySU/releases
# Then install .NET Framework 4.8 or higher before launching it.

Once the program is running, the flow is a form. You enter the server address and root credentials, choose a proxy type, and optionally supply a domain for TLS and a camouflage site for web disguise. If you use key authentication instead of a password, the key must be in a format SSH.NET accepts: RSA or DSA in OpenSSL PEM or ssh.com format, ECDSA 256/384/521 in OpenSSL PEM format, or ECDSA, ED25519 and RSA in OpenSSH key format. Encrypted keys may use DES-EDE3-CBC, DES-EDE3-CFB, DES-CBC, AES-128-CBC, AES-192-CBC or AES-256-CBC. The README suggests puttygen for converting anything else, and links a wiki page describing the conversion.

# After deployment, the program shows connection details and a QR code
# for the chosen client. The README advises keeping the client on the
# latest version to match the server-side proxy version just installed.

The README notes that ProxySU installs the latest release of the chosen proxy, so an outdated client is a common source of mismatch. For a first run, use a freshly reinstalled Debian 10 or newer server with at least 256 MB of RAM, which the README gives as the recommended minimum. Expect the first attempt to be the one that matters: if it fails, the documented recovery is to reinstall the operating system and try again, possibly on a different distribution.

Where ProxySU breaks: memory limits, NAT hosts and certificate quotas

The failure modes are documented, and they cluster around the server environment rather than the program.

Low memory is the first. The README recommends 256 MB or more, and states that lower configurations may prevent some proxy schemes from running at all. On a 128 MB container, the install may complete and the service may still refuse to stay up.

Resource-limited VPS providers are the second. On some free tiers, Caddy fails to start with a "failed to create new OS thread" error. The README's workaround is to switch to a proxy mode that does not use web camouflage, which in practice means leaving the camouflage URL field empty. That trades away the traffic disguise for a working node.

NAT-type VPS hosts are the third, and this one is structural. If the host cannot exclusively bind ports 80 and 443, TLS-mode proxies may be unable to obtain a certificate and the installation fails. No setting in the program fixes that; it is a property of the network you bought, and the only remedy is a different host.

Let's Encrypt rate limits are the fourth. The README lists them: 50 certificates per registered domain per week, 5 failed validation attempts per account per hostname per hour, 5 duplicate certificates per week, 10 certificates per account per IP address per 3 hours, and a maximum of 100 subdomains per SAN certificate. Renewals are not capped but still count against the duplicate limit. If issuance fails, the suggested remedy is to change the domain, and if the IP itself is throttled, to wait or change IP.

Pure IPv6 hosts deserve a separate warning. The README states that such a host cannot reach IPv4-only networks directly, that any camouflage site must itself be reachable over IPv6, and that IPv6-only servers are not recommended as proxy nodes at all. The NAT64 gateway is set only for the duration of deployment and deleted afterwards, so it does not rescue you at runtime.

ProxySU versus doing it yourself with Xray and acme.sh

The honest alternative is not another GUI. It is the manual path the README itself points beginners toward: the Xray project's own tutorials, where you install the core, write a JSON config, and run acme.sh or Caddy yourself for certificates.

The difference is where the knowledge lives. ProxySU encodes the deployment steps in a Windows binary and applies them over SSH in one pass. The manual path leaves you with a config file you wrote, a certificate renewal you can inspect, and an upgrade procedure you control. When something breaks on a ProxySU-managed host, your first move is to read the install log and ask in the issue tracker or the Telegram group, because the program's state is not something you assembled. When something breaks on a hand-built host, you already know which file to open.

There is a second difference in upgrade behaviour. ProxySU installs the latest version of the proxy at deploy time, and the README asks you to keep clients current to match. A manual install lets you pin a version and upgrade on your own schedule. Neither is wrong, but they suit different operators, and the manual path is the one that scales past a handful of nodes.

A third option, common in the related searches, is a server-side panel such as Remnawave that manages users and subscriptions from the host itself. That is a different product category: ProxySU configures one machine for one operator, and does not manage multiple users, subscription links or a web dashboard. If your goal is handing out access to other people, ProxySU is the wrong layer entirely.

Maintenance, licence and the cost of upgrading

The repository is not archived, and the last push was on 2026-08-12. Releases are irregular: v4.1.11 in November 2023, v4.2.0 in June 2025, and v4.3.0 in September 2025. That cadence matters if you depend on the program tracking upstream proxy changes, because the proxies it installs move faster than the installer does. A gap of more than a year between v4.1.11 and v4.2.0 is the pattern to expect, not an exception.

Upgrade cost is low on the client side and undefined on the server side. The program itself is a single executable you replace from the releases page. What the README does not document is an in-place upgrade path for an already-deployed proxy: the install flow assumes a clean system, and the recommended remedy for a conflicted host is to reinstall the OS and start over. If you have data or other services on that machine, that is a real cost, and it is the strongest argument for running ProxySU only against disposable nodes.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is a permissive licence with minimal obligations, but it says nothing about the legal status of proxy operation in your jurisdiction, and the README carries its own disclaimer leaving consequences with the user. Nothing here is legal advice; if you plan to run this commercially, the licensing question and the regulatory question are separate and the second one is not answered by the MIT text. The README also notes the program collects no personal data and that builds from outside the project page carry no guarantee.

What to check before you commit a server to ProxySU

Start with the host, not the program. Confirm the distribution is Debian 9 through 12 or Ubuntu 18 or newer, and that it has at least 256 MB of RAM. Check whether the provider assigns a NAT address, because if ports 80 and 443 are shared, TLS modes will fail at certificate issuance.

If the server is IPv6-only, read the README's caveats again before proceeding: the NAT64 gateway is temporary, the camouflage site must be IPv6-reachable, and IPv6-only nodes are explicitly not recommended.

Check your SSH key format against the SSH.NET list before you start, and convert it with puttygen if it does not match. A key in the wrong format fails at login, before any deployment work begins, which is the cheapest failure to hit and the easiest to avoid.

Then decide what you are willing to lose, because the recommended recovery from a failed or conflicted install is a fresh operating system. A cheap throwaway VPS is the right target; a machine running anything you care about is not, and the README says so directly when it warns against using the program on hosts running important or production services. If you cannot reinstall the server without consequences, the manual Xray path is the better starting point.

Editorial conclusion

ProxySU fits users who want a proxy node running on a fresh Debian 10+ or Ubuntu 18+ VPS and do not want to type shell commands. It does not fit anyone running services on the target host, since the program logs in as root and assumes nothing else is installed. Before adopting it, confirm your VPS is not NAT-restricted so ports 80 and 443 are free for certificate issuance, and check that your private key format is one SSH.NET accepts.

Frequently asked questions

Official sources

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