§9 WARP 专章（M-003 追加要求：单独成章）
状态：已可用。官方定义取自 Cloudflare WARP 文档 [DOC]（
S-06）；社区用法与陷阱取自 M-009 / M-013 / M-014 / M-017 / M-019 / M-022 / M-024，均标注[COMMUNITY]。 ⚠️ 范围声明：本章只讲"WARP 能做什么、有什么陷阱、如何与 Tunnel/组网配合"；不提供任何代理/翻墙配置教学（社区素材中涉及该类用途的部分，仅作能力与风险说明）。
9.0 先分清两条产品线（最容易混的地方）
官方（[DOC]）把 WARP 分成两个产品，文档与客户端都不一样：
| 消费者版 | 企业版 | |
|---|---|---|
| 名称 | WARP（1.1.1.1 with WARP） | Cloudflare One Client（原 Zero Trust WARP） |
| 文档入口 | developers.cloudflare.com/warp-client/ | cloudflare-one/team-and-resources/devices/cloudflare-one-client/ |
| 定位 | 面向个人的"更快、更私密"的上网客户端 | 组织对企业设备下发安全策略 |
| 与本教程的关系 | 了解即可 | ⭐ "异地组网 / 内网访问 / Mesh"用的都是这条线 |
官方原话：consumer 版文档明确「Looking for Zero Trust? … refer to the Cloudflare One Client documentation」。读者按"WARP"搜索时经常找错文档，这是第一章就要提示的点。
9.1 WARP 到底做了什么
一句话：在设备/服务器与互联网之间插入一段"经 Cloudflare 网络的加密出口"，可被策略控制。
社区对"套 WARP"的定义（M-024）：
「指在通过安装客户端或脚本，强制让服务器的所有或部分对外访问流量，先经过 Cloudflare 的 WARP 网络服务再发出去。相当于给 VPS 加了个 VPN」
WARP ≠ 站点加速：它不改变"你到 Cloudflare 边缘"的落点选择（那是优选，§3），而是改变你这台机器的出站流量路径。两者可以同时存在，但解决的是不同问题。
9.2 五类正当用途（按可信度排序）
| # | 用途 | 出处 | 说明 |
|---|---|---|---|
| 1 | 给 V4/V6 Only 主机补双栈出口 | M-024（"套 WARP"定义） | 只有 IPv4 的机器想访问 IPv6 资源（或反之）时，用 WARP 提供另一端 |
| 2 | 服务器出站代理，防"出站利用"泄露源站 IP | M-019（成因 5） | 论坛"链接预览"类功能会由服务器主动爬取攻击者构造的链接 → 记录你的源站 IP；解法就是让服务器出站走 WARP |
| 3 | 容器化给应用注入代理 | M-017 | 在 compose 里跑一个 WARP 容器，给需要出境的服务注入 HTTP_PROXY/HTTPS_PROXY/ALL_PROXY（详见 9.7） |
| 4 | 解锁/出口 IP 变化（流媒体、区域限制服务） | M-024 / M-014 | 社区主用途；但注意 9.4 的风险 |
| 5 | 改善路由 / 绕开部分封禁 | M-024 | 社区说法；效果与线路强相关，不承诺 |
⭐ 用途 2 和 3 是本教程最该强调的：它们把 WARP 从"翻墙工具"变成了服务器安全工程手段——这与 M-019 的"源站泄露六成因"直接配套。
9.3 ⚠️ 最大的配置陷阱：默认模式 ≈ 全局代理
社区实测（M-009，⚠️ 机制细节待官方核验 F-060）：
- WARP / Cloudflare One Client 连接后，onboard profile 默认是"排除模式（exclude）"，等同于全局代理——「默认除本地流量外全部走 warp」（M9-2）
- 一旦连上，你被换到「广播到你所在省份附近 + 污染极其严重」的出口 IP（M9-4）
正确配法（M9-5）：把 profile 改成"包含模式（include）"，只让 100.96 开头的 CF 内网地址走隧道：
包含模式 + 仅 100.96.0.0/x → 只有私网/Mesh 流量走 WARP，其余走本地出口
默认排除模式 → 相当于全局代理（含所有公网流量）📌 这条与 §9.7 的"
NO_PROXY白名单"是同一个设计思想：必须显式声明"哪些流量走 WARP"，而不是让默认值决定。
9.4 风险：WARP ≠ 干净的境外 IP
社区多个独立案例（M-009 / M-014 / M-015）：
| 风险 | 现象 |
|---|---|
| IP 定位异常 | 「虽然外网可以访问，但是查看 ip 定位是国内，这样很多 ai 服务或者流媒体就上不去了」（M14-2） |
| 账号风控（送中） | 开 Cloudflare One 后访问 Google，「结合你的定位信息等 safety controls…你的 google 账号送中概率飙升」；作者实例：Pixel 上开 cfone 后当晚账号被送中（M9-4） |
| IP 质量判据 | 社区用「能否静默通过 CF 盾 / reCAPTCHA、访问 Gemini 是否送中」作为 IP 质量信号（M-015），而不是看 ping |
结论：不要假设"套上 WARP 就干净了"。是否可用，要按 §4.3 的同一逻辑——用真实请求（含风控信号）去测，而不是看延迟。
9.5 与 Tunnel 同机共存的故障（真实案例）
社区案例（M-013）：仅 IPv6 的机器加 WARP 后，重启即与 CF Tunnel 断连
cloudflared 用 --edge-ip-version 6 启用 IPv6 连接 → 成功
再添加全局模式 WARP（IPv4 出口、IPv6 优先）→ 当时正常
重启操作系统后 → 连不上 tunnel- 作者的临时处置：只在需要 IPv4 时才临时启用 WARP
- 社区猜测（未验证）：「是不是 DNS 变成了 ipv4」（M13-4）
教程给出的排查方向（不替读者下结论）：
| 排查项 | 命令/判据 |
|---|---|
| cloudflared 实际解析与地址族 | --edge-ip-version 与 --edge-bind-address 的取值（§6.2，后者会覆盖前者） |
| WARP 是否改写了默认路由/DNS | 对比启用前后的 route/resolv.conf/scutil --dns |
| 是否只有出站被劫持 | 用 curl --resolve 打固定边缘 IP 观察是否仍被重置（附录 A 的阻断判据） |
核心结论：在同一台机器上，Tunnel 的出站与 WARP 的出站会互相竞争（路由/DNS/地址族）。必须先决定"谁走 WARP"，再配 Tunnel。
9.6 Cloudflare Mesh 与"组网"（社区用法 + 待核验项）
社区（M-009）：
- 「cloudflare 有个 cloudflare mesh 功能，可以把多台 vps 通过 cloudflare 网络获得内网 IP 地址」（M9-1）
- 接入设备需用 Cloudflare One app；私网地址形如
100.96.x（M9-3） - 正当用法：「可以部分实现家里云（无公网 IP 的小服务器）的 SSH 穿透，以及多台 vps 之间 ssh 跟服务互相连接不公开公网」（M9-6）
- 社区另一条思路：线路机 + Cloudflare Mesh 连接器搭跳板机，再用内网路由访问其它资源（M-018）
官方核验结果（F-060，2026-09-14 查证）：三项社区说法全部被官方文档证实，并给出更准确的表述：
| 社区说法 | 官方对应事实（[DOC]） |
|---|---|
| "多台 VPS 通过 CF 网络获得内网 IP" | Cloudflare Mesh（原 WARP Connector）是官方产品：给设备/服务器分配 Mesh IP，彼此可按私网 IP 直连（客户端之间甚至不需要 Mesh 节点） |
"100.96.x 私网段" | 官方地址段是 100.96.0.0/12（官方示例 profile 就是 include: [{address: "100.96.0.0/12"}]） |
| "要改成包含模式" | 官方创建 profile 时就是 Include 模式：「只把 Mesh 流量路由到 Cloudflare，避免打断服务器原有网络」 |
| （社区未提） | 节点安装：warp-cli connector new <TOKEN>；协议要求 MASQUE（WireGuard 下 hostname 路由 / IPv6 CIDR / HA 不工作）；官方建议 MTU 1381 |
因此本章的立场可以写实：Cloudflare Mesh 是官方组网能力，且官方推荐的配置就是"仅 Mesh 段走 CF"——社区那条"默认排除模式 ≈ 全局代理、应改包含模式"的经验，与官方做法一致。
9.7 工程落地：把 WARP 当"出站代理"（M-017 范式）
# docker-compose.yml 追加
services:
warp:
image: caomingjun/warp
restart: always
networks: [app-net] # 与应用同网络
environment:
- WARP_SLEEP=2
# - WARP_LICENSE_KEY= # 可选 WARP+
device_cgroup_rules: ['c 10:200 rwm']
cap_add: [MKNOD, AUDIT_WRITE, NET_ADMIN]
sysctls:
- net.ipv6.conf.all.disable_ipv6=0
- net.ipv4.conf.all.src_valid_mark=1
volumes: ['./warp-data:/var/lib/cloudflare-warp']
app:
environment:
- HTTP_PROXY=http://warp:1080
- HTTPS_PROXY=http://warp:1080
- ALL_PROXY=socks5://warp:1080
- NO_PROXY=localhost,127.0.0.1,postgres,redis,.local # 内网/DB 不走代理要点（M-017）：
| 要点 | 说明 |
|---|---|
| 同端口双协议 | GOPR 默认 :1080 同时提供 HTTP 与 SOCKS5 |
Go 程序其实支持 socks5h:// | 原作者的结论已被源码证伪（F-061）：Go 的 Transport.Proxy 文档明确列出 http/https/socks5/socks5h，且 socks5 视同 socks5h（schemePort 默认 1080）。稳妥做法仍是统一写 http://host:1080——不是因为 Go 不支持，而是只有一种写法时不会出错 |
NO_PROXY 必配 | 否则内网、数据库、Redis 都会绕 WARP，得不偿失 |
| 生效方式 | docker compose up -d --force-recreate <app> |
⭐ 这个范式不要求每台机器装 WARP 客户端，只让需要出境的那个服务走代理——与 9.3 的"显式包含"原则一致。
9.8 边界（三句必须记住的话）
- WARP ≠ 干净的境外 IP（9.4）：定位异常、送中风险真实存在
- WARP ≠ Cloudflare China Network：它不提供境内节点、不解决 ICP/合规、不承诺跨境专线质量（§7.3）
- WARP 与 Tunnel 是两条独立通道：Tunnel 管入站可达，WARP 管出站路径；同机共存需显式分配流量（9.5）
9.9 决策清单
| 你的需求 | 用 WARP？ | 更合适的方案 |
|---|---|---|
| 家庭/机房内网只有 v4，要访问 v6 资源 | ✅ 用途 1 | — |
| 怕服务端出站请求泄露源站 IP | ✅ 用途 2（M-019） | 也可用任一出站代理 |
| 容器内某服务需出境 | ✅ 用途 3（M-017） | — |
| 想给整站加速（国内访问更快） | ❌ | 优选（§4/§5）+ 平台加速（§7） |
| 想给大陆用户提供境内交付 | ❌ | 官方 China Network（§7.3） |
| 想在内网多机之间互访 | ✅ 官方 Cloudflare Mesh（§9.6） | Tunnel + Access（§2）/ 组网工具（M-021/M-025） |
本章两条原「待核验」项均已结案：Mesh 与
100.96.0.0/12为官方事实（F-060✅）；Go 支持socks5h://为源码事实，原社区说法已证伪（F-061❌）。