
Running paid VPS like DMIT for proxy nodes is stable but costly. What many don’t know is that Cloudflare Workers comes with 100,000 free requests daily—enough to run a completely free VLESS node as a backup or alternative. It’s worth deploying one for everyone.
This guide uses the open-source project edgetunnel, deployable in under 10 minutes.
Overview
Cloudflare Workers is a JavaScript runtime at CF’s edge nodes. edgetunnel implements the VLESS protocol in a Worker, routing traffic through CF’s CDN network to bypass direct IP identification.
Advantages:
- Completely free (the free plan offers 100,000 daily requests, sufficient for personal use)
- No server needed; no risk of IP blocks
- Extremely low chance of CF IP ranges being blocked
Limitations:
- Speed depends on CF network quality; slower than dedicated VPS during peak hours
- Not suitable for heavy downloads; best for browsing and light use
- Some regions apply QoS throttling to CF IPs
Prerequisites
- A Cloudflare account (free registration)
- A domain (optional but recommended; CF provides a free workers.dev subdomain as well)
Deployment Steps
Step 1: Fork the Project to GitHub
Open https://github.com/cmliu/edgetunnel, click Fork in the top right, and copy it to your account.
Step 2: Create a Worker in Cloudflare
- Log in to dash.cloudflare.com
- Click Workers & Pages in the left menu
- Click Create → Create Worker
- Give your Worker a name (e.g.,
my-proxy), then click Deploy
Step 3: Paste the Worker Code
- After deployment, click Edit code
- Clear the default code in the editor
- Open your forked GitHub repo, find the
_worker.jsfile, and copy all its contents - Paste it into the Worker editor
- Click Deploy in the top right
Step 4: Configure Your UUID (Connection Password)
A UUID is your node’s unique identifier. Generate one:
# macOS / Linux
uuidgen | tr '[:upper:]' '[:lower:]'
# Output example:
# a1b2c3d4-e5f6-7890-abcd-ef1234567890
Find the userID variable at the top of your Worker code and fill in your UUID:
let userID = 'a1b2c3d4-e5f6-7890-abcd-ef1234567890';
Or set it via environment variables (more secure):
- Click Settings → Variables on the Worker page
- Add a variable:
UUID= your UUID - Click Save and Deploy
Update the code to read from the environment variable:
let userID = env.UUID || 'default-uuid';
Step 5: Bind a Custom Domain (Optional but Recommended)
Workers.dev domains can be unstable in some regions; binding your own domain is better:
- Prerequisite: your domain must be hosted on Cloudflare (NS pointing to CF)
- Click Settings → Domains & Routes on the Worker page
- Click Add → Custom domain
- Enter your domain, for example
proxy.yourdomain.com - Save; CF automatically configures SSL
Getting Your Subscription Link
After deploying your Worker, visit:
https://your-worker-domain/your-uuid
For example:
https://my-proxy.workers.dev/a1b2c3d4-e5f6-7890-abcd-ef1234567890
The page will return a Base64-encoded subscription containing node information in multiple protocol formats (VLESS, Trojan, VMess).
Subscription Link Formats
https://your-domain/your-uuid?sub # Subscription link (all nodes)
https://your-domain/your-uuid?clash # Clash/mihomo format
https://your-domain/your-uuid?singbox # sing-box format
Using with mihomo
Method 1: Import via Subscription (Recommended)
Use the ?clash format URL directly as a subscription link and paste it into Clash/mihomo’s subscription management.
Method 2: Manual Configuration
proxies:
- name: "CF-Workers-VLESS"
type: vless
server: your-worker-domain
port: 443
uuid: your-uuid
network: ws
tls: true
ws-opts:
path: "/"
headers:
Host: your-worker-domain
client-fingerprint: chrome
Optimization: Select Faster CF IPs
edgetunnel uses CF-assigned nodes by default; speed varies by region. You can use CF IP optimization tools to select the node with the lowest latency.
Replacing the IP in your Worker domain with the lowest-latency CF IP can sometimes improve speed by 50% or more.
Tool: CloudflareSpeedTest
# Download the tool
wget https://github.com/XIU2/CloudflareSpeedTest/releases/latest/download/cfst_linux_amd64.tar.gz
tar -xzf cfst_linux_amd64.tar.gz
./CloudflareST
# After speed testing, results are saved in result.csv
# Use the lowest-latency IP to replace the one in your node config
CF Workers vs. DMIT VPS Comparison
| Comparison Item | CF Workers | DMIT VPS |
|---|---|---|
| Cost | Free | $20+/month |
| Speed (Daily) | Moderate | Fast (CN2 GIA) |
| Stability | Good (CF-managed) | Excellent |
| Heavy Traffic | Not suitable | Suitable |
| Risk of Blocking | Extremely low | Some probability |
| Use Case | Backup/Alternative | Primary node |
Recommended Strategy: Use DMIT as your primary, CF Workers as backup. The two solutions complement each other—if your primary node is blocked, CF Workers takes over seamlessly.
Combine with mihomo’s fallback mechanism:
proxy-groups:
- name: "Primary Route"
type: fallback
url: http://www.gstatic.com/generate_204
interval: 30
proxies:
- DMIT-HK-Reality
- CF-Workers-VLESS # Backup; auto-switches if primary fails
Frequently Asked Questions
522 Error After Worker Deployment
Your Worker domain isn’t resolving properly. Check:
- Whether your domain is bound to the Worker
- Whether your Worker is properly deployed (status shows Active)
Speed is Slow
- Try optimizing your IP (see CloudflareST method above)
- Check the time; CF nodes are under heavy load during peak hours
- Switch to a different CF data center region (you can select a different region’s IP from the optimization results)
Node Connects but Can’t Access Some Websites
Check the proxyIP configuration in your Worker code; some versions require setting an exit IP for proper origin access.
For more stable primary solutions, see:
📷 Cover image · Generated by Flux Schnell AI · panshi.io brand style