菜单
文章 WARP

使用WARP代理模式，解锁Netflix和ChatGPT

John Smith

• 阅读本文需 16 分钟
使用WARP代理模式，解锁Netflix和ChatGPT

如需一键解锁Netflix和ChatGPT，请自行搜索相应脚本，或者寻找专业稳定的DNS/IP解锁方案。本文只是以此为契机，进行相应的学习和探索，并简单记录。

受限于个人水平，文中结构排版与文字表达，难免存在错漏之处，还请见谅。

解锁测试

多功能测试脚本

https://github.com/LemonBench/LemonBench
https://github.com/lmc999/RegionRestrictionCheck

在服务器上运行脚本，可检测服务器自身IP，是否已解锁Netflix和ChatGPT。测试结果仅作为参考，并不一定准确，例如德国服务器，实际是解锁Gemini的，但是脚本却显示未解锁。

然而，当使用WARP代理模式解锁后，不能再用这种方法去判断，因为脚本运行时并没有通过WARP隧道去访问。

QuadraNet
OracleCloud

Netflix

在手机/电脑上，使用浏览器访问https://www.netflix.com/title/70143836，能正常显示《绝命毒师》的页面，即代表已解锁[非自制剧]。

Netflix

ChatGPT

  • （1）在服务器上测试

运行以下命令，如遇提示Something went wrong，则说明服务器自身IP，未解锁APP版本的ChatGPT。

curl https://ios.chat.openai.com
或
curl https://android.chat.openai.com
    • 未解锁（仅解锁Web版）的返回结果：

{"cf_details":"Something went wrong. You may be connected to a disallowed ISP. If you are using VPN, try disabling it. Otherwise try a different Wi-Fi network or data connection. (2)"}

    • 已解锁（Web和APP版）的返回结果：

{"cf_details":"Request is not allowed. Please try again later.", "type":"dc"}

  • （2）在手机/电脑上测试

使用浏览器访问https://chat.openai.com（或https://chatgpt.com），可正常显示，说明已解锁Web网页版；但在手机上，使用APP却报错，说明未解锁APP版本的ChatGPT。

ChatGPT
  • （3）使用WARP代理模式解锁后

在手机/电脑上，通过浏览器访问以下网址，查看是不是CloudFlare WARP的IP。（也可以直接使用ChatGPT的APP，查看是否解锁）
https://chat.openai.com/cdn-cgi/trace
https://chatgpt.com/cdn-cgi/trace
https://ios.chat.openai.com/cdn-cgi/trace
https://android.chat.openai.com/cdn-cgi/trace

或者，直接在服务器上运行以下命令，查看是不是CloudFlare WARP的IP。

curl -x "socks://127.0.0.1:40000" https://chat.openai.com/cdn-cgi/trace

基本原理

当我再回头看看本文时，发现通篇几乎都是文字内容，显得太过于凌乱，所以使用Xmind思维导图，在此补上简单的原理图，便于理清思路。

WARP部分

手机/电脑上，安装WARP客户端

  • 实现方式：在终端设备上，通过代理软件嵌套一层 WARP，形成链式代理（类似 内层 WireGuard + 外层 TLS 的“套娃”结构）。
  • 主要考量：
    • 操作与维护：在多用户（亲友/新手）和多设备场景下，这种方式会增加配置门槛与后期维护的复杂度。因此本文不推荐。
    • 性能开销： 终端设备需同时处理两套加密协议，CPU 负担加重，对于移动设备而言，发热情况与电池续航是需要权衡的因素。

服务器上，安装WARP客户端

这是本文讲述的核心。在服务器端开启 WARP 代理模式，除了能解锁 Netflix 和 ChatGPT，用途也更加广泛：

  • 极致体验
    • 用户与设备双无感：所有流量规则微调均在服务器端完成，一处修改，全局生效，极大降低了维护成本。
  • 精准解锁
    • 将 Netflix、ChatGPT、Reddit、Google Scholar 等特定流量统统交给 WARP，解决机房 IP 被拉黑或访问受限的问题。
  • 回国流量的“分流兜底”
    • 场景：当客户端因开启全局模式或分流规则失效，导致大陆流量（漏网之鱼）流向海外服务器时。
    • 方案：直接 block 拦截虽然安全、简单粗暴，但用户体验差；而将这部分流量分流给 WARP ，既能保证访问不中断，又能隐藏服务器真实 IP。
  • 补全协议栈
    • 为 IPv6-Only 或 IPv4-Only 的廉价 VPS 提供缺失的网络出口。通过 WARP 赋予服务器双栈访问能力，使其能够顺畅连接全栈互联网资源。

