am-cf-tunnel: a single Worker file that turns into a proxy subscription

One Worker file produces node configurations and a login page

The repository has almost no code in the conventional sense. The tree lists `_worker.js`, `_worker.js.zip`, `snippets.js` and an `example/` directory of text files, plus `.github/`, `.gitignore`, `LICENSE` and `README.md`. There is no `package.json`, no build step and no test suite, which tells you the deployment model: you paste a file into the Cloudflare dashboard and the platform runs it.

The functionality is described in the repository description, which is written in Chinese, as a modification of an earlier project where the generated VLESS and Trojan configuration is rendered as subscription content rather than as a single shareable link. The practical difference matters. A raw configuration link has to be pasted into a client by hand and breaks when a field changes. A subscription URL is fetched periodically by Clash, sing-box, Quantumult X or v2rayNG, so the client re-reads the configuration each time and picks up changes without the user doing anything.

The topics on the repository name the clients directly: `clash`, `openclash`, `quantumult-x`, `sing-box`, `trojan`, `v2ray` and `vless`. That list is the project's real target audience, and it is a list of mobile and desktop proxy clients rather than of developers.

Three deployment routes, and the README ranks them for you

The README documents three ways to get the script running on Cloudflare, and it labels each one. The Pages drag and drop route is marked as the best recommended option, the Workers paste route is documented without that label, and the Git integration route is marked as not recommended.

For the Workers route you create a Worker from the Hello World template, optionally create a Workers KV namespace, open the code editor and paste the contents of `_worker.js` from the repository. For the Pages route you download `_worker.js.zip` and drag it onto the Pages upload form. For the Git route you fork the repository on GitHub and let Pages import it.

The difference between the first two is the deployment surface rather than the script. Pages serves static assets from a drag and drop upload, which means no build pipeline is needed at all. The Git route would normally trigger a build, and since there is no build configuration in the repository, that is presumably why it carries the not recommended label.

What all three routes have in common is the verification step, which is the same for each. You visit the URL, you get a login page, and you enter the UUID as the password:

curl https://vless.amclubss.com

A successful login is the project's definition of a working deployment. The example hostname in the README is a subdomain of the author's own domain, so the URL you use will be one you bind yourself.

The KV namespace binding and the UUID that ships with the script

Storage is optional per the README, and the recommended arrangement is a Workers KV namespace bound under a variable name that cannot be changed. The instruction is that the variable name must be `amclubs`, and the README states it is fixed. That constraint tells you the worker code reads `env.amclubs`, and renaming the binding will break it.

The second thing the KV store holds is the UUID that acts as the login password, and here the README's advice matters more than usual. A single default UUID is published in the documentation for every deployment, and the README calls changing it recommended, with the stated reason being to stop other people from using your node. The default value is:

ec872d8f-72b0-4a04-b612-0327d85e18ed

If you deploy and skip this step, the first person to read the README has your node's login credential. The change itself takes a few clicks: log in with the default, open the ID field on the logged in page, paste a new UUID and save, after which the original value stops working.

Ports are the other constraint worth understanding before you start. The README lists the Cloudflare ports that work, split into two groups: 80, 8080, 8880, 2052, 2082, 2086 and 2095 on the HTTP side, and 443, 2053, 2083, 2087, 2096 and 8443 on the HTTPS side. Ports outside those sets are the reason the video tutorials spend time on IP selection.

Where the subscription itself comes from

The node configurations are produced by a separate piece of software, and the README is explicit about it. Deployment of that part happens in the `am-cf-tunnel-sub` project, deployed and used according to its own instructions. If you already have that running, this step can be skipped.

If you do not, the README points at the author's hosted conversion endpoint. Both are published as URLs:

https://sub.amclubss.com
https://amclubss.com

This is the part of the design that deserves an explicit decision. Using the hosted endpoint means your subscription is generated by infrastructure you do not control, serving a conversion of configurations you do not control, from a project whose maintenance status you cannot see. Deploying `am-cf-tunnel-sub` yourself removes that dependency and adds a second thing to run and secure.

The README also links a separate sibling project for automatic IP selection, described as having Windows desktop, Linux and OpenWrt, Mac, Android and Docker builds. That is a different concern from this repository. Here you are publishing node configurations; there you are picking which Cloudflare IP or fronting address the client connects to, which is the step the port restrictions above feed into.

A repository that is mostly instructions

Roughly seven thousand characters of README describe the deployment, and almost all of it is Chinese. Steps are written as click paths through the Cloudflare dashboard, with menu names and button labels, and each block of steps links to a YouTube video with a timestamp pointing at the relevant section. The channel is the project's real documentation site, and the repository homepage field points at the YouTube channel rather than at a documentation host.

The release notes follow the same pattern. v3.0.0, published on 2026-09-19, has a body that says the new version supports the latest Cloudflare specification and then lists video tutorials for deploying VLESS and Trojan as snippets, the blog documentation address, a Telegram group and the subscription project. v2.4.0, published on 2026-03-06, mentions optimising node performance, compatibility with Android subscription clients and a fix for connection problems with the latest v2rayNG. v2.5.0, published on 2026-09-19, has an empty body.

So the version history records what changed for users, not what changed for code, and there is no changelog beyond these notes. The repository is not archived and the last push was on 2026-09-19, the same day as both recent releases. License is Apache-2.0, which for a deployment target rather than a library matters less than it would for something you vendor into a product.

Why this is not cloudflared

The name invites a comparison that does not hold. A reader searching for a Cloudflare tunnel almost certainly wants cloudflared, which is Cloudflare's own daemon for exposing local services over an outbound connection without opening inbound ports. It installs on your machine or server, runs as a process, and you point it at a local address.

am-cf-tunnel has nothing in common with that. It is a Cloudflare Worker, which means it runs on Cloudflare's edge rather than on your host, and what it publishes is proxy node configurations rather than access to a local service. It also has no daemon, no install step and no ingress configuration. The overlap is the word tunnel and the fact that Cloudflare is involved.

There is a third category worth separating from both. Running your own proxy on a VPS you control is the straightforward option if you have one, because nothing depends on a third party script, a shared default credential or somebody else's subscription endpoint. am-cf-tunnel exists for the case where you want the free tier and no server, which is a real constraint for a lot of people, and the trade it makes is control for convenience.

Editorial conclusion

am-cf-tunnel is best read as a working, well documented deployment recipe rather than a library. Everything interesting happens in `_worker.js` and `snippets.js`, both of which you paste into Cloudflare, and the value is that the author already worked out the KV binding, the custom domain and the port constraints. Two things to settle before you rely on it: change the shipped default UUID, because the same credential appears in the README for every deployment, and remember the node configuration is generated by a third party service at `sub.amclubss.com` unless you deploy the separate `am-cf-tunnel-sub` project yourself. The repository is not archived and v3.0.0 was released on 2026-09-19.

Frequently asked questions

Official sources

1. amclubs/am-cf-tunnel on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases