# cmliu/WorkerVless2sub: a Cloudflare Workers subscription generator for VMess, VLESS and Trojan nodes > WorkerVless2sub rewrites a single upstream node into many Cloudflare-optimised endpoints and serves the result as a subscription. It is a small, single-file JavaScript worker aimed at people who already run a VLESS or Trojan tunnel behind Cloudflare. **cmliu/WorkerVless2sub** — 自动化批量替换生成优选线路 VMess / VLESS / Trojan 节点的 优选订阅生成器 - Repository: https://github.com/cmliu/WorkerVless2sub - Website: https://VLESS.fxxk.dedyn.io - Stars: 6,257 · Forks: 7,639 - Language: JavaScript - License: Apache-2.0 - Published: 2026-09-22 · Updated: 2026-09-22 · Language: en - Canonical page: https://hysenlabs.com/projects/cmliu-workervless2sub ## What WorkerVless2sub solves for people running a tunnel behind Cloudflare A single VLESS or Trojan endpoint on a Cloudflare edge is fragile. The hostname behind the tunnel resolves to addresses that vary in quality by carrier and by hour, and a client that hardcodes one address stops working the moment that address degrades. WorkerVless2sub takes one upstream node definition and emits a subscription containing that same node repeated across a list of candidate Cloudflare addresses and preferred domains. The client then picks among them on its own. The project describes itself as an automated batch replacement generator for preferred-line VMess, VLESS and Trojan nodes, built on Cloudflare Workers. The audience is narrow and specific: someone who already has a working tunnel (the README's examples reference edgetunnel-style Pages deployments and a Trojan host), understands what a WebSocket path and a camouflage host are, and wants the address list maintained centrally rather than in each client. It is not a proxy, not a tunnel, and not a subscription host that stores credentials for you. It is a rewriter that sits between your node and your client. ## How the worker turns one node into a subscription The repository is a single JavaScript entry point, _worker.js, plus a wrangler.toml and three sample address files: addressesapi.txt, addressesipv6api.txt and addressescsv.csv. There is no build step and no dependency tree to audit. The data flow has three inputs. First, node identity: HOST, UUID or PASSWORD, PATH, and optionally SNI, TYPE, ALPN and SCV. Second, candidate addresses, which arrive from three places. The ADD and ADDNOTLS variables hold static entries written inline, in the form host:port#alias, defaulting to 443 for TLS and 80 for non-TLS. ADDAPI and ADDNOTLSAPI point at plain-text files of addresses, one per line. ADDCSV points at an iptest speed-test result in CSV form, and the DLS variable sets a numeric floor: addresses scoring below it are dropped. Third, output format, selected by the format query parameter, which the README documents as clash and singbox. At request time the worker reads the configured address sources, filters the CSV entries against DLS, and generates one outbound entry per surviving address, each carrying the same UUID or password and path. The result is serialised as a subscription. The README notes that HOST accepts multiple values separated by commas or newlines, and that a client gets one of them at random per subscription fetch. ## Deploying WorkerVless2sub and requesting a first subscription There are two deployment routes. The Pages route forks the repository, connects it to Cloudflare Pages through the Git integration, then binds a custom subdomain such as sub.example.com with a CNAME to WorkerVless2sub.pages.dev. The Workers route is shorter: create a Worker in the Cloudflare dashboard and paste the contents of _worker.js into the editor. The README links a video walkthrough for each. Either way, the minimum viable configuration is a TOKEN, a HOST and a UUID. With TOKEN set to auto, the subscription lives at /auto on your deployment domain: ```url https://sub.cmliussss.workers.dev/auto ``` The README says the response is the default node subscription. If the body is empty or the request 404s, the TOKEN value and the deployment domain are the first two things to check, since the path is derived from TOKEN rather than fixed. For a node you do not want to bake into variables, the manual form takes the parameters in the query string. This is the documented VLESS example, with host, uuid, path, sni and type all supplied inline: ```url https://sub.cmliussss.workers.dev/sub?host=edgetunnel-2z2.pages.dev&uuid=30e9c5c8-ed28-4cd9-b008-dc67277f8b02&path=/?ed=2560&sni=www.10068.cn&type=splithttp ``` Two things about this URL are easy to get wrong. The path must contain /sub, and the path parameter itself is a URL fragment that needs its own escaping when it contains a query string. The README does not spell out the escaping rules. To get a client-ready config rather than the default list, append format. The README gives both clash and singbox as accepted values: ```url https://sub.cmliussss.workers.dev/auto?format=clash https://sub.cmliussss.workers.dev/auto?format=singbox ``` Finally, the address pool. Static entries go in ADD; dynamic lists go in ADDAPI as a URL to a text file. The README recommends static entries only for preferred domains, and points address changes at ADDAPI instead, which is the right split: a domain in ADD is stable, an IP list is not. ## The public-service warning is the project's sharpest constraint The README carries a warning at the top: this is a public-benefit project, and private nodes should not be placed in the LINK variable, because doing so makes the node available to everyone. That is not boilerplate. A subscription URL is unauthenticated by default, and TOKEN is a path segment, not a secret in any meaningful sense once the URL is shared or logged. If your threat model includes keeping an endpoint to yourself, this is the wrong tool, and the README says so before it says anything else. The second limitation is the address pipeline itself. ADDCSV filtering by DLS compares a bare number and ignores units, which the README states explicitly: it looks only at the numeric value, so you have to know what your speed-test output is measured in and pick DLS accordingly. A DLS set too high silently empties the pool. Nothing in the README describes a health check on the generated entries, so a subscription can be served successfully while every address in it is dead. There is also no documented rollback path for a bad variable change; recovery means editing the variable back. Finally, the project is a rewriter, not a tunnel. If the upstream node is down, WorkerVless2sub will faithfully generate a subscription full of endpoints that do not connect. ## Where it sits next to CloudflareSpeedTest and plain hand-written subscriptions The most direct alternative is a hand-maintained subscription file: you run a speed test yourself, pick addresses, and paste them into your client. That gives you full control and no third-party deployment, but every refresh is manual, and the file has to be updated per client. The other common approach is CloudflareSpeedTest, which the related searches associate with this project. The two are complementary rather than competing. CloudflareSpeedTest measures latency and speed from your own network and produces a result file; WorkerVless2sub consumes that kind of output through ADDCSV and turns it into a subscription. The difference in approach is where the work happens: CloudflareSpeedTest answers which addresses are fast for you right now, while WorkerVless2sub answers how to distribute whatever address list you have across clients as a subscription. Running the speed test on a schedule and pointing ADDCSV at its output is the combination the CSV variable exists to support. A third option is a managed subscription service. Those remove the deployment entirely, at the cost of handing your node credentials to someone else, which is precisely the arrangement the README's warning argues against. ## Maintenance, licence and what upgrading actually costs The repository is not archived, and its last push was on 2026-09-11. There are no retrieved releases, so the project appears to be distributed as a moving main branch rather than versioned artifacts. In practice that means two different upgrade stories depending on your deployment route. A Pages deployment connected to a forked repository updates when you sync the fork. A Worker deployment holds a pasted copy of _worker.js, and that copy does not update itself: you have to paste the new file over the old one. Neither route gives you a version number to pin, which makes it hard to tell which revision a deployment is running. Licensing is Apache-2.0, which permits commercial use and modification and requires that the licence and notice be preserved and that modified files carry prominent change notices. The repository ships a LICENSE file at the top level. Nothing here is legal advice; if you plan to redistribute a modified worker, read the licence text rather than this summary. The operational cost is mostly in the address sources. If ADDAPI points at a third-party list, that list becomes a dependency you do not control, and its failure mode is a subscription that loads and does not connect. Preferring your own hosted address file, as the README suggests when it says you can build one following the addressesapi.txt format, removes that dependency. ## Conclusion Adopt it if you already run a VLESS or Trojan tunnel behind Cloudflare and want a subscription URL that rotates through candidate IPs and domains without editing client configs by hand. Do not adopt it as a way to hide a private node: the README states plainly that anything placed in the LINK variable is visible to everyone using the deployment. Before pointing a client at it, verify that your TOKEN path returns a subscription and that your ADD, ADDAPI or ADDCSV sources actually resolve, because a broken address list produces a subscription that still loads but carries no working endpoints. ## FAQ ### Is WorkerVless2sub free to use, and can I put my private node in it? The README describes it as a public-benefit project and warns against placing private nodes in the LINK variable, because that would make the node available to everyone using the deployment. Treat the subscription URL as public. ### What do I need before deploying WorkerVless2sub? A Cloudflare account, a working VLESS or Trojan node with a camouflage host and path, and either a forked repository connected to Cloudflare Pages or a Worker with the contents of _worker.js pasted in. At minimum you set TOKEN, HOST and UUID. ### How do I get a clash or singbox config from WorkerVless2sub? Append the format parameter to the subscription URL. The README documents format=clash and format=singbox, and shows them applied to both the /auto and /sub endpoints. ### Why does the generated subscription contain addresses that do not connect? The worker generates entries from whatever address sources are configured and the README does not document a health check on the output. If an ADDAPI list or an ADDCSV file has gone stale, the subscription still serves successfully with dead endpoints. ### What does the DLS variable do in WorkerVless2sub? DLS sets the minimum speed an entry from the ADDCSV file must reach to be included in the subscription. The README notes it compares only the numeric value and ignores units, so you have to match it to your own speed-test output. ## Sources - [cmliu/WorkerVless2sub on GitHub](https://github.com/cmliu/WorkerVless2sub) - [Issues](https://github.com/cmliu/WorkerVless2sub/issues) - [License: Apache-2.0](https://github.com/cmliu/WorkerVless2sub/blob/main/LICENSE) - [Project website](https://VLESS.fxxk.dedyn.io) - [README](https://github.com/cmliu/WorkerVless2sub/blob/main/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/cmliu-workervless2sub