Cloudflare-vless-trojan deploys two different proxies, and publishes the default credentials

One README covering two deployments that share no configuration

The repository holds two separate things, and the README splits them into two numbered deployment methods.

The first is a proxy script for Cloudflare Workers and Pages, carrying the README's own version marker V2026.9. It speaks VLESS over WebSocket and Trojan over WebSocket with TLS, and the Workers method (custom domain only) also offers both without TLS. Its entire configuration is a set of Cloudflare environment variables. The README is explicit that every value is edited locally and that no subscription service or subscription converter is involved, which is the stated reason for its claim that node details are not visible to whoever operates such a third party.

The second is a local SOCKS5 and HTTP proxy script, meant for a machine you control such as a soft router. It is a different artifact with its own variable names, its own install line, and its own three transport modes.

The directory layout keeps the two apart:

Vless_workers_pages/
Trojan_workers_pages/
cf/
locations.json
s5http_wkpgs/

Three metadata signals sit awkwardly against each other. The README declares V2026.9. The repository's only release is named `serv00` and is dated 2024-12-12. The last push to the default branch is 2026-09-20. So the documented version string and the published tag are different things. The licence field is empty in the repository metadata as well, which leaves redistribution on an unclear footing.

The default uuid and password are printed in the README

Both node types arrive with a credential in the variable table, and both defaults are the same string for every reader.

For the VLESS node the `uuid` variable's default is `86c50e3a-5b87-49dd-bd20-03c7f2735e40`. For the Trojan node the `pswd` variable's default is `trojan`. Both are marked recommended rather than required, which in practice means a deployment can proceed without touching them.

The consequence is direct. A credential printed in a public README is not a secret, so a deployment that keeps the default hands the value to anyone who has read the same page.

This is less a criticism of the script than of what defaults mean inside a copy-paste workflow. The README is explicit that its configuration is all local editing, with no subscription aggregator in the middle, and that framing has a real privacy benefit: there is no third party holding a copy of your node list. The same minimalism cuts the other way on the credential itself. The script's own pitch is that after clicking the deploy button in Cloudflare you can build a node by hand or use a share link, having set at most one uuid or password and nothing else. That is genuinely low setup cost, and it also makes the single most important value in the deployment the one most likely to be left alone.

If you deploy this, set the uuid or password before generating any share link.

Thirteen IP slots, each locked to one port series

The subscription half of the configuration is thirteen paired variables, `ip1` through `ip13` and `pt1` through `pt13`, and the rules tying them together are positional rather than descriptive.

Slots 1 through 7, with `pt1` through `pt7`, accept only the 80-series ports with TLS switched off. Slots 8 through 13, with `pt8` through `pt13`, accept only the 443-series ports with TLS switched on. The split is a constraint rather than a preference: the variable name carries the mode, not the value you put in it.

The permitted numbers are given as two lists. The 80-series set is 80, 8080, 8880, 2052, 2082, 2086 and 2095. The 443-series set is 443, 2053, 2083, 2087, 2096 and 8443.

The README also narrows when any of this is needed. These twenty-six variables matter only when you are using a subscription-style client and want to change the optimised IPs; otherwise it says to ignore them and keep the defaults, which already cover thirteen standard Cloudflare ports. That is a fair amount of guidance for a beginner-oriented script, but the trap for anyone hand-editing the pairs is that moving an address from the `ip1` group into the `ip8` group silently changes its TLS behaviour, because the slot decides. A subscription assembled from the wrong pairing hands a client a node that does not match the server configuration.

A /pyip= path quietly overrides the global proxyip for one node

`proxyip` is the variable that decides where a node connects out to, and the script ships with one built in. You can replace it either globally through the `proxyip` variable or per node through a path segment.

The path form is a `/pyip=` prefix followed by an address, where IPv6 goes in brackets and a domain name occupies the same position. When the port is 443 the `:port` part may be left off. The keyword that triggers this behaviour is:

/pyip=

Three rules decide precedence, and they are worth reading twice. A `proxyip` set on a single node's path affects only that node, leaving other single nodes and the subscription nodes alone. A change to the global `proxyip` affects every node that has no path-level value of its own. And when a node's path contains that keyword, the global value stops applying to it entirely.

The consequence is two independent layers of the same setting, where the layer actually in force is not visible from the variable list. If a node behaves differently from its neighbours right after a global change, the likely reason is that its path carries its own value and silently insulated it. Settling that means reading the generated link for the specific node rather than the environment variables, since the variables alone will show you a value that was never consulted.

trojan+ws does not work on four of the clients it lists

The Workers deployment advertises four node shapes: vless+ws+tls, trojan+ws+tls, vless+ws, and trojan+ws. A compatibility warning then qualifies two of them.

