前情提要：
几个网络小故逝（第一集）
几个网络小故逝（第二集）
几个网络小故逝（第三集）

原本只想写三集的，但是后来发现，上一篇已经足够长了，导致博客编辑器有些不太稳定。所以单独拆出来一个收尾的第四集。来聊聊NAT打洞的事情，以及笔者最喜欢的Cloudflare WARP。

如果你也是喜欢折腾网络的人，不妨进来看看笔者的胡说八道和天马行空。建议按顺序阅读，以便于最大化感受笔者的牢骚。

写到最后一集了，来个沙雕图片庆祝一下

1. 崩坏：回家通道

阿基维利来了都打不穿NAT

我们俗话说，有WiFi的地方就是家，有流量的地方就不是乡下。如果你正常上互联网访问各种有公网地址的服务器，那很好，毕竟随处可连接。但是如果你真的想连回家怎么办？

公众宽带接入，是个大市场，毕竟你服务器再多能有人口多？之前也提到过了，国内目前分到的IPv4数量长期处于『总量可观人均拉胯』的状态，想要用少数的IP喂饱绝大多数人，NAT就是其中一个（也是应用最广泛的）选择，他让一群人能够共享一个IP，大大节约了IP使用量。毕竟大多数人对于互联网的需求也就很简单，以连接到各大门户网站和内容网站为主，连接协议又以TCP和UDP为主，所以这么干很多情况下都没有什么毛病。

不过你能看到这里，就说明你应该有（或者想过）在家里跑点什么东西，有可能是你有一个NAS来存储数据，有可能是你有一台电脑要远程连接，或者更加常见的，你可能有一个支持多人联机的游戏，想通过P2P的方式和朋友联机玩游戏。以前你还可以申请到公网IPv4，之后可以快乐连接了，但是家宽的公网v4基本上可以认为消失在了历史长河中，某些地方还可以通过加钱的方式买上一个，但是其他地方都是统一口径，要公网v4就必须得开专线。或者你也可以使用公网v6，但是你既然都看到这里了，上面吐槽IPv6的内容应该也不用在这里再抄一次了。所以不论是上面的哪种情况，都意味着，你需要穿透NAT，从外面访问到NAT之后的世界，也就是你家。

首先澄清一下，这里并不会去讨论类似FRP/Ngrok之类基于中转的技术（包括通过VPN连接到公网服务器那种），毕竟虽然这里技术名字叫做『内网穿透』，但严格来说这些方式并没有『穿透』NAT，他只是一个正常的数据交换，只是流量主要的传输方式和普通上网并不太一致罢了，称其为反向代理也是可以的。

借用一张自己旧博客站的图片，这是当时的SakuraFRP后台，笔者用它来维持博客站运行

澄清完了，我们继续讨论。NAT穿透意味着要在NAT转换后的地址上开个端口，让从这个端口进来的流量能被转发到我们指定的IP上。本来类似这种用途是有很多正经解决方式的，比如手动在NAT上设置端口转发，比如通过NAT-PMP之类的协议通知对端设备打开转发，但问题在于我们的对手不是普通的NAT，而是运营商级别的NAT（CGNAT）。运营商不论是出于技术还是利益角度（比如不能让你家宽当专线），都不会给你开设这样服务。于是我们就只能做一些歪门邪道，通过NAT设备的固有特性（比如说针对不同目标地址和源地址的数据包映射规则）来实现我们的目的，所以这种技术就有了另一个很直白的名字：NAT打洞（hole punching）。

老规矩，关于打洞的具体原理和实现方法，这里就不深入讲述了，因为网上的资料一抓一大把，大致要说的话就是『通过UDP无连接的特性，配合NAT设备的转发规则，实现预期目标之外的通信』。但是笔者可以明确告诉你，这条路其实并不太好走。比如最典型的问题，NAT3到NAT4的打洞就已经非常困难了，而NAT4到NAT4的打洞就是几乎不可能实现的（除非你运气足够好，一下子猜对了，或者通过生日攻击等方式猜对了），只能回落到中转连接。所以如果你家里面是NAT3或者干脆就是NAT4的网络，你在外面的某个餐馆吃饭，发现餐馆WiFi提供的也是NAT4网络，那么就呵呵了。

