# 6Kmfi6HP/EDtunnel: a VLESS and Trojan proxy on Cloudflare Workers and Pages

> EDtunnel turns a Cloudflare Worker or Pages project into a VLESS and Trojan proxy endpoint with SOCKS5, HTTP and VLESS outbound routing. It is easy to deploy and easy to misconfigure, and the README leaves several operational questions open.

**6Kmfi6HP/EDtunnel** — EDtunnel 是一个基于 Cloudflare Workers 和 Pages 的代理工具，支持多种协议和配置选项。  EDtunnel is a proxy tool based on Cloudflare Workers and Pages, supporting multiple protocols and configuration options.

- Repository: https://github.com/6Kmfi6HP/EDtunnel
- Website: https://cfworker.edtunnel.best/
- Stars: 3,056 · Forks: 5,321
- Language: JavaScript
- License: MIT
- Published: 2026-09-24 · Updated: 2026-09-24 · Language: en
- Canonical page: https://hysenlabs.com/projects/6kmfi6hp-edtunnel

## What EDtunnel actually provides on top of a Cloudflare Worker

A Cloudflare Worker is a request handler with an outbound socket API. EDtunnel uses that socket API to accept a VLESS or Trojan connection from a client and forward the traffic onward, either directly or through a proxy it has been told about. The repository describes itself in package.json as "a Cloudflare Worker-based VLESS proxy with WebSocket transport" with a modular architecture, and the README adds Trojan support with auto-detection.

The audience is narrow. You need a Cloudflare account, a Workers or Pages project, and a client that speaks VLESS or Trojan. If you only want a generic HTTPS tunnel, or you want to terminate traffic inside your own network, this is the wrong layer. The value here is that the entry point is a Cloudflare edge hostname, and the routing decisions are made by environment variables and URL parameters rather than by a config file you redeploy.

## How the Worker routes traffic: UUID, PROXYIP and outbound chains

The request flow has three decision points. First, identity: the Worker matches the incoming UUID against the UUID variable, which accepts a single value or a comma-separated list. Second, egress: if PROXYIP is set, traffic is sent to that host and port instead of going direct; the README shows both a bare IP and a host:port form, and supports a comma-separated list for rotation. Third, fallback: PROXY_FALLBACK defaults to true, so if the configured proxies fail the Worker falls back to a direct connection, and PROXY_TIMEOUT defaults to 1500 ms, which is the budget each proxy attempt gets.

SOCKS5 and HTTP CONNECT proxies sit alongside PROXYIP, and VLESS_OUTBOUND takes a full vless:// URL with query parameters such as type=ws and security=tls. The README states that VLESS outbound has "full UDP capability" and that multi-proxy rotation includes automatic failover. The configuration page generated at the domain root and at /sub/[uuid] is what you paste into a client.

The priority order is explicit: URL parameters override environment variables, which override defaults. UUID is the exception. The README says UUID cannot be set through URL parameters, to prevent unauthorized identity changes.

## Deploying EDtunnel on Workers or Pages and reading the config page

There are two documented paths. For Pages, the README points at a YouTube tutorial and says to clone the repository and deploy it in Cloudflare Pages. For Workers, you copy the contents of _worker.js or use the Deploy to Cloudflare Workers button, which points at the repository URL. The repository also ships a wrangler.toml, and package.json exposes wrangler scripts.

The npm scripts are the fastest way to see what the toolchain expects. Deploy runs wrangler deploy, build runs a dry run, and dev runs wrangler dev against the remote runtime.

```bash
npm run deploy
```

If you prefer to set the UUID in the repository rather than the dashboard, the README gives this wrangler.toml shape, while noting it is not recommended for public repositories.

```toml
[vars]
UUID = "your-uuid-here"
```

The README recommends the Cloudflare Dashboard environment variables instead, because a committed UUID is visible to anyone who can read the repository. After deployment, visiting the domain root shows the full configuration, and /sub/[uuid] returns subscription content for that identity.

```bash
curl https://your-domain.workers.dev/sub/your-uuid
```

One detail that trips people up: the README warns that all multiple values must use the ASCII comma, not the Chinese full-width comma. A UUID list separated by the wrong character is a single malformed value, not three identities.

## URL query parameters and path-based proxy overrides

The override layer is the most distinctive part of EDtunnel and also the part most likely to confuse. Query parameters such as proxyip, socks5, http, vless and globalproxy mirror the environment variables, and the README states that they apply only to the current request. That makes them useful for testing a proxy before committing it to the dashboard.

```bash
https://your-domain.workers.dev/?proxyip=1.1.1.1:443&socks5_relay=true
```

There is also a path form: /proxyip=, /socks5://, /http://, /vless:// and /gvless= for a base64-encoded VLESS URL. The README notes that the project now handles query parameters encoded into the path, but recommends the standard ?parameter=value form. If you see /%3Fproxyip=value, that is the encoded question mark and the README says it will not work correctly.

