Digital screens display data on a circuit board background

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

  1. Log in to dash.cloudflare.com
  2. Click Workers & Pages in the left menu
  3. Click Create → Create Worker
  4. Give your Worker a name (e.g., my-proxy), then click Deploy

Step 3: Paste the Worker Code

  1. After deployment, click Edit code
  2. Clear the default code in the editor
  3. Open your forked GitHub repo, find the _worker.js file, and copy all its contents
  4. Paste it into the Worker editor
  5. 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):

  1. Click Settings → Variables on the Worker page
  2. Add a variable: UUID = your UUID
  3. Click Save and Deploy

Update the code to read from the environment variable:

let userID = env.UUID || 'default-uuid';

Workers.dev domains can be unstable in some regions; binding your own domain is better:

  1. Prerequisite: your domain must be hosted on Cloudflare (NS pointing to CF)
  2. Click Settings → Domains & Routes on the Worker page
  3. Click Add → Custom domain
  4. Enter your domain, for example proxy.yourdomain.com
  5. Save; CF automatically configures SSL

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).

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 ItemCF WorkersDMIT VPS
CostFree$20+/month
Speed (Daily)ModerateFast (CN2 GIA)
StabilityGood (CF-managed)Excellent
Heavy TrafficNot suitableSuitable
Risk of BlockingExtremely lowSome probability
Use CaseBackup/AlternativePrimary 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:

  1. Whether your domain is bound to the Worker
  2. Whether your Worker is properly deployed (status shows Active)

Speed is Slow

  1. Try optimizing your IP (see CloudflareST method above)
  2. Check the time; CF nodes are under heavy load during peak hours
  3. 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