即使是比较容易穿透的NAT类型，一般情况下，用于实现NAT穿透的协议一般都是UDP（TCP打洞确实存在，且客户端访问同样不需要额外配置什么软件，但要求打洞那一边是NAT1，这种类型的NAT比NAT3/4少很多，但好在比公网类型的用户多一些），而国内对于UDP的QoS估计各位都有目共睹：不是说不能用，而是各种花式恶心，比如高峰期丢包一半的，比如说单次传输多少MB又丢包的，速度太快也丢包的，甚至有更加丧心病狂的运营商，非TCP协议是直接限速的——是的，包括ESP和GRE之类的IP协议。

所以每次笔者看到公网IPv4用户能够端口转发一下就开始提供服务，总是心痒痒的。就目前来看，估计只能硬着头皮走IPv6的路了——所以你现在明白（上一篇文章的）题图的意思了吧：吃屎，还得笑着吃。

2. 赛博菩萨在云端

各种意义上的在云端

啊，Cloudflare，伟大的Cloudflare，被人称之为赛博菩萨是一点问题都没有的。

本站就运行在Cloudflare提供的CDN上，还顺便白嫖了一下他的邮件转发功能，所以你会看到本站联系邮箱的域名就是根域名。为了方便叙述起见，下文使用CF来指代Cloudflare。

2.1 CDN

选啊，怎么不优选了

CF的主要业务就是他的CDN（内容分发网络），能够把源站保护在CDN之后，再依托CF的全球网络，相当于免费给服务器提供了全球文件缓存和超强的扛打能力（目前CF扛下来的最大流量DDoS攻击，没记错的话应该是5.6Tbps），所以很多人都会去使用CF的CDN服务。更有甚至，有人实现了全站放在CF，也就是用R2做图床，Pages托管网页，D1做数据库，Worker做API和网页生成，再配合CDN做分发，完完全全做成了Serverless服务。

不过还是老规矩，能出现在《网络小故逝》系列里面的东西，自然有很多值得说道的地方，所以坐稳当了，我们现在开始唠嗑。

2.1.1 神奇的带宽

表面上看，CF提供的CDN服务器秒天秒地秒空气，但可惜事与愿违，CF的节点（不仅仅是CDN）在大陆地区很多地方都有减速器的名号，也就是套了本来用于加速的CDN服务之后，访问这个网站反而变慢了。这种情况的出现，得益于国内神奇的C-I-X-F跨境结构，以及运营商的各种小动作。所以根据资料来看，很反直觉的一点是，离大陆地区越近，带宽价格越高，所以你会看到这些情况：

• 低价区VPS中，美国VPS占比大，欧洲VPS紧随其后
• 香港/新加坡等地『优化线路』VPS价格较高
• 便宜的香港VPS会出现『三网绕美』的情况，也就是数据得从美国绕一圈
• 各种Linux软件源，即使没被墙，在大陆地区可达性也相当差
• 国外大厂VPN的机房，同上，甚至更惨

关于最后两点，笔者在此处举个例子，DataPacket.com。这是一家出售大带宽服务器的厂商——不是VPS，而是独立服务器，所以你能看到内存16G起步，CPU 6核起步，硬盘1TB起步，独享网络接入带宽10Gbps起步.....当然价格也很美丽：三位数美元起步，而且不能立刻交付，最好也得等4小时，最差的情况下得在14天内才能交付，说明机房内出售的确实是一台又一台的独立服务器。

不过这不是重点。既然上文提到，这些服务器最低都可以接独享10G的带宽（最高是单台服务器开到2x100G），那么VPN服务提供商应该会很喜欢这样的服务器。我们来看他给出来的Solutions页面，显然，VPN赫然在列——甚至下面还能看到NordVPN以及Mullvad VPN作为用户案例出现在里面。因为Mullvad VPN的服务器列表是公开的，我们可以很轻松在其中筛选到租用于DataPacket的服务器，作为佐证：

DataPacket官方有给出Looking Glass地址，比如说我们挑一个香港的地址，84.17.57.129，发起路由追踪：

乍一眼看上去好像还行，毕竟才80多延迟，稍微有点高，但是也不是不能用。出现这样现象原因也很简单，注意图中的第8跳，就是AS58453那个，出现这个东西说明出境线路走的是移动的CMI。移动CMI在当年是非常风光的（现在基本上也差不多，就是家宽用户除外），有句俗话说『广移拉AZ，AZ拉万物』（AZ就是Azure云），意思就是，通过广东移动（最好是商宽）连接香港Azure，就可以乘上AZ云的快车，到世界各地网络都非常好，甚至有了『穷逼专线』的美称。

CMI用户倒是舒服了，那么非CMI呢？找一个别的运营商的ping测试结果马上就能发现端倪：同一个香港节点，即使是离他最近的广东电信，延迟也很轻松飙升到200ms以上。根据光速和地球周长等知识可以很轻松知道，出现这个延迟，必然是到美国去绕了一圈所导致的，也就是上文提到的三网绕美。

我们的主角，Cloudflare，虽然用的是任播技术，但是默认配置给大陆用户（尤其是站长是免费用户时）的也就是美国节点：

SEA，代表西塔科机场，位于西雅图

出现上面这些情况的原因也非常简单：做大带宽生意的供应商，在面对国内这种神奇的跨境带宽费用时，自然不会特别地针对国内这一小部分用户（和全球用户相比）去购入高价优化带宽，因为成本受不住，或者说投入产出比并不高。所以国内用户访问的时候，就只能通过低价的美国线路去转接流量，导致延迟飙升，甚至有时候丢包增加。至于上面提到的CMI，那是一个特例，CMI属于是那种相对来说便宜大碗的，机房的接受程度会高一些，这才让『移动直连其他绕路』的情况变得多见。

而又因为目前绝大多数Web流量，包括在座各位的加密代理工具的流量，都基于TCP协议（QUIC目前采用还不多，而且UDP有UDP的惨，上面已经提到过了）运行，而TCP是很容易受到丢包和延迟所影响的。丢包影响的是流控，表现为某条TCP连接速度升起来很慢，而且掉速度很快，尤其是碰上了指数退避的情况时；延迟影响的是应答机制，更准确的说是会造成TCP长肥网络（LFN）问题，链路带宽大是大了，但是因为延迟高，大部分时间光用来等对方回答ACK了，导致TCP最高速度被卡在那，实际有效的传输时间并不多。这两个因素加起来，就导致了我们印象中的跨境TCP连接『慢』的问题。很多搭梯子的教程都告诉你，要打开服务器的BBR，或者当年有用锐速的，本质上都是对流控算法做一些改进，让他更适合目前流量传输的现状。（至于FinalSpeed，KCP，包括现在的Hysteria协议，那就是另一回事了，基本上可以认为这些软件是使用UDP重新实现了一个可靠传输层，以尽可能利用链路速度，所以不在本节讨论范围内）

2.1.2 优选的IP

CF的服务端是人家的，我们自然不可能去修改人家服务器的设置，也不可能给人家服务器多拉一点优化带宽，所以只能从客户端入手。CF作为大公司，手头自然是有不少IP段的，所以就可以在上面做文章：会不会有些IP段的效果，比其他的IP要好呢？

事实证明，确实是这样的。虽然CF是任播，但似乎给机房划分IP也有点偏好，比如作为移动用户，在一大票IP被分配到LAX（洛杉矶）或者SJC（圣何塞）的时候，曾经有某些特殊的段，比如1.1.1.0/24，是会被分配到HKG机房的，此时配合上文提到的CMI线路，那个质量不是一般的好。即使抛开选机房不谈，有些IP段不知为何，体质就是比其他的IP好一些（可能是专门给付费用户解析的IP？），所以大多数软件在测试完延迟之后，还会顺便测试一下下载文件的速度，从中挑一些下载速度快的节点出来使用。我记得这么清楚，是因为当年是这个段的钉子户：找一台美国VPS，搭建基于WS+TLS的协议，前置加上这个IP里的IP（没记错的话应该是1.1.1.7），然后就可以让自己家里的百兆宽带跑出来85M以上的代理速度，在当时体验是非常丝滑的。

