v2ray + warp-go 非全局使用Cloudflare WARP解锁New Bing等服务
v2ex之相关帖子：https://www.v2ex.com/t/926788
谷歌之后看到有些文章通过继续修改X-Forwarded-For头的方法解决，将原先的8.8.8.8改为1.1.1.1，也确实能解决一部分人的问题，但这恐怕也只是一时饮鸩止渴之方案，非长期之良方，随时有可能被再次封杀。
评论区有人提到了通过WARP的方式解锁，我认为这个方法才是一劳永逸的，毕竟WARP甚至能解锁Netflix，Bing自然不在话下。
关于WARP之使用，我建议使用非全局模式。假设只有一台VPS作为梯子，那么可以让正常的代理流量使用VPS自己的IP直连，而需要解锁的流量使用WARP解锁，这样不必全部流量走WARP，可以保证速度。
启动warp-go非全局模式
通过warp-go脚本可以让VPS连上Cloudflare WARP。并且相比其他方案还有两项主要优点：
支持洛杉矶等wgcf无法获取WARP IP之地区使用；
支持非全局模式，只是单纯新增一个WARP网卡，可进行更多自定义。
warp-go项目地址：https://gitlab.com/ProjectWARP/warp-go
一键脚本：https://github.com/fscarmen/warp#warp-go-%E8%BF%90%E8%A1%8C%E8%84%9A%E6%9C%AC
安装之后切换为非全局模式：
使用ip a命令可以看到多出了一个WARP虚拟网卡：
使用curl工具指定网卡访问，可以看到IP已经变成了WARP的IP；但不指定网卡访问的话还是VPS原来的IP：
配置v2ray
说是v2ray，但其实我们用到的应该是xray。因为我们需要在outbounds中指定网卡，而这个选项只有xray的较新版本才能支持。
之前有写过另一篇类似的文章，通过v2ray在服务端配置轮询tor链路出口：在自己的VPS上利用v2ray+Tor打造代理IP池
接下来要介绍的配置参考了xray的文档和另一篇博客的内容，在此表示感谢。
首先我们需要配置inbounds，这一步应该是非常基础的，不必过多解释。我这里就使用x-ui来偷懒了。对于开在端口号xxx上的x-ui配置来说，其自动生成的inbounds配置对应的tag为inbound-xxx。
因此我们只需要配置outbounds和routing（以下配置模板省略了无关配置）：
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 | { "inbounds": [ { // 此处省略具体inbound配置 "tag": "inbound-xxx" } ], "outbounds": [ { "protocol": "freedom", "streamSettings": { "sockopt": { "tcpFastOpen": true, "interface": "WARP"// 指定使用名为WARP的网卡 } }, "settings": { "domainStrategy": "AsIs" }, "tag": "my-warp" } ], "routing": { "rules": [ {// 将inbound和outbound通过路由绑定：inbound-xxx -> my-warp "inboundTag": [ "inbound-xxx" ], "network": "tcp,udp", "outboundTag": "my-warp", "type": "field" } ] } } |
配置客户端
至此服务端配置已经完成，现在只需要让客户端连上即可。我这里客户端是用的是clash来分流。
配置Unlock规则组，例如：
1 2 3 4 5 | - name: "Unlock" type: select proxies: - "monolith_warp" # 走warp的线路，事先配好在proxies中 - "DIRECT" |
然后让Bing等需要解锁的域名走该规则即可：
1 2 3 | - DOMAIN-SUFFIX,openai.com,Unlock - DOMAIN-SUFFIX,bilibili.tv,Unlock - DOMAIN-SUFFIX,bing.com,Unlock |
与此同时，其他不需要Unlock的请求依旧是走原先的直连代理。这样可以保证其访问速度，毕竟即使VPS上直连Cloudflare WARP很快，也是存在一定延迟增加和降速。