官方WARP相关文章

https://blog.cloudflare.com/zh-cn/tag/warp/
https://blog.cloudflare.com/zh-cn/announcing-warp-for-linux-and-proxy-mode/

时至今日，由于WARP版本更新迭代，以上官方文章中关于warp-cli的部分，有些命令已经过时/更改/弃用。
要查看WARP版本更新记录/新功能变化等，可访问以下链接。
https://developers.cloudflare.com/cloudflare-one/changelog/cloudflare-one-client/

官方WARP安装

https://developers.cloudflare.com/warp-client/get-started/linux/
https://pkg.cloudflareclient.com

本文，以Debian 12作为演示，复制官方操作。

  • Add cloudflare gpg key
curl -fsSL https://pkg.cloudflareclient.com/pubkey.gpg | sudo gpg --yes --dearmor --output /usr/share/keyrings/cloudflare-warp-archive-keyring.gpg
  • Add this repo to your apt repositories
echo "deb [signed-by=/usr/share/keyrings/cloudflare-warp-archive-keyring.gpg] https://pkg.cloudflareclient.com/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/cloudflare-client.list
  • Install
sudo apt-get update && sudo apt-get install cloudflare-warp

WARP的使用（warp-cli）

  • 注册客户端
warp-cli registration new
  • 设置代理模式，默认端口是40000
warp-cli mode proxy

CloudFlare WARP支持的模式，有warp, doh, warp+doh, dot, warp+dot, proxy, tunnel_only。
如果使用默认模式（warp），那么下一步“连接WARP网络”（运行warp-cli connect命令）时，WARP将接管所有网络流量，从而导致ssh连接断开，完蛋啦，傻眼了吧！
当然，掉坑后还是能爬起来的，通过服务器厂商提供的Web后台面板，进入VNC远程连接，运行命令恢复原状，即“断开WARP网络”（运行warp-cli disconnect）。

  • 也可以根据自己喜好，例如自定义端口为10086，非必须
warp-cli proxy port 10086
  • 自定义端口，也可以直接改配置文件，"proxy_port": 10086，非必须
sudo nano /var/lib/cloudflare-warp/settings.json
  • 连接WARP网络
warp-cli connect
  • 测试WARP网络

当看到CloudFlare的IP，或者warp=on，即代表WARP网络连接成功。

curl -x "socks://127.0.0.1:40000" https://www.cloudflare.com/cdn-cgi/trace
或
curl -x "socks5://127.0.0.1:40000" https://www.cloudflare.com/cdn-cgi/trace

# 输出结果如下
fl=445xxxx
h=www.cloudflare.com
ip=104.28.195.185
ts=1776xxxxxx.000
visit_scheme=https
uag=curl/8.14.1
colo=LAX
sliver=none
http=http/2
loc=US
tls=TLSv1.3
sni=plaintext
warp=on
gateway=off
rbi=off
kex=X25519MLKEM768
  • 断开WARP网络
warp-cli disconnect
  • WARP配置文件路径

/var/lib/cloudflare-warp/

  • 查看WARP连接状态
warp-cli status
  • 查看更多warp-cli命令
warp-cli --help
  • 重启WARP主程序

使用top或htop命令，有时候会发现/bin/warp-svc，竟然占用了500-600MB内存！对于低配的VPS而言简直要了老命，要么增加swap，要么定时重启主程序warp-svc释放内存。

# 查看 warp-svc
sudo systemctl status warp-svc
或
sudo service warp-svc status

# 重启 warp-svc
sudo systemctl restart warp-svc
或
sudo service warp-svc restart
  • WARP内存泄漏