优选IP主要的用途就是这几个，要么就是使用CDN作为梯子的前置代理，实现加速/复活被墙的机器，要么就是配合第三方解析（不靠第三方的话，免费版CF只能把域名托管上去使用，无法做到CNAME或者IP去指定加速）实现网站的加速访问。

很显然，这样的行为多多少少属于滥用，或者说是违反了ToS（服务条款）的行为，CF当然不会放过。于是去年十二月的时候，CF更新了ToS，在『2.2.1 Restrictions』中明确规定了『优选IP』和『用CF网络搭建代理』是违反服务条款的。所以以上的做法，基本上可以认为是已经失去了意义，也许小打小闹不会被系统看在眼里，但是量起来了，就很难说了。

2.2 WARP

好用的脚手架，就是有点裸奔

不知道为什么，也许是某些特别经历，也许是软件的UI，也有可能是单纯好奇，笔者对于VPN技术一直都比较感兴趣。经常提到的例子比如ExpressVPN的Lightway协议，比如AstrillVPN的OpenWEB（但是听他描述，这玩意非常类似于某种加密代理，而非真正的VPN），当然也少不了本节的主题：Cloudflare WARP。WARP的大名想必不用我多说，CF出品的，一款基于WireGuard（以及最新的MASQUE）的VPN。本来WireGuard就够快了，再配合WARP的底层网络（就是CF的全球任播网络），实现了就近入网，付费的WARP+用户还可以走CF的高速内网，访问托管在CF上的源站时更快回源。所以在没有连接干扰的情况下，WARP使用体验其实是非常好的。

不过还是那句话，小故逝小故逝，怎么会逝呢？

2.2.0 我们来连连看？

下面的内容写到一半，才想起来最好自己再测试一下连接情况，以便于行文。结果这一测试，就测试出来了新的结果。当然有一点需要说明，下面的测试结果与IP协议，时间段，运营商，省级政策等，有很大关系，因此不一定适合你所在的地方的情况。

测试环境：

• 中国移动，严格来说是广东移动
• 双栈接入
• Windows 10 22H2
• Cloudflare WARP 2025.6.1400.0

2.2.0.1 尝试连接

测试的时候发现了一件非常有趣的事情：安装好，笔者关掉了电脑上的Clash的代理设置（但核心保持运行），打开WARP，软件居然顺畅地解析到了地址，并连上了API，点击连接之后也能很快就连上，而且能正常使用，和一般认为的『已经被墙了』不符。

考虑到Clash的运行模式是代理模式，并非Tun模式，猜测有可能是信令/API等走了代理，又恰好碰上了一个没有被墙的节点地址，所以能正常使用。想要证明实际业务流量并没有通过日用梯子出去，也没有被局域网里面可能存在的透明代理干扰（因为笔者前两台在局域网里做了杏泉网络的单向对接），最简单的方法当然就是检查WARP获取的IP归属地（这一点下文还会提）。到网上查询，很显然证实了我们的猜测：

查询到的IP属于Cloudflare，但归属地属于大陆地区

Netflix显示Not Available（注意Netflix其实没有被墙）

一番排查之后，发现了问题所在：系统环境变量里面有HTTP_PROXY和HTTPS_PROXY设置，指向了Clash，导致被WARP读取并利用。排除方法也很简单，清除环境变量，关掉Clash，重新启动WARP，此时就无法正常连接了。

不过这个小意外倒是告诉了我们一件事：在某些地区，Cloudflare WARP的业务节点是没有被完全墙掉的，只是把API之类的墙掉了，就足以挡住绝大多数傻瓜用户了（毕竟WARP的设计就很傻瓜化）。因此下一步就很简单了，我们只需要给他提供一个稳定的信令代理环境即可。

WARP除了提供GUI程序，还有CLI程序。因此我们打开cmd，执行：

> warp-cli settings
...
Resolve via: cloudflare-dns.com @ [162.159.36.1, 162.159.46.1, 2606:4700:4700::1111, 2606:4700:4700::1001]
...

