How far can a zero-cost cf-vless US node go? Three measured builds: edgetunnel, preferred IP, and ProxyIP
Development
The egress address is Cloudflare’s own 104.28.x datacenter IP, and it changes with every new connection. A fixed, clean US IP needs a SOCKS5 exit as the next step.
These are the three builds I actually ran on 2026-10-20 (Pacific Time):
- v1, default: connect straight to the Worker hostname, with the project’s default ProxyIP.
- v2, fixed ProxyIP: put one fixed ProxyIP in the client path.
- v3, preferred IP: use CloudflareSpeedTest to pick a Cloudflare entry IP and put it in the client.
Every secret in this article is a placeholder: <UUID>, <ADMIN>, and <WORKER_HOST> (your own Worker hostname).
1. How it works: a cf-vless node has two egress paths
edgetunnel (https://github.com/cmliu/edgetunnel) runs VLESS over WebSocket on Cloudflare Workers. The client first connects to a Cloudflare edge, the entry. The Worker then uses connect() to reach the destination site, the egress.
One detail is easy to miss. @ygkkkg’s post explains it clearly:
🎯很多人可能不清楚： ProxyIP → 负责 CF 网站 托管在 Cloudflare 的网站。ProxyIP 决定 CF 网站访问时的出口。比如X、ChatGPT就是这类网站。 优选 IP → 负责非 CF 网站 优选 IP 决定这部分网站的出口。比如google，youtube，facebook等与CF无关的网站。 可以简单理解为：ProxyIP 管 CF Show more
- Ordinary sites (Google, YouTube, ipinfo, cleanip, and anything else not hosted on Cloudflare): the Worker connects directly, and the other side sees a Cloudflare egress IP. In my tests that was always 104.28.x, AS13335.
- Sites hosted on Cloudflare (X, ChatGPT, cloudflare.com, and so on): Workers cannot use
connect()to reach Cloudflare’s own IPs, so edgetunnel switches to the ProxyIP. A ProxyIP is a machine that forwards port 443 to Cloudflare. Sites in this group see that machine’s IP as the egress. - Preferred IP changes the “client → Cloudflare entry” hop: the entry becomes a low-latency, fast Cloudflare IP. SNI and Host stay the same.
In another post, @ygkkkg also says that with a preferred IP the egress “shows a 104.28 prefix, the IP suffix keeps changing within a few seconds, and the country and region stay the same.” That post quotes an earlier article of his. The measurements below match that account.
🌟关于CF免费节点的跳IP问题，当然也分两条线路。在视频教程中没有说到！ 优选IP可以单个IP、可以域名归集多个同地区优选IP、可以域名归集多个不同地区的优选IP，共这三种情况。 1、当使用单个IP时，落地显示104.28开头，IP后缀在几秒内会不停变化，但国家地区不变。 Show more
CF免费VPN节点新时代：无视1101报错，Workers+Pages精简部署方案，解读CF节点的奥秘 x.com/i/article/2100…
CF免费VPN节点新时代：无视1101报错，Workers+Pages精简部署方案，解读CF节点的奥秘 x.com/i/article/2100…
2. Deploy edgetunnel to Workers
2.1 Prepare
- A free Cloudflare account. Register a separate one. Do not keep this on the same account as a production site. Using Workers as a general-purpose proxy sits outside what Cloudflare’s terms are aimed at. If the account is restricted, the other sites on that account go with it.
- The client I used is sing-box 1.14.3. v2rayN, mihomo, and Shadowrocket also work.
2.2 Generate the secrets
mkdir -p ~/cf-vless && cd ~/cf-vless && umask 077
python3 -c "import uuid,secrets;print(f'UUID={uuid.uuid4()}\nADMIN={secrets.token_urlsafe(24)}')" > secrets.env
chmod 600 secrets.envUUID has to be a UUIDv4. ADMIN is the admin password and also the switch that turns the proxy on. It has to be set.
2.3 Get the source
git clone https://github.com/cmliu/edgetunnel.git && cd edgetunnel
git checkout a8ab11125ece9bc27983f609a6359be81b21050c # 我用的版本：2026-10-08 22:23:272.4 Deploy
wrangler is the simplest way:
npx wrangler login
# wrangler.toml 里 name = "<WORKER_NAME>"
npx wrangler deploy
echo "<UUID>" | npx wrangler secret put UUID
echo "<ADMIN>" | npx wrangler secret put ADMINWhat I actually did was upload through the Cloudflare API: PUT /accounts/{account_id}/workers/scripts/<WORKER_NAME>, with UUID and ADMIN as the two secrets in metadata, plus OFF_LOG=1 (I did not bind KV). Then POST .../subdomain turns on the workers.dev subdomain. The result is the same.
2.5 Check it
curl -s https://<WORKER_HOST>/ | head # 返回伪装的 "Welcome to nginx!" 页面就说明部署成功了3. Client config (v1, default)
{
"log": {"level": "warn"},
"inbounds": [{"type": "mixed", "tag": "in", "listen": "127.0.0.1", "listen_port": 10808}],
"outbounds": [{
"type": "vless", "tag": "cf",
"server": "<WORKER_HOST>", "server_port": 443, "uuid": "<UUID>",
"tls": {"enabled": true, "server_name": "<WORKER_HOST>", "utls": {"enabled": true, "fingerprint": "chrome"}},
"transport": {"type": "ws", "path": "/?ed=2560", "headers": {"Host": "<WORKER_HOST>"},
"max_early_data": 2560, "early_data_header_name": "Sec-WebSocket-Protocol"}
}],
"route": {"final": "cf"}
}The equivalent share link:
vless://<UUID>@<WORKER_HOST>:443?encryption=none&security=tls&sni=<WORKER_HOST>&fp=chrome&type=ws&host=<WORKER_HOST>&path=%2F%3Fed%3D2560#cf-vlessStart it with sing-box run -c client.json, then check the egress with curl -x socks5h://127.0.0.1:10808 https://ipinfo.io/ip.
4. v2: how to use a ProxyIP
A ProxyIP can go in the Worker variable PROXYIP, or straight into the client path:
"path": "/proxyip=<PROXYIP_HOST:443>?ed=2560"I picked one IP out of the project’s default public pool, proxyip.us.cmliussss.net, and pinned it: 150.136.139.228, Oracle Cloud, Ashburn, United States. Public ProxyIPs are someone else’s machines, and there is no way to see who runs them. I only sent a few probe requests through this one. I did not use it day to day.
What changed:
- Sites hosted on Cloudflare egress through a fixed 150.136.139.228. Three checks of
cloudflare.com/cdn-cgi/traceand four checks ofapi.ipify.orgall returned the same IP, colo=IAD. - Ordinary sites (cleanip, ipinfo, and the rest) are still 104.28.x, and the address still changes every time. ProxyIP only covers sites hosted on Cloudflare.
5. v3: how to pick a preferred IP
5.1 Pick an entry IP with CloudflareSpeedTest
The tool is XIU2/CloudflareSpeedTest v2.3.5 (https://github.com/XIU2/CloudflareSpeedTest/releases). The bundled ip.txt is Cloudflare’s official IPv4 ranges: one random address from each /24, 5955 in total.
On my test machine the TCP handshake completes locally, so the default TCPing came back as 0 ms for everything and showed no difference. I switched to HTTPing plus a download test:
./cfst -httping -httping-code 200 -url "https://speed.cloudflare.com/__down?bytes=50000000" \
-n 200 -t 3 -dn 10 -dt 8 -tl 400 -p 15 -o result.csvUsers in mainland China can usually just run the default TCPing. Point -url at a speed-test file you host yourself. The default URL is not guaranteed to work.
Result: 5871 addresses were usable. My test machine is on the US East Coast, and every IP landed in the IAD (Washington) datacenter. The ones near the top of the list:
- 104.31.220.40, average latency 16 ms, direct download 379 MB/s
- 172.65.222.149, average latency 14 ms, direct download 340 MB/s
- 104.20.80.180, average latency 10 ms, direct download 290 MB/s
- 172.65.26.34, average latency 9 ms, direct download 229 MB/s
I also tried a few hostnames people commonly use as preferred IPs. www.visa.com was fine. cf.090227.xyz took 11.6 seconds for 10 MB on that run, only about 7 Mbps. A third-party preferred-IP hostname is not reliable. Measure it yourself.
5.2 Put it in the client
Change only server. Keep server_name (SNI) and Host on the Worker hostname:
"server": "104.31.220.40", "server_port": 443,
"tls": {"enabled": true, "server_name": "<WORKER_HOST>", "utls": {"enabled": true, "fingerprint": "chrome"}},
"transport": {"type": "ws", "path": "/?ed=2560", "headers": {"Host": "<WORKER_HOST>"}, "max_early_data": 2560, "early_data_header_name": "Sec-WebSocket-Protocol"}Share link:
vless://<UUID>@104.31.220.40:443?encryption=none&security=tls&sni=<WORKER_HOST>&fp=chrome&type=ws&host=<WORKER_HOST>&path=%2F%3Fed%3D2560#cf-vless-preferip6. Results
6.1 cleanip.io: all three builds scored 75, grade B
- v1, default. The egress cleanip saw was 104.28.153.241, score 75 / B. Location / type: Cloudflare AS13335, Reston, Virginia, United States; native IP, datacenter IP.
- v2, fixed ProxyIP. The egress cleanip saw was 104.28.167.2, score 75 / B. Location / type: the same. cleanip is not hosted on Cloudflare, so the ProxyIP does not affect it.
- v3, preferred IP. The egress cleanip saw was 104.28.153.181, score 75 / B. Location / type: the same.
In an earlier round I measured the same way several times and got 74 to 75, all grade B. What the cleanip page listed: 4 of 24 reputation checks hit, a proxy-threat score of 33/100, and a network-segment abuse rate of 1.6%. The main reason for the deduction was “datacenter egress.”
6.2 Other tools (v1)
- Scamalytics: Fraud Score 24, Medium Risk. The page says this is a Cloudflare business-server IP, not residential broadband.
- IPPure: native IP, datacenter IP. The IPPure coefficient moves with the specific IP. Across my checks I saw 23% (clean), 44% (light risk), and 61% (moderate risk). This screenshot is the 44% result.
- ipinfo.io: Reston, Virginia, AS13335, tags Hosting and Relay, Privacy = true.
- Egress seen by sites hosted on Cloudflare (
www.cloudflare.com/cdn-cgi/trace): v1 and v3 were also 104.28.x, colo=SJC. Only v2 was pinned to 150.136.139.228.
6.3 Speed: v1 and v3
The test machine is in the United States. Latency is the total time for a request to google.com/generate_204 through the node. Each sample is a new connection, so the handshake is included. The download used the test files on proof.ovh.net.
- Build:
- v1 default (the screenshot run)
- generate_204 latency, median:
- 248 ms
- 10 MB:
- 58.7 Mbps
- 100 MB:
- 218.7 Mbps
- Build:
- v3 preferred (the screenshot run)
- generate_204 latency, median:
- 278 ms
- 10 MB:
- 53.7 Mbps
- 100 MB:
- 211.9 Mbps
- Build:
- v1 default (mean of 3 alternating A/B rounds)
- generate_204 latency, median:
- about 323 ms
- 10 MB:
- about 54.6 Mbps
- 100 MB:
- about 214 Mbps
- Build:
- v3 preferred (mean of 3 alternating A/B rounds)
- generate_204 latency, median:
- about 298 ms
- 10 MB:
- about 56.3 Mbps
- 100 MB:
- about 242 Mbps
On this machine, the preferred IP and the default entry were about the same. The three-round average was slightly better, but a single measurement was sometimes slower, and the gap stayed inside the noise. The test machine sits next to Cloudflare’s Washington datacenter. Every entry IP goes to IAD, and the route is the same. A preferred IP actually helps when the path from the client to Cloudflare is already poor, for example at peak hours on China’s three carriers, or when workers.dev is blocked and you need a different entry. That case means running cfst on your own network. The result depends on the person and the network.
v2 only changes the egress for sites hosted on Cloudflare. I did not measure its speed on its own.
7. What zero cost can actually do
What it can do:
- Completely free. A usable US node is deployed in a few minutes.
- cleanip.io score 75, grade B, a native US IP, Scamalytics 24 (Medium).
- An ordinary speed test is about 55 Mbps at 10 MB, and can pass 200 Mbps at 100 MB, on a test machine in the United States.
- A fixed ProxyIP can pin the egress when the site you are visiting is hosted on Cloudflare.
The limits:
- The egress is always a Cloudflare 104.28.x datacenter IP. Every checker recognizes it as Cloudflare, a datacenter, or a relay. Services that are strict about the IP, including e-commerce with tight risk controls and some streaming and AI services, may refuse it.
- Every new connection gets a different IP. The region stays put, but the IP suffix keeps jumping. Sites that need a sticky session may keep asking for verification.
- Neither a preferred IP nor a ProxyIP changes the egress that ordinary sites see. A preferred IP only changes the entry and the speed. A ProxyIP only covers sites hosted on Cloudflare, and a public ProxyIP is a datacenter IP from an unknown operator. The one I measured, 150.136.139.228, scored 88% on IPPure (extreme risk) and 75 on cleanip.
So Workers alone will not give you a US IP that is both fixed and clean. If that is what you want, the next step is:
Next: land on SOCKS5. edgetunnel supports a SOCKS5 or HTTP exit. Set the Worker variables SOCKS5=<user:pass@host:port> and GO2SOCKS5=*, or write /socks5://<user:pass@host:port>?ed=2560 in the client path. Every flow then egresses as that exit machine’s IP, and the address stays fixed. The quality of the exit machine’s IP decides the result:
- Your own US VPS: the egress is fixed, and it is still a datacenter IP.
- A residential or ISP static proxy: this can get you an IP in the “US home broadband” class. It usually costs money.
- A free route, for example @404jsh’s post “I just talked, and got US, Japan, and Korea residential IPs for ¥0”: CF Worker, then SOCKS5 on your own VPS, then a VPN Gate volunteer node. That needs a VPS, and VPN Gate has very few nodes that are actually inside the United States. I tried edgetunnel’s built-in SSTP straight to VPN Gate. It did not connect that time. This article has no result for that route.
Do not use a free public SOCKS5 of unknown origin from the internet. A lot of them are compromised machines.
8. References
- edgetunnel: https://github.com/cmliu/edgetunnel
- CloudflareSpeedTest: https://github.com/XIU2/CloudflareSpeedTest
- Checkers: https://cleanip.io, https://scamalytics.com, https://ippure.com, https://ipinfo.io