官方WARP客户端，内存泄漏问题由来以久，之前确实并不关注，也没深入研究。

方法1：对warp-svc进行限制

配置说明：

MemoryMax：物理内存RAM上限150MB，超出则触发系统回收，若回收失败则杀掉进程
MemorySwapMax：交换空间Swap上限50MB
Restart：设置为always，确保进程崩溃或被杀后能自动重启
RestartSec：设置重启前的等待缓冲时间为5秒
Nice：优先级设为10，通过增大 Nice 值，降低 CPU 优先级

# 编辑 warp-svc 配置
sudo systemctl edit warp-svc

# 增加以下内容，建议根据自己的实际情况调整
[Service]
MemoryMax=150M
MemorySwapMax=50M
Restart=always
RestartSec=5s
Nice=10

# 重启 warp-svc 生效
sudo systemctl restart warp-svc

当然，也要提一嘴 crontab -e，添加定时任务重启 warp-svc，就像低端路由器经常卡，需要定时重启大法。此处不推荐，是因为你不知道内存啥时候泄漏/爆满，就很被动，所以终归不如限制内存的方案稳妥和优雅。

方法2：不使用官方WARP客户端

使用 WireGuard 配置，wgcf即https://github.com/ViRb3/wgcf
Xray 出站配置，可参照https://xtls.github.io/document/level-2/warp.html

Xray部分

Xray安装

Xray官方文档参考
https://github.com/XTLS/Xray-core
https://github.com/XTLS/Xray-install
https://github.com/XTLS/Xray-examples
https://xtls.github.io

每个人都有各自的喜好和习惯，针对不同的内核，V2ray（V2fly）、Xray，sing-box、Mihomo（原Clash.Meta），请自行查阅对应的官方文档。

Xray配置

由于是在Xray的服务端进行分流，因此本文指的是，修改Xray服务端配置。

sudo nano /usr/local/etc/xray/config.json
  • Xray的Inbound入站，添加sniffing，因为需要根据sni探测域名。
"inbounds": [
  {
    "port": 443,
    "protocol": "vless",
    "settings": { 
      …… //根据自己的实际情况填写
    },
    "streamSettings": {
      …… //根据自己的实际情况填写
    }
    "sniffing": {
      "enabled": true,
      "destOverride": [
        "http",
        "tls",
        "quic"
      ]
    }
  }
]
  • Xray的Routing路由规则中，设置域名过滤（分流Netflix和ChatGPT）。
"routing": {
  "domainStrategy": "AsIs",
  "rules": [
    {
      "type": "field",
      "domain": [
         "geosite:netflix",
         "geosite:openai"
       ],
       "outboundTag": "warp"
    }
  ]
}
  • Xray的Outbound出站，使用socks协议，将数据转发至本机40000端口。
"outbounds": [
  {
    "tag": "direct",
    "protocol": "freedom"
  },
  {
    "tag": "warp",
    "protocol": "socks",
    "settings": {
      "servers": [
        {
          "address": "127.0.0.1",
          "port": 40000
        }
      ]
    }
  }
]
  • 测试Xray配置
# 测试Xray配置，通过输出结果判断语法是否正确
sudo xray --test -c /usr/local/etc/xray/config.json 

Xray 1.8.23 (Xray, Penetrates Everything.) 4c82ef8 (go1.21.4 linux/amd64)
A unified platform for anti-censorship.
xxxx/xx/xx xx:xx:xx.828646 [Info] infra/conf/serial: Reading config: &{Name:/usr/local/etc/xray/config.json Format:json}
Configuration OK.
  • 重启Xray服务
sudo systemctl restart xray
或
sudo service xray restart
  • 查看Xray运行状态
sudo systemctl status xray
或
sudo service xray status

坏消息：试验失败

  • 手机/电脑上，使用浏览器访问Google正常（Xray代理），但访问Netflix和ChatGPT都报错。

此网站无法提供安全连接，www.netflix.com发送的响应无效，ERR_SSL_PROTOCOL_ERROR。

  • 服务器运行环境
    • 系统架构，x86/AMD64
    • 操作系统，Debian12 和 Ubuntu 24.04.1 LTS
    • WARP版本，warp-cli 2024.9.346.0
    • Xray版本，1.8.23