可以看到几个关键的IP地址，这就是WARP内部的DoH/DoT的地址了，由于此处已经给出了固定的IP，猜测可能是固化在程序内部的，因此我们需要确保这几个地址不被污染即可。因为上面提到，已经有用于杏泉网络的透明代理，看过我博客的朋友都知道，杏泉网络香港主节点就是平时科学上网的落地节点，所以只需要把需要代理的IP地址也转入到同一个节点，就可以正常获取内容了：

iptables -t mangle -A PREROUTING -d 162.159.36.1/32 -p tcp -j TPROXY --on-port 65530 --tproxy-mark 0x1/0x1
iptables -t mangle -A PREROUTING -d 162.159.46.1/32 -p tcp -j TPROXY --on-port 65530 --tproxy-mark 0x1/0x1
ip6tables -t mangle -A PREROUTING -d 2606:4700:4700::1111/128 -p tcp -j TPROXY --on-port 65530 --tproxy-mark 0x1/0x1
ip6tables -t mangle -A PREROUTING -d 2606:4700:4700::1001/128 -p tcp -j TPROXY --on-port 65530 --tproxy-mark 0x1/0x1

添加完代理，重启客户端，就能又像刚才那样丝滑连接了。

2.2.0.2 质量测试

连上了，也拿到了一个送中的IP，接下来自然就是测试一下。

首先是看看工作模式，很显然工作在MASQUE协议（下面还要提及）下：

抓包也能证明这一点，出现了大量的UDP 443流量

这是整个测试中最好玩的部分：居然还有没被墙的IPv4节点

然后是ping Google：

能正常ping，说明不是简单的四层代理，至少有一定的三层处理能力。

访问油管当然没有问题，而且因为是送中IP，没有广告（不在大陆地区做广告），速度的话，非高峰期看个1440P没啥问题，不过高峰期就难说了，毕竟是UDP流量。这里就不再给出截图了。

测试完毕，感觉下来就是，如果你能折腾明白如何正确连上WARP，那么你大概率也不需要WARP了。（洗IP除外）

2.2.1 入口的一条线

测完了WARP，现在是时候开始小故逝了。

2.2.1.1 WireGuard未照耀到的地方

在使用MASQUE之前，WARP曾经使用（目前似乎也还支持）的协议，是WireGuard。

WireGuard作为一款新晋（相对来说）的VPN，和他的前辈们一样，安全性没问题，但是并没有设计混淆性，无法抵御DPI系统的检测，而且这一点是在WireGuard的已知限制里面列出来的，第一项就是了。这一点从WireGuard的协议设计层面也能很轻松发现问题，加密握手时候是有固定形式的明文字段的，比如开头四个字节一般都是01 00 00 00。

而且，除了理论证明，实际抓包也能发现，即使像是WireShark这样简单的软件，也可以很轻松发现链路上正在进行WireGuard通信，更何况是某些更加高级的DPI设备呢？所以当年WireGuard刚刚出来的时候，网上还有很多教程教你如何搭建，甚至还一度有人称其为『Shadowsocks继任者』。但是等到尘埃落定之后，大家才发现，这个名号其实并不适合他。

此处演示使用IPv6连接，据说墙低一些

回到WARP上。WARP以前使用的是WireGuard，所以自然也无法避开这个命运。有人可能会说，CF的CDN不是听说有类似白名单之类的东西嘛，怎么WARP还是连不上呢？其实道理也很简单：

1. CDN并不支持代理WireGuard流量。这就是误解的最大根源。CDN一般情况下只能处理HTTP和HTTPS（后者还包括WebSocket和gRPC等流量），而无法支持WireGuard（也没给你开端口），所以自然无法享受CDN的好处（但至少还是CF自己的机房）
2. 入口IP段和CDN不同。翻阅官方文档可知，WARP在WireGuard模式下固定使用的是162.159.192.0/24这个IP段（IPv6也类似），所使用的端口也不是443，而是2408/500/1701/4500之类的VPN常用端口。很显然，这个段不和CDN地址重叠（虽然开放了443端口，但也只作为WARP应用程序注册等使用），真要屏蔽的话，简直是易如反掌。

（注：部分资料还指出，WARP还有不同的入口段，可能不仅仅局限于上面这个/24。但考虑到这些段依然是162开头，大体独立于正常CDN段之外，因此结论仍具有一定的可信度）

2.2.1.2 神奇的reserved字段