Shadowrocket, v2box, v2rayn and v2rayng all force TLS on for trojan+ws, and the stated result is that trojan+ws stops working. Separately, a Clash subscription produced by the script contains no trojan+ws nodes at all.

So the two plaintext shapes are the ones with holes, and the holes are client-specific. The usable node list therefore depends on the client and not only on the server. Someone generating a trojan+ws share link and importing it into v2rayN gets a node the client forces into TLS and that will not connect, and the link itself carries nothing that says why.

The client list the README endorses covers Android with v2rayNG, NekoBox, Karing, clash/mihomo and sing-box builds; Windows with v2rayN, Hiddify, Karing, clash/mihomo and sing-box; iOS with Karing, Hiddify Proxy and VPN, Shadowrocket and Streisand; and soft routers with passwall, ssr-plus and homeproxy. Note that three of the clients named in the breakage warning also appear on that list. That is not a contradiction: the TLS shapes work there, the plaintext trojan+ws shape does not.

A related client-side switch applies to the TLS shapes. Enabling Fragment lets a walled domain carry a TLS node, while a custom or pages domain that is not itself TLS-blocked needs no Fragment at all.

The IPv4 address behind proxyip is one strangers are scanning for

The guidance on choosing your own `proxyip` is the most cautionary passage in the document, and it argues against the obvious default.

It recommends a pure IPv6 VPS that sits close to China, is cheap, and has generous traffic. It then tells you to avoid IPv4 where you can, on the grounds that an IPv4 address will probably be found by other people scanning for reverse-proxy IPs, who then fold it into a free or paid pool of their own. If you do use IPv4, it says to watch the VPS's traffic, because both the `proxyip` and the client's optimised IP consume that traffic.

The consequence is that a hand-built IPv4 `proxyip` is not private by default. It is an address on a machine other people are actively looking for, and the README treats that as the normal case rather than an edge case. It also means the traffic cost is not only what you send yourself, since every client resolving through the same `proxyip` spends it too, which is what makes the monitoring advice part of the setup rather than an afterthought.

Two lookup sites are offered as the diagnostic. Asking whatismyip.com shows Cloudflare's own 104.28 and 2a09 addresses, while asking ip.sb shows the `proxyip` address instead. The gap between those two answers is how you confirm which hop a connection is leaving from, and the README states that whether the `proxyip` is valid decides whether Cloudflare-hosted destinations are reachable at all.

The SOCKS5 script's mode decides which hostname you may point it at

The second half of the repository is a local SOCKS5 and HTTP proxy, installable from a one-line shell command or as the `ygkkk/cfsh` Docker image.

curl -sSL https://raw.githubusercontent.com/yonggekkk/Cloudflare_vless_trojan/main/s5http_wkpgs/cfsh.sh -o cfsh.sh && chmod +x cfsh.sh && bash cfsh.sh

It exposes eight variables, of which only one is required:

cf_domain
token
client_ip
cf_cdnip
pyip
dns
enable_ech
cnrule

`cf_domain` must be a workers, pages, or custom domain together with a 443-series or 80-series port, and it has no default. `client_ip` is the local listening port, any value from 10000 to 65000, defaulting to 30000. `dns` sets a DNS-over-HTTPS endpoint and defaults to `dns.alidns.com/dns-query`. `cnrule` chooses between splitting domestic and overseas traffic and proxying everything, defaulting to the split. `enable_ech` takes a plain y or n.

The three modes are the part with teeth, because the mode constrains the hostname and not merely the encryption. ECH-TLS accepts a workers, pages, or custom domain on a 443-series port with `enable_ech` set to y. Plain TLS accepts a pages or custom domain on a 443-series port with `enable_ech` set to n, which rules out a workers domain. No TLS accepts a workers domain on an 80-series port, with `enable_ech` either way.

Read as a compatibility matrix rather than a preference list, that table has an empty cell. Someone who deploys to a workers domain and then picks plain TLS has no valid setting, because no row meets. And with `enable_ech` as a single on-or-off variable there is no third state between an encrypted client hello and none.

Editorial conclusion

Cloudflare-vless-trojan fits someone who wants a VLESS or Trojan endpoint on Cloudflare Workers or Pages and is willing to treat the deployment as disposable configuration rather than durable infrastructure, because the whole server side asks for one credential and nothing else. It fits badly if you need a node you can hand to any client, since trojan+ws does not work in v2rayN, v2rayng, v2box, or Shadowrocket, and a Clash subscription omits that shape entirely. Before deploying, replace the default uuid or pswd value printed in the README with your own, then confirm which of the three SOCKS5 modes matches the hostname you actually hold, because plain TLS has no valid row for a workers domain at all.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. yonggekkk/Cloudflare-vless-trojan on GitHub