排查故障时，在不同环境（操作系统/IP地址）都进行了测试，结果还是一个样。

  • WARP连接测试
curl -x "socks://127.0.0.1:40000" https://www.cloudflare.com/cdn-cgi/trace
或
curl -x "socks5://127.0.0.1:40000" https://www.cloudflare.com/cdn-cgi/trace

在服务器上，运行curl -x命令，直接将数据转发到WARP的40000端口​，能正常显示ClouFlare的IP，以及warp=on，说明WARP客户端能正常访问。那就只好再从Xray身上继续排查。

  • 打开Xray访问日志
sudo nano /var/log/xray/access.log
x.x.x.x:39955 accepted tcp:www.netflix.com:443 [warp]
x.x.x.x:39956 accepted tcp:www.netflix.com:443 [warp]
x.x.x.x:39958 accepted tcp:youtubei.googleapis.com:443 [direct]
x.x.x.x:39957 accepted tcp:www.google.com:443 [direct]

Xray的Outbound出站，转发到WARP的40000端口，分流并无异常。

  • 打开Xray错误日志
sudo nano /var/log/xray/error.log
app/proxyman/outbound: app/proxyman/outbound: failed to process outbound traffic > proxy/socks: failed to establish connection to server > proxy/socks: server rejects

app/proxyman/inbound: connection ends > proxy/vless/inbound: connection ends > proxy/vless/inbound: failed to transfer response payload > io: read/write on closed pipe

Xray的Outbound出站流量 ——>Socks协议——> WARP客户端，中间出现了问题。

  • 问题分析
    • WARP监听的40000端口服务，是可以正常访问的！（curl -x验证通过）
    • 而Xray配置，无数次核对确认，也是可以正常使用的！（浏览器可访问Google）
    • 关键就在于，Xray转发给本机WARP这个环节出问题了！（Netflix和ChatGPT出错）

Xray为何有错误日志，到底谁的错？

内事不决问百度，外事不决问谷歌。网上搜到的WARP解锁，大多都是一键脚本的，并不是一步步手搓配置，除了脚本作者，没人会深究这些配置。
正当我日夜苦恼，百思不得其解时，上天开眼了，在官方社区发现有两种说法。

（1）WARP的socks5协议不支持UDP，涉及DNS请求解析。

但是，这种案例场景是，电脑上（一般是Windows）通过浏览器的socks协议，转发给WARP客户端，与本文不符。
https://community.cloudflare.com/t/cloudflare-warp-local-proxy-mode-no-working/508993

（2）WARP新版本2024.9.346.0的Bug。

暂时的解决方法是，安装WARP旧版本2024.6.497即可正常使用；或者向官方提交Bug等待下一个版本修复。事实证明，这个解决方法是对的，搞定！那一刻，眼泪快掉下来了😭
https://community.cloudflare.com/t/cloudflare-warp-version-2024-9-346-0-proxy-mode-issue/720751

# 下载Debian包
curl -O https://pkg.cloudflareclient.com/pool/bookworm/main/c/cloudflare-warp/cloudflare-warp_2024.6.497-1_amd64.deb
或
wget https://pkg.cloudflareclient.com/pool/bookworm/main/c/cloudflare-warp/cloudflare-warp_2024.6.497-1_amd64.deb

# 安装Debian包
sudo dpkg -i cloudflare-warp_2024.6.497-1_amd64.deb

# 未修复Bug前，保持WARP当前版本，以防运行sudo apt upgrade时被更新
sudo apt-mark hold cloudflare-warp

# 将来修复Bug后，解除限制，允许更新版本
sudo apt-mark unhold cloudflare-warp

由于WARP官方存储库https://pkg.cloudflareclient.com，访问网页无法直接找到历史版本安装包，因此下方贴出部分链接，以供不时之需。