即使你在墙外面，比如海外VPS，你找到了一个第三方应用程序叫做wgcf的，用来产生WireGuard配置文件以供其他程序连接，你也会发现，有时候官方CLI客户端可以正常连接，但是生成配置文件后用第三方WireGuard客户端就连不上了。这种情况多发于香港地区的VPS，以及美国洛杉矶地区的部分VPS，甚至可能还会包括其他的地方。

其原因也很简单：上述地区的WARP使用了WireGuard中的一个保留字段，导致不提供此设置项的WireGuard客户端无法连接。

如图所示，标准情况下这三个字节应该全为0，而上述地区则需要一个不为零的特定值（通过WARP官方API去动态获取），才能连接到服务器。关于此值的作用，其实众说纷纭，有说是为了优化路由的，有说是为了防止滥用的，但总之一句话就是，没有这个值，你是连不上的。

2.2.1.3 MASQUE：新的希望？

互联网上从来不缺乏新技术，RFC9208 中定义的 MASQUE 就是其中之一。前段时间（差不多就是一两年前）刚推出的时候，网上的声音就和当时WireGuard刚推出的时候差不多的，基本上都是xx继任者，xx复活者这样的名号。但是实际用起来...至少笔者觉得，撑不了多久。

讨论MASQUE之前，得先说说QUIC。QUIC是基于UDP的一种可靠传输协议，其最大特点就是内置了TLS支持，换句话说这玩意能取代传统实现中的TCP+TLS。很显然，既然QUIC能实现安全性，那么一个很自然的想法就是，能不能在QUIC上面跑代理协议或者隧道协议，实现安全数据传输呢？巧的是，HTTP中本来就有一个类似功能的玩意，就是我们熟悉的HTTP CONNECT，可惜这玩意不支持UDP。所以，在这样的情况下，MASQUE应运而生。

根据RFC9208（以及RFC 9484），MASQUE可以看作是运行在HTTP3上的（基于QUIC，当然可以回退到HTTP/2，也就是基于TCP），支持TCP和UDP代理的，加密代理协议，VPN和加密代理的混合协议，可以和我们熟悉的Shadowsocks，VLESS+TLS，甚至最普通的HTTPS代理坐一桌的。引入加密代理功能，这样做也有一定的好处，最主要的就是可以更好处理当今互联网最普遍的TCP流量，和VPN协议直接传输三层数据包，导致TCP标头等也被封入隧道不同，代理协议是在本地终结TCP，把其中传输的数据分离出来进行处理，因此不必维持一条完整的跨洋的TCP连接，而且此时建立TCP连接的对象从目标服务器变成了代理服务器，因此你可以在代理服务器和客户端上做针对性优化（例如BBR），不像VPN那种只能原样转发，速度等体验会好很多——这一点其实也是笔者不建议在长距离高延迟高丢包链路上使用VPN的原因之一。

WARP选择加入MASQUE的支持，那自然是一件好事，因为原来的WireGuard已经可以被精确识别，换一个基于QUIC的协议透透气也不错，所以你能看到大批量的教程告诉你，『WARP复活啦，快开启MASQUE协议吧』。不过还是那句话，对于MASQUE的具体效果，笔者依然有一些顾虑：

1. 依然是固定的IP地址段：还是刚刚给出来的那个页面，虽然里面没有明确标出来WARP在MASQUE模式下的入口IP段是多少（应该是162.159.198.0/24），但是CF Zero Trust是有明确说明的，想用MASQUE，就要从162.159.197.0/24或者2606:4700:102::/48连接，所以依然存在上面提到的固定入口的问题。
2. HTTP3采用率有待提高：目前网络上流量占比较大的还是基于TCP的HTTP/1.1和HTTP2，而基于QUIC（UDP）的HTTP3不是说没有，而是还没有大量地被采用，因此就目前而言，MASQUE的流量依然算是较为明显。
3. SNI？根据一些报告所述，苟分王已经可以大规模解密QUIC首包，从而拿到里面包含的SNI值。笔者没有深入研究，不确定其他机制（如ECH）在这里是否能起到一定的抵抗作用，但是目前能看到的情况就是，已经可以根据解密后首包对指定域名的流量进行定向阻断了。