This design has a real cost. Because the same configuration can arrive through three channels, debugging a misrouted request means checking the dashboard variables, the query string, and the path, in that order of precedence. The README does not describe a logging or introspection endpoint that would show which value won.

## Where EDtunnel gets awkward: separator bugs, silent fallback and no releases

The comma separator rule is the clearest failure mode in the documentation, and it is a bad one because the mistake looks correct in a dashboard text field. A full-width comma produces a value that parses as one entry, so rotation silently collapses to a single proxy or a single UUID.

PROXY_FALLBACK is the second. It defaults to true, which means a broken PROXYIP does not produce a visible error; the connection succeeds over the direct path instead. That is good for availability and bad for diagnosis, because the symptom of a misconfigured proxy is that everything works and your traffic does not take the route you intended. The README does not document a way to force failure or to log which path was taken.

Third, there are no releases in the repository data, and the last push was on 2026-04-25. The README does not document rollback, version pinning, or a changelog. If you deploy by copying _worker.js, you have no version identifier to return to, and the obfuscate script in package.json rewrites _worker.js from a bundled and minified build, which makes the deployed artifact hard to diff against the source tree.

## EDtunnel compared with the plain edgetunnel Worker

The obvious comparison is the edgetunnel Worker that this project's search results keep surfacing. Both put a VLESS endpoint on a Cloudflare Worker, and both are configured through environment variables. The difference is what sits behind the endpoint. A minimal edgetunnel deployment forwards to a single proxy address; EDtunnel adds a list of PROXYIP entries with rotation, SOCKS5 and HTTP CONNECT outbounds, a VLESS outbound, and Trojan on the same UUID with auto-detection.

That extra routing layer is the reason to pick EDtunnel and the reason it is harder to operate. A single-proxy Worker has one thing to check when traffic fails. EDtunnel has a precedence chain, a fallback that hides failures, and a separator convention that fails quietly. If your only requirement is one stable outbound, the simpler Worker is easier to reason about. If you are trying to survive individual proxy IPs going dark, the rotation logic is the feature you are here for.

## Licence and the cost of keeping a deployment current

The repository is MIT licensed, and the LICENSE file is at the top level. MIT is permissive: you can deploy, modify and redistribute the Worker, provided the copyright notice and permission notice are preserved. The package.json declares "license": "ISC", which does not match the repository's MIT file. That is a metadata inconsistency, not a legal conclusion, and if you redistribute EDtunnel you should read both files rather than trusting either field.

Upgrade cost is the harder question. With no releases and no changelog in the repository data, the only upgrade signal is a push to main. The documented deploy path is wrangler deploy or a Cloudflare Pages build, so pulling the latest source and redeploying is straightforward. Knowing whether anything changed, and whether it changed the routing behaviour you depend on, is not. The README does not describe a rollback procedure, so a deployment you cannot reproduce is a deployment you cannot revert.

## Conclusion

Adopt EDtunnel if you already run Cloudflare Workers or Pages and want a VLESS and Trojan endpoint with outbound proxy rotation, and if you are comfortable setting UUID and PROXYIP as dashboard environment variables rather than in wrangler.toml. Do not adopt it if you need documented rollback, versioned releases, or a stable subscription endpoint you do not control. Before deploying, verify that your PROXYIP host and port respond, that your comma separators are ASCII, and that the /sub/[uuid] page returns the configuration you expect.

## FAQ

### How do I set the UUID in EDtunnel?

Set UUID as a Cloudflare Dashboard environment variable, which the README recommends, or place it under [vars] in wrangler.toml, which the README says is not recommended for public repositories. UUID cannot be set through URL query parameters.

### Why does EDtunnel require a comma instead of a Chinese comma for multiple values?

The README states that all multiple configurations must use the English comma as the separator, and shows UUID, SOCKS5 and PROXYIP examples with both the correct and the wrong character. A full-width comma is treated as part of the value, so the list does not split.

### What happens if the PROXYIP configured in EDtunnel is unreachable?

PROXY_FALLBACK defaults to true, so the Worker falls back to a direct connection when the configured proxies fail. PROXY_TIMEOUT, which defaults to 1500 ms, is the time allowed for each proxy attempt.

## Sources

- [6Kmfi6HP/EDtunnel on GitHub](https://github.com/6Kmfi6HP/EDtunnel)
- [Issues](https://github.com/6Kmfi6HP/EDtunnel/issues)
- [License: MIT](https://github.com/6Kmfi6HP/EDtunnel/blob/main/LICENSE)
- [Project website](https://cfworker.edtunnel.best/)
- [README](https://github.com/6Kmfi6HP/EDtunnel/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/6kmfi6hp-edtunnel