高！实在是高！白嫖 nat64 公共网关来做代理，太绝了！这样就解决了 workers 代理无法访问 ipv4 only 的网站问题
NAT64 公共节点资源有限，大家且用且珍惜
我在涌哥的脚本基础上，增加了自定义 proxydomains 变量，因此现在可以将需要固定ip访问的网站设置到 proxydomains 变量中，这样就不会跳 ip 了。
相信很多小伙伴在使用 cloudflare 搭建的 workers 节点时都会遇到同样的一个问题，那就是无法访问推特。这是因为推特目前不支持使用 ipv6 访问，而 cf workers 默认使用 ipv6 访问，此时会访问失败，然后会尝试使用 proxyip 去访问，假如你的 proxyip 节点也是优先使用 ipv6 访问的，那么就会失败。 为了解决这个问题，推荐使用一个 ipv4 only 的 proxyip，当然，这样会增加 proxyip 节点被网络上的大佬扫描出来的风险，但是不这样做就没法达到访问 ipv4 only 网站的效果。 网络上有一些公开的 proxyip 的域名，其中有一些是使用脚本自动更新，会定时扫描互联网上的 proxyip，使用一个域名可以解析出来相当多的 proxyip 的地址，这种时候会有一个问题，假如你本次访问正好解析出来的是一个 ipv4 only 的 proxyip，那么你就可以访问推特，假如域名解析出来的 proxyip 是带有 ipv6 地址，那你就没法访问推特。 有条件的小伙伴建议自己搭建一个 proxyip 节点，禁用 ipv6 以后，注意保护好信息，尽量避免泄漏。
注意，本项目提供的 worker-trojan-proxyip 和 worker-vless-proxyip，均未内置 proxyip，需要自己在变量中设置；worker-vless-nat64 则内置了公共 NAT64 节点
只需要设置 uuid 就行，如果不担心被其他人扫到，uuid 都不需要改，不过还是建议修改 建议搭配 ipv4 only 的 proxyip 使用
worker-vless-proxyip脚本稳定报 1101错误，不建议使用，实测另外两个脚本还是可以正常部署的
| 变量作用 | 变量名称 | 变量值要求 | 变量默认值 | 变量要求 |
|---|---|---|---|---|
| 1、必要的uuid | uuid (小写字母) | 符合uuid规定格式 | 万人骑uuid：86c50e3a-5b87-49dd-bd20-03c7f2735e40 | 建议 |
| 2、订阅节点：优选IP | ip1到ip13，共13个 | CF官方IP、CF反代IP、CF优选域名 | CF官方不同地区的visa域名 | 可选 |
| 3、订阅节点：优选IP对应端口 | pt1到pt13，共13个 | CF13个标准端口、反代IP对应任意端口 | CF13个标准端口 | 可选 |
| 4、需要固定ip访问的网站 | proxydomains | 域名之间使用","分割 | "twitch.tv","ttvnw.net" | 可选 |
| 5、proxyip | proxyip | 域名:端口 | "" | 可选 |
只需要设置 pswd 就行，如果不担心被其他人扫到，pswd 都不需要改，不过还是建议修改 建议搭配 ipv4 only 的 proxyip 使用
| 变量作用 | 变量名称 | 变量值要求 | 变量默认值 | 变量要求 |
|---|---|---|---|---|
| 1、必要的密码 | pswd (小写字母) | 建议字母数字 | 万人骑密码：trojan | 建议 |
| 2、全局节点能上CF类网站 | proxyip (小写字母) | 443端口：ipv4地址、[ipv6地址]、域名。非443端口：IPV4地址:端口、[IPV6地址]:端口、域名:端口 | proxyip：留空 | 可选 |
| 3、订阅节点：优选IP | ip1到ip13，共13个 | CF官方IP、CF反代IP、CF优选域名 | CF官方不同地区的visa域名 | 可选 |
| 4、订阅节点：优选IP对应端口 | pt1到pt13，共13个 | CF13个标准端口、反代IP对应任意端口 | CF13个标准端口 | 可选 |
| 5、需要固定ip访问的网站 | proxydomains | 域名之间使用","分割 | "twitch.tv","ttvnw.net" | 可选 |
下面的解释来自 gemini 2.5 pro，最后的地方它说错了，cloudflare 出口ip是同时拥有ipv4和ipv6的，但是优先使用ipv6，所以在访问推特等仅支持 ipv4 网站时就会失败。
您好，这是一个非常好的问题，也是理解这段代码核心功能的关键。
您的理解是正确的：代码确实是将一个IPv4地址转换成了一个IPv6地址，然后通过这个IPv6地址去访问。
现在来回答您最核心的困惑：这个转换后的IPv6地址究竟在哪台服务器上？
答案是：这个IPv6地址并不在最终的目标服务器上，它指向的是一台公共的“NAT64网关”服务器。
您可以把这台“NAT64网关”想象成一个专业的“国际快递中转站”。
一个通俗的比喻
您（Cloudflare Worker）：您只会说“IPv6”这门语言，也只认识“IPv6”格式的地址。您无法直接向一个只懂“IPv4”语言、只认识“IPv4”地址的人寄送包裹。
目标服务器：它只懂“IPv4”语言，只认“IPv4”地址。
NAT64网关（快递中转站）：这是一个非常特殊的中转站。它既懂IPv6，也懂IPv4，并且同时拥有IPv6和IPv4的地址。它的工作就是帮助您和目标服务器进行沟通。
代码的工作流程
代码中的流程就像这样：
第一次尝试：您（Worker）尝试直接用域名（比如 example.com）连接目标服务器。如果这个域名有IPv6地址，连接就成功了。但如果它只有IPv4地址（比如 93.184.216.34），您的IPv6环境无法直接连接，所以第一次尝试失败了。
B计划（NAT64登场）：
代码发现直连失败，于是执行 retry() 函数。
它首先通过DNS查询，明确知道了目标服务器的IPv4地址是 93.184.216.34。
然后，convertToNAT64IPv6 函数开始“打包”地址。它拿到了一个公共NAT64中转站的地址前缀，也就是代码里的 2001:67c:2960:6464::。
它将目标IPv4地址 93.184.216.34 按照规则嵌入到这个前缀后面，合成了一个新的、特殊的IPv6地址。例如，转换后可能看起来像这样（十六进制表示）：2001:67c:2960:6464::5db8:d822。
第二次连接：
现在，您（Worker）不再尝试连接 93.184.216.34，而是向这个新合成的IPv6地址 [2001:67c:2960:6464::5db8:d822] 发起连接。
由于这是一个合法的IPv6地址，您的网络环境认识它，于是成功地将数据包发了出去。
中转站的工作：
数据包到达了地址为 2001:67c:2960:6464:: 的NAT64网关服务器。
这个网关服务器看到这个请求，马上就明白了：“哦，这是一个需要中转的请求。我需要把数据包后面的 5db8:d822 部分解码出来。”
网关将 5db8:d822 解码回原始的IPv4地址 93.184.216.34。
然后，这台网关服务器用自己的IPv4地址，向真正的目标服务器 93.184.216.34 发起连接，并将您的数据转发过去。
当目标服务器返回数据时，数据会先回到NAT64网关，网关再将其打包成IPv6格式，发回给您。
总结
所以，可以这样理解：
转换后的IPv6地址，是您和NAT64网关之间约定的一个“暗号”。这个“暗号”的前半部分是网关的地址，后半部分是您真正想访问的目标。
服务器是“NAT64网关”。代码中使用的 2001:67c:2960:6464:: 是一个由第三方（如Trex.fi）提供的公共NAT64服务地址。您等于是在利用这个公共服务来作为连接IPv4世界的桥梁。
这么做的根本原因：Cloudflare Workers的执行环境是纯IPv6的，它无法原生创建到公网IPv4地址的出站连接。NAT64是解决这个“跨网络”通信问题的标准技术方案。这段代码巧妙地通过手动合成地址的方式，利用了公共NAT64服务，实现了这个功能。
- https://github.com/yonggekkk/Cloudflare-vless-trojan - 原项目仓库
- @yonggekkk - 原项目作者
本项目仅供学习交流使用，请遵守当地法律法规。