cf-proxy-ex turns a URL prefix into a whole reverse proxy

Open a site by putting its URL behind your own domain

The interface is one rule: prefix any address with your deployment's domain and the worker fetches the rest. The README's example is a DuckDuckGo chat session routed through the author's demo deployment:

https://y.demo.lhyang.org/https://duckduckgo.com/?t=h_&q=hi&ia=chat

The same shape loads GitHub, Stackoverflow, Google Maps or an OpenAI chat page, and the project description lists Github acceleration and OpenAI and ChatGPT access among its targets. Underneath that prefix trick the worker does what a reverse proxy does: it fetches the origin, rewrites the HTML and the headers so the browser talks only to the worker domain, and handles the details that break naive proxies, including relative URLs turned into absolute ones, redirects with the target URL completed, and form submission. The repository makes the shape of the thing obvious, with a single _worker.js as the entry point, a beta_worker.js alternative, a wrangler.jsonc for the Cloudflare toolchain, and a docs directory of plain Markdown files at the root rather than a documentation site.

The password gate is a cookie check with a default of 123

Since version 1.4 the worker sits behind a security password, and the default is 123. Anyone deploying this has to change that, which means editing the code and searching for the password declaration:

const password = "";

Replace that with your own string. The mechanism around it is simple and worth understanding before you publish anything. On each request the worker looks for a password cookie, checks whether the value matches, and either lets the request through, shows an input screen, or returns 403 outright. The cookie's name defaults to passwordCookieName, and both the name and the behaviour are covered in more detail in security_password_tutorial.md at the repository root. The reason the gate exists at all is not abstract: the README shows a screenshot of an abuse report, and an open forward proxy on a domain of yours is an open relay that strangers will find. Changing 123 is not optional, and the gate is only a front door, so treat the deployment as public.

Cookie scoping is the argument against logging in anyway

The most technical claim in the README is about cookies, and it is worth reading closely. The project limits the scope of cookies it passes through, so a session started on one proxied site is not handed to another. The README contrasts this with the original version of the proxy, whose cookies were global, and spells out the consequence: log into Github through the proxy, then visit a malicious site through the same proxy, and your cookies go with you. Even with scoping in place, the README tells you not to log into anything through the proxy, and the online demo is published with the password 123, which is a reminder of what happens when an instance is left open. For an engineer deciding whether to use this, the takeaway is that the project has thought about the failure mode and still declines to promise it is safe for authenticated sessions. Treat the proxy as a way to read a public page, not as a way to be signed in somewhere else.

Deploy to Cloudflare first, Deno second

Deployment is documented as two Markdown files at the repository root, deploy_on_cf_tutorial.md for Cloudflare and deploy_on_deno_tutorial.md for Deno, and the second exists because a contributor opened an issue pointing out the worker code was not Cloudflare specific. The name stayed cf-proxy-ex anyway, the README explains, because renaming it to worker-proxy-ex was more trouble than it was worth. That is worth knowing when you search for documentation or for other people's forks, because the name understates where the code runs. The project is built on gaboolic's cloudflare-reverse-proxy, and the author credits that repository for the Cloudflare deployment approach. If a deploy fails with a redirect or an error, the README points at FAQ.md rather than at an issue tracker, so check that file before debugging the worker yourself. There is no build step in the repository to speak of, since the deliverable is a single JavaScript file.

The subdomain name is sent in plaintext before the page loads

This is the sharpest piece of advice in the README, and it is a warning rather than a feature. Do not name the subdomain something like proxy.example.com, because the TLS handshake sends the server name in cleartext, which makes the proxy easy to identify for anyone watching the network. The recommended alternative is a name with no false meaning of its own, and the README offers cdn.example.com or img.example.com as the kind of thing to use. Alongside that, the quick start suggests buying your own domain, noting that searching for $0. in a registrar's search box turns up one-year throwaway domains, and warning to turn off auto-renewal so the domain is not charged again. Custom domains are described as optional but recommended for stability. The combination is deliberate: hide the service in plain sight, own the name, and do not let a registrar keep a billing relationship with a proxy you are running.

MIT plus two conditions, which is not the same as MIT

The LICENSE file is described in the README as the MIT License plus some conditions, and the two conditions are specific. Any proxy site built with the project must carry a link back to the open source repository, and using the project to make money is prohibited, including for projects based on it. That is a source-available arrangement with obligations attached rather than a permissive licence, and it changes what you can do with the code compared with plain MIT: internal use and study are unaffected, while anything customer facing has to credit the project and cannot be a paid product. The README also states that the project is for learning how online proxies work and forbids using it for unlawful activity. None of this is legal advice, and the wording of the conditions is short enough that a commercial deployment should be checked against the LICENSE file itself rather than against this summary.

What breaks: URL normalization loops and undocumented targets

Two contributors are credited with finding a Cloudflare URL normalization problem that produced an infinite redirect loop, which tells you the failure mode is not hypothetical: Cloudflare's own normalization can fight the worker's rewriting, and the symptom is a page that never settles. A FAQ file exists for exactly this class of problem. Beyond that, the documentation is thin about what a target site must look like to work. There is no list of verified sites, no statement about WebSocket support, no description of how the worker handles a site that needs a session or a service worker, and no guidance on request size or rate limits. The screenshots in the README cover DuckDuckGo, Baidu, Github and Stackoverflow, which is the closest thing to a compatibility list that exists. If your target is something else, test it against the public demo before you deploy your own copy and change the password.

How it differs from an online proxy service or a VPN

The alternative approaches solve a different part of the problem. A commercial online proxy such as hide.me runs the fetching in the browser and the vendor's servers, so you install nothing and trust the operator with every request, and cf-proxy-ex explicitly positions itself against that class by loading more static assets and scoping cookies. A VPN moves all your traffic, which is the wrong shape for the problem here, since the goal is usually one unreachable page rather than a blocked network, and it needs a client on every device. A proxy on your own VPS is closest in spirit, but it costs money, needs hardening, and gives up the serverless property that makes this project a two-file deployment. What cf-proxy-ex adds on top is the URL prefix convention, which means no client configuration at all: the browser, a bookmark, and a link you can paste to someone else. The cost is that you own the abuse report that arrives when someone else uses it.

Editorial conclusion

Adopt cf-proxy-ex if you need a single blocked page to load from a machine you control and you already have a domain and a Cloudflare account, because the whole deployment is _worker.js plus wrangler.jsonc. Do not adopt it if you need anonymity from your ISP rather than from one site, since everything still runs under your own domain, and read the licence conditions first, because the MIT grant comes with a requirement to credit the project and a prohibition on profiting from it. Verify three things before you rely on it: that you have changed the default password 123 in the deployed copy, that your subdomain name does not contain proxy, since the SNI is sent in plaintext during the TLS handshake, and that nothing newer than v1.5.1 from 2026-04-12 has been released, the last push to main being 2026-06-11.

Frequently asked questions

Official sources

1. 1234567Yang/cf-proxy-ex on GitHub
2. Issues
3. Project website
4. README
5. Releases