Debian包，https://pkg.cloudflareclient.com/pool/bookworm/main/c/cloudflare-warp/cloudflare-warp_2024.6.497-1_amd64.deb
Ubuntu包，https://pkg.cloudflareclient.com/pool/noble/main/c/cloudflare-warp/cloudflare-warp_2024.6.497-1_amd64.deb
RPM包，https://pkg.cloudflareclient.com/rpm/x86_64/cloudflare-warp-2024.6.497-1.x86_64.rpm

2025年更新：WARP新版本已解决此Bug，至于从哪个版本开始，并未时刻关注，能用就行……

其他方案

  • Xray分流IPv4和IPv6

由于有些服务器IP，自带IPv4无法解锁，但IPv6可以解锁。实现思路，使用Xray的Outbound，链式代理配置。参考：
https://github.com/XTLS/Xray-core/issues/1653#issuecomment-1602185054
https://github.com/fscarmen/warp-sh

  • Xray流量转发

既然A服务器IP，无法解锁Netflix和ChatGPT，那就可以通过Xray的Outbound出站，转发给能解锁的B服务器处理。缺点是，你要有2台服务器（多花钱），且服务器A和B由于来回转发要消耗较多流量。

当然，也有解决方法，不用服务器端转发。只需要在Xray客户端分流，普通应用交给服务器A，需解锁应用交给服务器B。咦……是不是很熟悉，这不就是使用机场多节点的场景么？

总之，这些都是通过改变用户的 IP 地址（代理服务器IP），来绕过地区限制，实现解锁Netflix/ChatGPT的方法。

  • DNS解锁

针对服务器仅有IPv4，且无法解锁的，像BandwagonHost官方，Los Angeles服务器提供了内网的DNS（172.31.255.2），但只解锁ChatGPT，不解锁Netflix。

当访问ChatGPT时，DNS的解析结果为172.31.255.2（利用SNI进行DNS劫持），然后再将数据转发给，位于San Jose的AS6233 xTom IPv6服务器访问。

从用户的层面而言，只需要在服务器上设置DNS，而最终数据转发给BandwagonHost官方搭建的解锁服务器访问，不需要为解锁额外付费。但需要注意的是，用户体量大，共用IP，且IPv6是一直变化的，稳定性可能要考量，除非自建解锁服务器。

https://ipinfo.io

感兴趣的话，可以再深入剖析DNS解锁，参照https://blog.skk.moe/post/how-proxy-client-cause-netflix-unlock-to-fail

  • 好消息
    2025.01.13左右，ChatGPT官方已经放宽了机房IP的限制，包括OracleCloud、DMIT、BandwagonHost、DigitalOcean、Aliyun（AlibabaCloud）等，都可以直接使用APP版本的ChatGPT。
    大赦天下，皆大欢喜！至于降智嘛，那得资深付费用户才有发言权。
  • 2025年11月，发现DMIT机房IP，解锁Netflix和Reddit（2025年10月未解锁）。
    2026年4月，OracleCloud机房IP，可以解锁Netflix，未解锁Reddit。
    可能只是偶然凑巧，并无有效的案例能够证明；然而时代、环境、政策在变化，解锁不必太在意。

另外，我的服务器IP几乎不会变动，即便DMIT、OracleCloud可以免费更换IP。我本身对所谓的IP风险值评分并无兴致，脚本测得再纯净，也始终掩盖不了 Hosting IP 的宿命。当然，论“情绪价值”这方面，还得靠娱乐脚本。

写在最后

网上已经有很多关于CloudFlare WARP解锁Netflix和ChatGPT的文章和视频。你这不是又在重复造轮子？

事实是，我本人亲自尝试时，却发生了出乎意料的情况。主要有3点，已经在本文中，使用高亮颜色标注出来。
1）对于新手而言，warp-cli不熟悉，且旧命令已弃用，有些文章未能及时更新。
2）参照官方文档，直接运行warp-cli connect，结果导致ssh断连，需要VNC抢救。
3）warp-cli新版本Bug，谁曾想自己就偏偏遇上了呢，这，就是天选之子（呸）。

总结，失败是成功他妈。

参考推荐

https://github.com/P3TERX/warp.sh
https://github.com/haoel/haoel.github.io

分享