谷歌之后看到有些文章通过继续修改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（以下配置模板省略了无关配置）：
{
"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规则组，例如：
- name: "Unlock" type: select proxies: - "monolith_warp" # 走warp的线路，事先配好在proxies中 - "DIRECT"
然后让Bing等需要解锁的域名走该规则即可：
DOMAIN-SUFFIX,openai.com,Unlock - DOMAIN-SUFFIX,bilibili.tv,Unlock - DOMAIN-SUFFIX,bing.com,Unlock
与此同时，其他不需要Unlock的请求依旧是走原先的直连代理。这样可以保证其访问速度，毕竟即使VPS上直连Cloudflare WARP很快，也是存在一定延迟增加和降速。