撰写时截图，图源：https://radar.cloudflare.com/，可以看到HTTP3的流量占比依然不算很大

2.2.2 出口的一片天

WARP，尤其是免费版，基本上可以认为是从机房直接出口到互联网。但是上文也说了，判断流量走向的最快捷方式就是判断出口IP的归属地——他所分配给用户的出口IP地址比较有趣，乍一眼看上去都是104开头的一系列IP，但是连接上去之后的归属地却会随着你实际所在位置而发生变化，譬如你在中国大陆连接的，会分给你某个城市的IP（不一定精确），你在海外的，就分配相对应地区的归属地的IP。所以上面我们看到落地IP归属地为大陆，就知道我们是在直连WARP，而并非通过代理服务器转发流量。

要想知道为什么出现这样的情况，就需要理解一个大前提：IP地址是没有『归属地』这个属性的，这只是一个由某些组织搜集起来的信息，所组成的属性。虽然我们会看到某某地区的NIC（比如APNIC，以及国内的CNNIC）负责分配某一段IP，但是除非有特殊的行政命令，否则没人拦着你拿某段IP地址去别的地方做广播（也就是BGP宣告，告诉其他路由器此IP在这个地方，请把流量转发过来）。比如我从ARIN（美国的）搞到了一段IP，却在香港做了BGP宣告（没错，这就是所谓的广播IP），那么虽然你的流量会被发送到香港，但是在各大IP库的记录里，这段IP依然归属于ARIN名下，所以一定还是归属于美国的IP。出现这种情况的时候，你就要去和各大IP库协调，比如有个比较著名的IP库叫MaxMind的，告诉他们，这段IP实际在香港接入，请把归属地信息改成香港。IP库厂家审核完毕之后，就可以更正了。但毕竟你不可能更正世界上所有的IP库（更何况还有万年不更新的离线IP库），所以广播IP在某些苛刻的场景下可能有些问题（也就是所谓的不如原生IP），但是日用上网问题不大。

通过逆向思维，想必你也能发现一个情况：假如我故意告诉这些IP库，我的这个IP属于某个不在接入点的地方呢？恭喜你，你参透了WARP的IP归属地不同的原理。上面举的例子是MaxMind，原因就是MaxMind与Cloudflare有合作关系，而且MaxMind也有自己的GeoIP Exchange项目，可以让CF之类的厂家提供批量的归属地修正。因此CF只需要把自己手头的IP段划分成多个部分，每个部分都修正为不同的IP归属地，然后再根据连上来的用户真实IP归属地，分配不同的IP以供NAT，就万事大吉了。

2025年11月24日 16:35 编辑：

有站外的朋友指出，IP所有者也可以通过GeoFeed（RFC8805，以及RFC9632）的方式，主动向IP归属地的数据库提交订正数据，这样会更快捷些。

这玩意的工作方式类似于Sitemap，也就是在自己站点上准备好CSV文件，让IP归属地数据库来拉取，根据规范，典型的文件格式如下：

# 格式：前缀,国家码,地区码,城市,邮编
# 国家码满足 ISO 3166-1 标准
# 地区码满足 ISO 3166-2 标准
# 城市与邮编为UTF-8文本，邮编常常省略

198.18.3.1/24,XQ,XQ-US,杏泉网络 - 美国洛杉矶,
198.18.4.1/24,XQ,XQ-HK,杏泉网络 - 香港,
198.18.5.1/24,XQ,XQ-HK,杏泉网络 - 香港,

# 除前缀外所有字段均为可选
# 全空通常表示 规划中/正在重新部署/计划用于任播

198.19.0.0/16,,,,

更进一步，前几年还有各种『朝鲜VPS』横行，让人恍惚以为三胖开始搞对外开放了。但即使抛...搬开三胖不谈，从技术层面上来说，朝鲜就不太可能提供运行VPS的能力，一个是对外带宽严重不足，一个是IP数量不够：朝鲜这一个国家，所分配到的IP段只有175.45.176.0/22共1024个IP，没有已知的IPv6分配记录，所以搞不好他们自己拿来用都不太够——当然也很难说，据说金日成综合大学只有一个还是多少个IP分配，甚至不如笔者所在的一个小大专院校，所以可能也暂时没用完。

这是朝中社，以及金日成综合大学，的IP解析

看完上面的内容你可能也猜到了，没错，这样的VPS就是用和类似CF的方式弄出来的。CF早年间在他的WARP出口地址段上保留了两三个IPv4，归属地划分为朝鲜，本来是给在朝鲜的外国人使用的，结果被一群人滥用了：

1. 滥用者先购买一段IPv6（因为便宜），在任意机房做广播
2. 然后向MaxMind请求IP归属地更正，更正为朝鲜
3. CF拿到了更正后的信息，认为这段IP属于朝鲜
4. 滥用者在VPS上发起WARP连接，WARP服务端给他分配了『朝鲜』IPv4
5. 到各大网站查询，得到朝鲜IP结果

当然CF不可能不知道这种滥用情况，于是在某次更新之后，这两三个归属为朝鲜的IP就被撤销掉了，如果真有在朝鲜的外国人连上的WARP，现在也只会分别的地方的IP了。

2.3 此路别通

机器秒变公交车

说完了WARP，我们再来聊最后一个东西。虽然这个不是CF官方出品，也不是预期用途，但毕竟涉及到安全问题（和钱包问题）因此值得一提。

CF的CDN承载了不少用户，其具体的工作原理可以追溯到远古时期的『虚拟主机』，也就是通过HTTP的Host标头（以及TLS的SNI字段）确定目前这条连接属于谁，然后提供相应的服务。所以不论是谁的域名，正确地在CF注册后解析到CDN节点，就可以用上CDN服务。

但是，上文也提到了，部分CDN节点在国内效果不算好，访客体验很差，因此部分想要使用CF功能（比如借助CDN隐藏源站），又想要获得较好体验的站长，想到了这么一个办法：

• 通过CF合作伙伴之类的形式，让域名解析和CF分开
• 找一台大陆连接效果好的VPS，在上面做端口转发，把80/443端口转发到CF的某个CDN节点的80/443端口
• 最后把自己的网站域名解析到这个VPS上

这么干，能不能用？当然是可以的，确实实现了高效连接，提升体验的作用。不过顶多到下个月，他们就会收到告警邮件，又或者是欠费通知——告诉他们，前置VPS流量已经耗尽了。显然，不可能是突然多了很多热情用户来访问网站，而是因为服务器的流量被人偷了。

问题出在第二步：单纯的四层端口转发无法解析上层流量内容，自然也不可能去判断转发的Host/SNI是不是想要的域名，不可能做白名单。所以有心之人完全可以借助你的VPS来为他的网站提供加速，甚至拿来跑大流量应用，比如下载内容，于是你的流量就耗尽了——而且此问题并非CF独有，你用任何一家CDN，理论上都会出现这种情况。另外，不要以为你转发端口这个操作没有他人知情，互联网上有大把的机器人在扫描网络空间（就是那些网络空间测绘平台），只要被扫到了，就可以用很轻松的方式来判断是不是这种傻瓜加速器：一个不是CF的地址却返回了CF的『不可直接IP访问』提示页，你说呢？

这个问题大规模出现在近几年，主要是因为两类用户，都是搭梯子用户：一类是前置套了CDN，嫌不够快，还买了流量转发平台的服务，结果把流量转发目标指向了CF的CDN；另一类用户是搭建了REALITY协议的，需要找一个网站打掩护，结果又是找了大型CDN平台的网站，且没做白名单，没做限速，于是又被偷走了。

如果你真的有此类需求，千万不可直接四层端口转发，至少通过nginx等程序做一下Host/SNI白名单。

写在最后

从六月份到九月份，过去了这么长时间，网络小故逝系列，这次是真的完结了。

说不好到时候还有没有续集，但是目前真的得暂时停一下脚步了。博客还会更新一些别的内容，也有可能更新放缓，因为笔者最近要忙的事情是一点也不少，专升本的，生活的，手头还有几个程序一直搁置想更新一下，当然还有之前提到的小说——虽然不发出来，但是一直没有进展，也不太好受。

就这样吧，时间也不早了，也许该去和周公约会了。

（完）