从更新《终末地》开始的大连理工大学校园网IPv6免流实践

Lentinel 发布于 11 小时前 44 次阅读

环境：Windows 11 / 大连理工大学开发区校区校园网 / 鹰角启动器1.6.0 / Cloudflare One Client 2026.8.2110.0
最终结果：不登录学校SSO，在原生IPv6通路上建立WARP MASQUE隧道；鹰角启动器可以收验证码、登录和下载更新，游戏本体可联网游玩；普通IPv4网站（含Bing、Google等）也能访问，更新速度约2～10 MB/s，存在波动。
声明：本文是特定校园网与特定时间的实测案例，仅在大连理工大学开发区校区校园网下测试成功，并非各高校通用配置，也不保证本校校园网系统未来升级后的长期可用性。另外，本文由GPT-6辅助撰写，AI味大的批爆，我自己都看不下去，但是我懒得码字了，反正内容准确性是没问题的。只想知道怎样免流的请直接跳转第12节省流。

0. 起因：只要连上Wi-Fi，就能用IPv6？

大连理工大学开发区校区的无线校园网，目前情况下即使没有登录统一身份认证系统（SSO），校园网服务器依然会给客户端分配IPv6，且能打开中科大IPv6测速站，说明基本的IPv6连接可用（有传言说校区会更新校园网系统，以后不登录认证就无法被分配IPv6，但是这个更新一直没实装）。而许多依赖IPv4的网站、应用和游戏启动器却不能正常工作，这是没登录校园网的正常现象。

恰好电脑上的《明日方舟：终末地》要大更新，我又没钱充流量，而如果单在这种仅连接未登录的情况下，虽然有IPv6连接，但是压根连接不到游戏更新服务器，基本等于没啥用。于是产生了一个问题，能不能把已经基本可用的IPv6通路利用起来，实现游戏更新免流？

1. 第一步：确认IPv6到底通到了哪一层

1.1 网络层：ICMPv6可达

PowerShell中执行：

ping -6 240c::6666

得到结果有3/4个回应，平均RTT约288 ms；后续也出现过50% ICMP丢包。至少证明，未认证校园网存在通往公网IPv6的路由，但Ping成功不代表HTTPS一定成功，ICMP丢包也不等于TCP具有相同丢包率。

1.2 DNS：Resolve-DnsName 与 curl 的结果为什么矛盾

执行以下命令：

Resolve-DnsName www.bilibili.com -Type AAAA -Server 240c::6666
curl.exe -6 -I --max-time 10 https://www.bilibili.com

前者返回过B站的CNAME链，终点却没有AAAA；后者提示：

curl: (6) Could not resolve host: www.bilibili.com

改用其他DNS测试：

Resolve-DnsName www.cloudflare.com -Type AAAA -Server 2606:4700:4700::1111

能够返回Cloudflare的AAAA地址。说明不能仅凭某一次域名解析失败，就认为IPv6外网被封锁。DNS服务器、CDN调度和系统解析器的结果可能不同。

1.3 绕开DNS测HTTPS：决定性证据

连手机热点网络查到了一个B站IPv6地址，然后在校园网电脑上用 --resolve 固定本次请求的目标地址：

curl.exe -6 -I -v --connect-timeout 10 --max-time 20 --resolve "www.bilibili.com:443:[2409:8c02:21c:b0::21]" https://www.bilibili.com/

得到：

Established connection to www.bilibili.com (... port 443)
HTTP/1.1 200 OK

这一步验证的是完整的IPv6 → TCP/443 → TLS → HTTP链路。--resolve 保留了URL主机名和正常TLS证书校验，并不是关闭HTTPS安全检查。这里的地址只是实验时可用的CDN节点，今后可能变化，不建议永久写入hosts。

阶段结论：校园网未认证时不只是能Ping某个IPv6网站，而是能直接访问部分公网IPv6 HTTPS服务。

2. 鹰角服务器为什么仍然无法直接连接？

用手机热点查询了这些鹰角相关域名：

$domains = @("launcher.hycdn.cn","launcher.hg-cdn.com","launcher.hypergryph.com","beyond.hycdn.cn")
foreach ($d in $domains) { Resolve-DnsName $d -Type AAAA -Server 240c::6666 -ErrorAction SilentlyContinue | Where-Object Type -eq AAAA }

在当时的解析条件下，都未发现可直接使用的原生AAAA记录。这不能证明游戏所有资源节点都不支持IPv6，只能说明被测试的域名与DNS返回结果不足以满足直接IPv6下载。

在游戏电脑上，登录接口最初无法发送验证码；但后续实验发现，只要能够提供IPv4出口，游戏更新本身也可以工作。于是问题从“鹰角是否支持IPv6”变为：IPv6能出校门，怎样让IPv6客户端访问只有IPv4地址的服务？

3. 第一条路线：DNS64 + NAT64

3.1 原理：DNS64负责合成地址，NAT64负责转发

假设某个CDN域名只有A记录、没有AAAA记录：

游戏启动器查询IPv4-only域名
              ↓
        DNS64解析器
              ↓
    合成可路由的IPv6地址
              ↓
校园网电脑 --IPv6--> 公共NAT64网关 --IPv4--> CDN

DNS64本身不会转发流量。 它只是在合适条件下把IPv4地址嵌入运营方使用的NAT64 IPv6前缀；真正的协议转换发生在NAT64网关。一个只有DNS64、没有配套可路由NAT64网关的配置无法实现完整访问。详细原理见RFC 6146、RFC 6147、RFC 7050。

3.2 为什么 64:ff9b::/96 没有成功

尝试标准的Well-Known NAT64前缀，把 1.1.1.1 表示成 64:ff9b::101:101：

ping -6 64:ff9b::101:101
Test-NetConnection 64:ff9b::101:101 -Port 443

结果是 TTL传输中过期 和 TcpTestSucceeded: False。TTL超时不是Ping成功，说明这个目标没有被有效转发，可能涉及错误路由或环路。这个前缀不是一个“全球默认公开NAT64服务器”，能否用取决于实际网络是否部署相应路由和网关。

另一个检查：

Resolve-DnsName ipv4only.arpa -Type AAAA

在校园网默认DNS下只返回SOA，没有合成AAAA，表明该解析路径没有提供可检测到的DNS64合成结果；它不能排除世界上其他公共NAT64服务可用。

3.3 试用公共NAT64

使用 nat64.net 公布的DNS64（本次测试中能访问的入口）：

2a00:1098:2b::1   （DNS64入口）
2a00:1098:2c::1   （DNS64入口）

先不修改系统配置，只进行显式查询：

Resolve-DnsName ipv4only.arpa -Type AAAA -Server 2a00:1098:2c::1
Resolve-DnsName launcher.hg-cdn.com -Type AAAA -Server 2a00:1098:2c::1

这次DNS64成功返回了以运营方前缀开头的IPv6地址。随后用合成地址进行HTTPS测试，例如：

curl.exe -6 -I --connect-timeout 8 --max-time 15 --resolve "launcher.hg-cdn.com:443:[2a00:1098:2b::1:3a4:4475]" https://launcher.hg-cdn.com/

实测返回：

HTTP=403
TCP connect ≈ 0.320 s
TLS handshake ≈ 0.651 s
ExitCode=0

403在这里并不是网络失败。 访问的是CDN根目录 /，服务器拒绝目录访问很常见；拿到HTTP响应意味着TCP和TLS已经完成。但它也不证明真实更新文件一定可下载。

比较多个网关合成地址，部分请求不到一秒成功，另一些连接超时；DNS64不同入口也会返回不同NAT64网关前缀，DNS地址和实际转发节点不是一一对应的。

3.4 Windows：为什么 Resolve-DnsName 成功，curl 仍解析失败？

最初的配置是：

WLAN IPv4 DNS：学校DNS（自动获取）
WLAN IPv6 DNS：空

用管理员PowerShell设置WLAN的IPv6 DNS：

netsh interface ipv6 set dnsservers name="WLAN" source=static address=2a00:1098:2c::1 validate=no
netsh interface ipv6 add dnsservers name="WLAN" address=2a00:1098:2b::1 index=2 validate=no
Clear-DnsClientCache
Get-DnsClientServerAddress -InterfaceAlias "WLAN"

这时：

Resolve-DnsName launcher.hg-cdn.com -Type AAAA

已经能看到DNS64合成地址，但 curl.exe -6 https://launcher.hg-cdn.com/ 仍提示解析失败。怀疑与机器同时启用IPv4/IPv6、不同DNS路径及系统应用解析方式有关；没有足够证据把原因严格归咎于某一个DNS服务器。

接着做了一个诊断性实验：暂时关闭WLAN上的IPv4绑定，保留IPv6：

Disable-NetAdapterBinding -Name "WLAN" -ComponentID ms_tcpip -Confirm:$false
Clear-DnsClientCache

然后：

[System.Net.Dns]::GetHostAddresses("launcher.hg-cdn.com")
curl.exe -6 -I -v --connect-timeout 10 --max-time 25 https://launcher.hg-cdn.com/

Windows系统解析器能列出合成的IPv6地址，curl 也开始自动尝试这些IPv6地址。首次自动连接超时，而手动测试部分合成地址成功，说明“域名解析是否能用”与“选中的网关是否畅通”是两个独立问题。

⚠️ 关闭IPv4绑定会改变网卡行为，可能暂时断网；它是本次为了排除IPv4路径干扰做的实验，不是所有Windows电脑都必须执行的通用操作。后文附恢复命令。

3.5 NAT64的实际成绩

在这种配置下，鹰角启动器能够识别更新并下载，速度在1~10MB/s之间频繁波动，并不稳定。

尝试登录启动器，发送短信验证码失败，始终提示网络错误。

因此NAT64路线得出的结论是：更新CDN中至少有一部分资源能够通过NAT64下载，但账号接口不一定兼容，或可能受境外出口、其他连接方式等因素影响，不能直接认为“鹰角账号服务完全不支持NAT64”。

此外，公共NAT64通常不保障带宽或可用性；大量用户直接拿个人维护的公共网关更新数十GB游戏，也不是值得推广的长期方案。

4. 第二条路线：Cloudflare WARP，最终采用的方案

由于我自己的阿里云ECS没有公网IPv6，无法直接做双栈中继，于是改为测试官方WARP客户端。

4.1 核心思路

未认证校园Wi-Fi
       |
       | 物理网络：IPv6
       v
Cloudflare WARP隧道（MASQUE）
       |
       | 由WARP虚拟网卡提供IPv4能力
       v
Cloudflare网络与IPv4出口
       ↓
鹰角登录服务 / 游戏更新CDN

与NAT64最大的区别：NAT64依赖域名解析合成IPv6地址，且程序需要能够正确走IPv6；WARP则建立IP层隧道，向应用提供可使用的IPv4网络能力，因此对IPv4-only应用往往更兼容。

安装好WARP客户端后，在「设置」里选 “流量和DNS（UDP）”，然后回到主页点击「连接」。这里的“UDP”描述的是隧道内的DNS查询方式，不是“只代理DNS”，更不等于“使用WireGuard”。Cloudflare官方的模式说明明确区分了DNS-only和Traffic and DNS。

4.2 证实WARP真正提供了IPv4出口

实测：

Status update: Connected
Network: healthy

同时，物理WLAN的IPv4绑定仍处于禁用状态：

Get-NetAdapterBinding -Name "WLAN" -ComponentID ms_tcpip
Name  ComponentID  Enabled
WLAN  ms_tcpip      False

但通过下面的命令，IPv4网站已经可以访问：

curl.exe -4 --noproxy "*" -sS --max-time 15 https://www.cloudflare.com/cdn-cgi/trace | Select-String "ip=|colo=|warp=|gateway="

关键输出：

ip=104.28.208.136
colo=HKG
warp=on
gateway=off

再检查网卡，能够看到 CloudflareWARP 虚拟接口获得了 172.16.0.2 这样的IPv4地址。于是可以比较有把握地认为：在这台机器上，应用的IPv4访问已通过WARP隧道恢复；而不是依靠未认证校园WLAN的IPv4出口。

注意 colo=HKG 表示该诊断请求到达Cloudflare香港边缘，不代表所有游戏流量都固定走香港，也不表示可以手动指定香港作为WARP出口。warp=on 才是这次诊断请求使用WARP的关键证据。

4.3 业务层验证：验证码与下载都成功

切换WARP后，之前始终报“网络错误”的验证码发送恢复正常，鹰角启动器可以登录；《终末地》的更新也能继续。实际速度虽然仍波动，但最终大致落在2～10 MB/s，对于免费下载游戏的要求来说够够的了，不敢奢求太多。

这是整个实验中比测速更重要的成果：不仅HTTP测试成功，真实软件的登录和游戏下载都能工作。

4.4 WireGuard失败：卡在Happy Eyeballs

好奇另一种协议是否更快，尝试：

& $warp disconnect
& $warp tunnel protocol set WireGuard
& $warp connect

结果客户端一直显示正在执行Happy Eyeballs相关连接过程，隧道无法恢复，电脑断网。这只能证明这次校园网环境下WireGuard没连成；怀疑与目标地址、UDP端口或网络策略有关，但没有抓包，不能确定根因。Happy Eyeballs本身是一种在多种候选地址或连接路径之间尽快选择可用路径的机制，不是独立的错误代码。

恢复到已验证可用的MASQUE：

& $warp disconnect
& $warp tunnel protocol set MASQUE
& $warp connect
& $warp status

恢复后再次显示 Connected / Network: healthy。因此最终保留MASQUE，不再折腾WireGuard。

5. 真正的测速：不要拿Ping或TCP握手时间代替吞吐量

一开始我们比较过NAT64网关的TCP连接速度，也测试过fOxO Anycast的DNS64/NAT64。fOxO对CDN的三个HTTPS测试都成功，最快TCP建连只有约0.2秒，但实际游戏更新速度跌至约200 KB/s。

教训：握手快 ≠ 大文件下载快。吞吐量还取决于丢包、拥塞控制、服务器限速、路由和CDN调度。

5.1 两次失败的测速尝试

  • speed.cloudflare.com/__down?bytes=100000000 返回HTTP 403、只收到1字节，完全不能当作带宽测量。
  • 某测试站点出现 SEC_E_WRONG_PRINCIPAL（HTTPS证书名称不匹配），属于TLS验证失败，也不能据此认定NAT64完全不可用；没有必要加 -k 绕过验证。

5.2 WARP东京与新加坡：不同目的地差很多

用 curl.exe 下载Vultr的测试文件，且写入 NUL，避免把磁盘写入算进测试：

curl.exe -4 --noproxy "*" -L --range 0-49999999 --connect-timeout 10 --max-time 45 -o NUL -w "HTTP=%{http_code} Bytes=%{size_download} Speed_Bps=%{speed_download} Time=%{time_total}\n" https://hnd-jp-ping.vultr.com/vultr.com.100MB.bin

同样的命令改为 https://sgp-ping.vultr.com/vultr.com.100MB.bin：

目标 接收量 耗时 平均速度 结果
东京 50,000,000 B 8.66 s 5.77 MB/s HTTP 206，完成
新加坡 46,972,465 B 45.01 s 1.04 MB/s HTTP 206，超时未完成

测速服务器不同，不能直接认为WARP东京节点优于新加坡节点，只是说明目的地不同可能出现显著速度差异。

5.3 对同一个东京服务器进行文件测试（WARP与NAT64）

进一步将目标统一为东京测试站，分段下载20,000,000字节，每条路线两次，计算各组平均速度：

路线 第一次 第二次 两次平均
WARP MASQUE 2.30 MB/s 9.28 MB/s 5.79 MB/s
nat64.net DNS 2b 1.82 2.21 2.02
nat64.net DNS 2c 2.08 1.47 1.77
nat64.net DNS 4f9 1.49 2.89 2.19
nat64.net DNS 4f8 1.89 2.36 2.12

这里的 2b / 2c / 4f9 / 4f8 是查询所选DNS64入口的标签，不是实际NAT64网关的严格标识：实验中向 2b 查询也可能返回 2c 前缀的合成地址。

本轮WARP的两次均值约5.79 MB/s，四组NAT64的整体均值约2.02 MB/s。 样本仅两次且波动较大，不能当成长期稳定带宽排名；但结合登录成功与游戏下载情况，已经足以支持本机优先保留WARP MASQUE。

为了复现实验，一个不改变系统配置的WARP单项测速命令即可：

curl.exe -4 --noproxy "*" -L -sS --range 0-19999999 --connect-timeout 8 --max-time 35 -o NUL -w "HTTP=%{http_code} Bytes=%{size_download} Speed_Bps=%{speed_download} Time=%{time_total}s`n" https://hnd-jp-ping.vultr.com/vultr.com.100MB.bin

只有 HTTP=206、Bytes=20000000、ExitCode=0 同时满足时，才把这一次视为完成的有效速度样本。不要把报403或超时的请求照样算进平均带宽。

6. 有没有可能是磁盘或游戏启动器的问题？

这台机器使用SSD，任务管理器中游戏安装盘活动时间约1%。同时在Windows资源监视器（Win + R → resmon → “网络”）中看到：

  • Games.exe，来自 E:\Games\Hypergryph Launcher\1.6.0\Games.exe，属于鹰角启动器；
  • 接收速度快时约5.8～6.7 MB/s；
  • 高流量远端曾出现 155.102.181.141，后一次是 155.102.181.140；
  • 182.239.104.60 确实出现过在更新资源域名的解析结果和某次连接里，但它不一定是那一刻真正主要的下载连接。

这说明磁盘持续写入饱和的可能性较低，网络实际接收确实波动。但无法仅凭这些结果区分WARP链路、CDN服务端、下载线程调度哪个才是主要瓶颈。另外，IP变化是CDN常见现象，不值得把每个IP都当作“最优节点”固定到hosts。

最终我们的目标也不是写论文一样定位每一毫秒的波动，而是选择整体能用、平均传输表现更好的路线。

7. 简化版校园网IPv6免流复现指南

前提：你自己的网络在未认证时确实允许公网IPv6 HTTPS流量，且你有权限使用它。不同学校不一定具有这一特性。下面不保证启动器版本或WARP行为永远一致。

A. 不动系统设置，先验证IPv6

ping -6 240c::6666
Resolve-DnsName www.cloudflare.com -Type AAAA -Server 2606:4700:4700::1111

如果 curl -6 因系统DNS失败，先修正解析问题，而不是只看Ping。如果能拿到可信的目标站点IPv6地址，可临时使用 curl --resolve 验证HTTPS；不要依赖上文的历史CDN IP长期有效。

B. 安装官方WARP客户端

官方安装说明：https://developers.cloudflare.com/warp-client/get-started/windows/

  1. 安装官方Windows WARP / Cloudflare One Client；如果初次安装需要普通网络，可以短暂借用正常网络完成安装初始化，但不要用手机热点下载整包游戏。
  2. 模式选择 “流量和DNS（UDP）”，而非“仅DNS”；保持MASQUE。
  3. 点击连接。不要先动高级分流、加密密钥、Split Tunnel设置。
  4. PowerShell测试：
$warp = "C:\Program Files\Cloudflare\Cloudflare WARP\warp-cli.exe"
& $warp status
curl.exe -4 --noproxy "*" -sS --max-time 15 https://www.cloudflare.com/cdn-cgi/trace | Select-String "ip=|colo=|warp="

期望看到 Connected 和 warp=on；若当前物理Wi-Fi根本没有IPv4出口，却可以 curl -4 成功，说明WARP的虚拟网络确实承担了IPv4访问。

重要提醒：本次实验为了排除IPv4干扰曾在WLAN禁用IPv4，这不是每个人安装WARP都必须做的前置操作。只要可以确认WARP在自己的环境里实际通过IPv6接入即可；不要在远程维护的电脑上轻易禁用IPv4。

C. 若WARP无法连接，NAT64可作为研究和备用方案

Resolve-DnsName ipv4only.arpa -Type AAAA -Server 2a00:1098:2c::1
Resolve-DnsName launcher.hg-cdn.com -Type AAAA -Server 2a00:1098:2c::1

能合成AAAA是第一步，接下来还必须验证对应网关的TCP/TLS可达性，且应用要能走IPv6。仅修改DNS不等于已经获得IPv4互联网能力。公共NAT64网关的免费资源与使用条款应受到尊重，不建议把它当成可无限制使用的高速下载器。

8. 临时回滚与救援命令（完整版见第12节）

以下操作需要管理员PowerShell，假设无线网卡别名是 WLAN。先运行 Get-NetAdapter 核对名称。实际使用时，只恢复自己改动过的项目：

# 如果曾禁用过WLAN的IPv4，重新启用
Enable-NetAdapterBinding -Name "WLAN" -ComponentID ms_tcpip

# 如果曾给WLAN手动配置过IPv6 DNS64，把IPv6 DNS恢复为自动获取
netsh interface ipv6 set dnsservers name="WLAN" source=dhcp

# 清理DNS缓存
Clear-DnsClientCache

# 如需关闭WARP隧道
& "C:\Program Files\Cloudflare\Cloudflare WARP\warp-cli.exe" disconnect

# 检查当前网卡配置
Get-DnsClientServerAddress -InterfaceAlias "WLAN"
Get-NetAdapterBinding -Name "WLAN" -ComponentID ms_tcpip

如果电脑原本就有人工设置的IPv6 DNS，不要盲目改回DHCP，应先备份再按原值恢复。禁用网卡绑定、切换WARP都可能导致短暂断网；如果通过远程桌面操作，应准备本机恢复手段。

9. 一些问题的说明

  1. “没登录SSO”不等于“所有公网协议都放通”。我们只证明了这条校园网在测试时允许特定IPv6连接及WARP隧道。
  2. “能访问IPv6测速站”不等于“任何软件都能工作”。游戏登录、CDN下载、游戏服务器等等可能是不同域名与不同协议。
  3. DNS64不是代理服务器。它负责地址合成，NAT64才负责网络层转换；有DNS64没NAT64不行。
  4. 64:ff9b::/96 不是免费全球NAT64出口。标准地址格式需要真实可用的转换设施。
  5. HTTP 403不总意味着TCP/TLS失败。本次CDN根目录的403反而证明到达了对端HTTP层，但不等于资源URL可下载。
  6. WARP “流量和DNS（UDP）”不是“仅DNS模式”。同时也不能把其中的UDP理解成WireGuard。
  7. warp=on、虚拟IPv4地址、WLAN IPv4禁用，是相互印证的证据。单独看到 colo=HKG 不等于你所有流量都经香港。
  8. TCP握手低延迟不意味着高吞吐量。fOxO的握手成功率很高，实际游戏更新却只有约200 KB/s。
  9. 不要把403、证书错误或超时样本当作有效下载测速。核对HTTP 206、完整字节数、退出码。
  10. 下载IP变化不是问题本身。观察过 .140 和 .141 等主要流量节点，没理由据此认定固定某一IP就能更快。
  11. 没有账号不代表没有网络行为记录。学校可有独立于SSO的网络准入、审计和使用规范，是否计费或允许使用应以管理规定为准。

10. 阶段性成果：游戏下载免流已解决

一开始的情况还是，校园网Wi-Fi未登录SSO，也能访问中科大IPv6测速站。

我们依次验证了ICMPv6、IPv6 DNS和IPv6 HTTPS；发现鹰角若干服务域名缺乏可直接使用的AAAA；测试了标准NAT64前缀（失败）、公共DNS64/NAT64（成功下载但账号验证码失败）；排除了自己VPS没有公网IPv6的中继方案；最终使用Cloudflare WARP的MASQUE隧道，让原本只有IPv6外网的游戏电脑获得了可用的IPv4访问能力。

实测，鹰角启动器验证码正常、登录正常、更新正常，游戏更新下载约2～10 MB/s，仍有波动但可接受。 东京测试站的短时WARP测速均值在对比中明显优于公共NAT64；WireGuard尝试未连接成功，因此保留MASQUE。

11. 科普环节：没登录SSO、没开梯子，为什么连Google和IPv4游戏服务器都能访问？

折腾完之后发现，现在启动器能收验证码、游戏本体能够登录和游玩（延迟在几百ms左右），中科大IPv4测速站、必应，甚至一般情况下连不上的谷歌油管也能访问，并没有挂梯子。

乍看似乎矛盾，物理WLAN的IPv4明明已经关闭，学校IPv4出口又要求SSO，为什么各种IPv4应用反而都能工作？

11.1 先区分物理接口与逻辑接口

在Windows上，“是否具有IPv4网络能力”和“无线网卡是否启用IPv4”不是同一回事。我们当时获得了以下三个相互支持的证据：

Get-NetAdapterBinding -Name "WLAN" -ComponentID ms_tcpip
Get-NetIPConfiguration | Where-Object IPv4Address | Select-Object InterfaceAlias,IPv4Address,IPv4DefaultGateway
& "C:\Program Files\Cloudflare\Cloudflare WARP\warp-cli.exe" status

观测结果：

WLAN / ms_tcpip / Enabled=False
CloudflareWARP / IPv4Address={172.16.0.2}
Status update: Connected
Network: healthy

这说明：物理无线网卡的IPv4协议绑定被关闭了，但系统仍然有一张由WARP创建的虚拟网络接口，并能在这张逻辑接口上处理IPv4数据包。

Windows在选择下一跳时参考路由表，具体哪些流量走WARP还受客户端模式、Split Tunnel等配置影响。它不是靠WLAN自己直接发送IPv4帧穿越校园网。

11.2 从浏览器请求到校园网链路：到底封装了什么？

以访问一个只有IPv4地址的HTTPS服务为例，可以把过程拆成五步。

① 应用正常使用IPv4。 浏览器取得目标IPv4地址，建立TCP/HTTPS连接；应用通常不知道底层校园网是否允许原生IPv4出口。

② Windows将数据交给WARP虚拟接口。 在当前全隧道配置下，公网IPv4流量通过路由被交给WARP客户端（若配置了排除规则，实际路由可能不同）。

③ WARP在现有IPv6通路上建立MASQUE隧道。 MASQUE不是把IPv4地址“翻译成IPv6地址”，而是把原有IP数据包通过加密的隧道协议运送到远端。Cloudflare文档确认MASQUE使用HTTP/3；从原理上可以理解为：

应用要发送的原始数据：
    [IPv4][TCP/UDP][应用负载]
             |
             v
由WARP交给MASQUE隧道：
    [外层IPv6][UDP][QUIC / HTTP/3 / MASQUE加密承载]
                         └── 原始IP包的隧道表示
             |
             v
校园网只负责转发可到达Cloudflare的外层IPv6数据

这个图是逻辑示意，而不是逐字节的抓包结果；例如连接标识、隧道数据报和加密记录的具体格式不能直接用图中的方框代替。MASQUE代理IP数据包的标准机制可参阅RFC 9484（CONNECT-IP）。

④ Cloudflare接收并转发。 远端终止隧道后，从Cloudflare网络将请求送往IPv4目的地。对网站而言，它看到的是所分配的出口IP，而非这台电脑无线网卡上的IPv6地址。

⑤ 响应返回。 服务器的回复先抵达远端，再经隧道返回本机，由客户端还原为应用可以处理的IP流量。

因此，原本需要校园网IPv4出口才能访问的应用，可以在具备互联网IPv6连通性的底层之上获得逻辑IPv4网络。

11.3 证明？

当时执行的是（注意 --noproxy "*"，不使用curl的显式代理配置）：

curl.exe -4 --noproxy "*" -sS --max-time 15 https://www.cloudflare.com/cdn-cgi/trace | Select-String "ip=|colo=|warp=|gateway="

得到：

ip=104.28.208.136
colo=HKG
warp=on
gateway=off

结合WLAN IPv4被禁用、WARP虚拟网卡有IPv4、curl -4 成功、warp=on，可以很有把握地确认：这次被检测的IPv4请求确实通过了WARP。

但这里有几个要点：

  • ip=104.28.208.136 是当次请求观测到的出口IP，不是固定公网地址。
  • colo=HKG 表明该次Cloudflare诊断请求落在香港的边缘节点；不代表任意游戏连接都固定从香港进出，更不是用户选择的“香港节点”。
  • warp=on 表明该次请求经过WARP，而非证明电脑上所有进程、所有目的地在任何时刻都绝对走同一路径。比如虚拟机网络、局域网和例外路由可能不同。
  • 在浏览器里打开Google、Bing是当时的使用体验记录；我们没有针对每个浏览器请求抓包，不能把所有访问路径都当成逐包验证过的事实。

想排除其他代理的干扰，可以做下面的附加测试（仅测试，不改系统设置）：

curl.exe -4 --noproxy "*" -I --connect-timeout 10 --max-time 20 https://www.google.com/
curl.exe -4 --noproxy "*" -sS --max-time 15 https://www.cloudflare.com/cdn-cgi/trace | Select-String "ip=|colo=|warp="

若第一条获得正常HTTP响应，第二条仍显示 warp=on，就能比“浏览器能打开”更直接地证明这条IPv4请求路径可用。某些网络和地区可能无法复现，不应理解为WARP对任何受限网站都提供保证。

11.4 为什么校园网没有拦下这些IPv4网站？

我们没有获得校园网的原生IPv4使用权限，也没有看到学校内网认证系统被修改。根据实测，更准确的解释是：

  • 学校当时允许未认证终端访问某些公网IPv6资源；
  • WARP的加密隧道外层使用了这条可用的IPv6通路；
  • 网站访问所需的IPv4流量在隧道内部传送，真正的IPv4出口不再是学校原生IPv4网关。

因此，“校园网IPv4需要SSO”与“通过已放通的IPv6建立远端网络出口”可以同时成立。不同学校的IPv6准入、策略路由、防火墙和流量管理可能完全不同，本文不能由现象反推出学校设备的具体配置。

这也不代表学校无法检测或管理：网络仍可观察外层目的IP、协议、端口、连接时间和流量规模，并可采取相应管理措施。是否允许这种用途，应以校园网规定为准；不能因没有登录账号就推断“没有记录或不受管理”。

11.5 WARP和v2rayN到底有何区别？

对比项 典型v2rayN使用方式 本次WARP MASQUE
接入形式 常见为本地HTTP/SOCKS代理；也可启用TUN 客户端建立IP层隧道与虚拟网络接口
应用是否要单独配置代理 取决于系统代理/TUN/软件支持 当前全隧道模式下通常不需要逐个配置
底层传输 取决于所配置节点与协议 本次借助校园网IPv6建立MASQUE
IPv4出口 自己配置的代理服务器 Cloudflare网络提供的出口
能否选择固定出口地区 取决于已有节点 普通WARP不提供按国家任意挑选出口的功能
隐私与用途 由所用代理、服务器和协议决定 WARP是网络隧道，不等于匿名服务

所以“没开v2rayN也能访问Google”的含义，并不是v2rayN被神奇地替代成了同一种代理协议，而是Windows已经有了另一条可用的加密出网通道。Cloudflare明确提醒，WARP不提供匿名性，也不设计为任意伪装出口国家的工具。

11.6 为什么游戏能玩，但延迟有几百毫秒？

这是境外转发路径与校园网原有IPv6高延迟共同作用的结果。假设游戏服务器在国内，正常校园网IPv4连接通常可以直接走国内网络；而当前的游戏流量需要先通过校园网IPv6进入WARP，再由Cloudflare网络转发至服务器：

直接访问：电脑 → 校园网IPv4出口 → 国内网络 → 游戏服务器
免流连接：电脑 → 校园网IPv6 → WARP接入与转发网络 → 游戏服务器

一方面，WARP可能让原本在国内完成的通信绕经境外网络。我们曾在Cloudflare的诊断页面看到 colo=HKG，说明那次测试请求到达香港边缘节点；这支持存在境外中转的可能，但不能证明游戏的所有流量都固定经香港，更不能据此确定具体出口路线。跨境互联、绕路和拥塞都会增加时延。

另一方面，校园网这条原生IPv6链路本来就不算快。 在配置 WARP 以前，ping -6 240c::6666 的平均往返时延已经约为288 ms，还出现过丢包。这只能说明到那个特定IPv6 DNS目标的路径表现不佳，不能把288 ms当作游戏服务器的固有延迟，也不能直接与游戏延迟相加，但它确实提示底层IPv6出网质量可能也是原因之一。

因此，游戏里看到数百毫秒延迟并不意外：校园网 IPv6 到外部网络的路径可能已经偏慢，再叠加 WARP 转发、可能的境外绕行以及链路拥塞，整体延迟就会比较高。MASQUE 封装、丢包重传、无线链路质量和游戏本身的延迟统计方式也可能产生影响，但没有同目标对照测试，不能确定各因素分别贡献了多少，更不能说主要是加密运算造成了几百毫秒延迟。

延迟高但下载还能达到约10 MB/s左右也不矛盾。RTT 和吞吐量是不同指标：举例来说，若速度为10 MB/s、RTT为0.3 s，带宽时延积约为 10 × 0.3 = 3 MB，足够大的传输窗口及多连接下载可以帮助维持高吞吐量。

对于竞技类FPS来说，几百毫秒会非常明显；而《终末地》在实际体验中仍可游玩。所以这种情况下的免流不适合对延迟有高要求的使用环境。

12. 省流：说了这么多，校园网IPv6免流究竟如何操作？

记得先安装Cloudflare WARP的Windows客户端。

12.1 哪些设置是会被修改的

项目 初始状态 最终状态 复原方法
WLAN IPv4协议绑定 启用 禁用 重新启用 ms_tcpip
WLAN IPv4 DNS 当时显示学校DNS 202.118.66.6 未主动修改IPv4 DNS 不动IPv4 DNS配置
WLAN IPv6 DNS 自动获取，查询结果显示为空 手动nat64.net DNS64 恢复自动获取
Cloudflare WARP 未连接 MASQUE已连接 断开；软件可保留
WARP客户端模式 不适用 “流量和DNS（UDP）” 重新连接前确认模式

12.2 操作前备份当前状态

在管理员PowerShell中执行。本文假设无线网卡名称为 WLAN，其他电脑先通过 Get-NetAdapter 确认名称。

$nic = "WLAN"
Get-NetAdapter -Name $nic
Get-NetAdapterBinding -Name $nic -ComponentID ms_tcpip
Get-DnsClientServerAddress -InterfaceAlias $nic
Get-NetIPConfiguration -InterfaceAlias $nic
& "C:\Program Files\Cloudflare\Cloudflare WARP\warp-cli.exe" status

把输出保存为文本或截图，尤其要保存此前已经存在的手动DNS、特殊路由、VPN配置。不要在远程桌面或无人值守电脑上直接改网卡绑定，因为操作本身可能导致连接中断。

12.3 脚本A：恢复到正常网络配置

$nic = "WLAN"
$warp = "C:\Program Files\Cloudflare\Cloudflare WARP\warp-cli.exe"

if (-not (Get-NetAdapter -Name $nic -ErrorAction SilentlyContinue)) {
    throw "找不到名为 $nic的网卡，请先运行Get-NetAdapter核对名称。"
}

Write-Host "[1/5] 断开WARP" -ForegroundColor Cyan
if (Test-Path $warp) { & $warp disconnect }

Write-Host "[2/5] 启用WLAN IPv4" -ForegroundColor Cyan
Enable-NetAdapterBinding -Name $nic -ComponentID ms_tcpip -Confirm:$false

Write-Host "[3/5] 恢复IPv6 DNS自动获取" -ForegroundColor Cyan
netsh interface ipv6 set dnsservers name="$nic" source=dhcp

Write-Host "[4/5] 清理DNS缓存" -ForegroundColor Cyan
Clear-DnsClientCache
Start-Sleep -Seconds 5

Write-Host "[5/5] 检查最终状态" -ForegroundColor Green
Get-NetAdapterBinding -Name $nic -ComponentID ms_tcpip
Get-DnsClientServerAddress -InterfaceAlias $nic
if (Test-Path $warp) { & $warp status }

预期：WLAN / ms_tcpip 的 Enabled=True；IPv6 DNS不再固定为nat64.net；WARP显示未连接。若此时不登录校园网SSO，IPv4网站再次打不开属于预期现象，因为恢复的是学校原本的准入路径。

如果你的WLAN原本就是静态IPv6 DNS，千万不要照搬 source=dhcp；应根据12.2节备份恢复到原值。若客户端设置了自动连接，还需在WARP图形界面关闭自动连接，避免它在下一次开机自行启动隧道。

12.4 脚本B：开启IPv6免流状态

$nic = "WLAN"
$warp = "C:\Program Files\Cloudflare\Cloudflare WARP\warp-cli.exe"

if (-not (Get-NetAdapter -Name $nic -ErrorAction SilentlyContinue)) {
    throw "找不到WLAN，请先确认网卡名称。"
}
if (-not (Test-Path $warp)) {
    throw "未找到WARP CLI，请先安装官方客户端并完成首次注册。"
}

Write-Host "[1/7] 断开原有WARP连接" -ForegroundColor Cyan
& $warp disconnect

Write-Host "[2/7] 配置nat64.net DNS64" -ForegroundColor Cyan
netsh interface ipv6 set dnsservers name="$nic" source=static address=2a00:1098:2c::1 validate=no
netsh interface ipv6 add dnsservers name="$nic" address=2a00:1098:2b::1 index=2 validate=no
Clear-DnsClientCache

Write-Host "[3/7] 检查校园网IPv6及DNS64" -ForegroundColor Cyan
ping -6 240c::6666
Resolve-DnsName ipv4only.arpa -Type AAAA -Server 2a00:1098:2c::1

Write-Host "[4/7] 临时关闭WLAN IPv4绑定" -ForegroundColor Cyan
Disable-NetAdapterBinding -Name $nic -ComponentID ms_tcpip -Confirm:$false
Start-Sleep -Seconds 5

Write-Host "[5/7] 使用已验证可用的MASQUE" -ForegroundColor Cyan
& $warp tunnel protocol set MASQUE
& $warp connect
Start-Sleep -Seconds 10

Write-Host "[6/7] 验证WARP及IPv4出口" -ForegroundColor Cyan
& $warp status
curl.exe -4 --noproxy "*" -sS --connect-timeout 10 --max-time 20 https://www.cloudflare.com/cdn-cgi/trace | Select-String "ip=|colo=|warp="

Write-Host "[7/7] 输出最终网卡状态" -ForegroundColor Green
Get-NetAdapterBinding -Name $nic -ComponentID ms_tcpip
Get-DnsClientServerAddress -InterfaceAlias $nic

验收标准是 warp-cli status 报告 Connected / Network: healthy，curl -4 成功且响应中包含 warp=on，并且物理WLAN的IPv4仍禁用。若不能满足条件，先回滚而不是反复切换WireGuard。

上述脚本不会安装WARP，也不会自动处理GUI初次注册或其他系统代理软件残留配置。原始实验里WARP客户端选的是“流量和DNS（UDP）”；如果界面当前选了“仅DNS”，需要手工切回这个模式。

12.5 最简方案：先试WARP，不要上来就禁用IPv4

从技术上讲，WARP正常工作不需要预先把WLAN IPv4关闭，也不需要永久依赖nat64.net的DNS64。

推荐先按以下顺序尝试：

  1. 验证本机在未认证网络下的IPv6 HTTPS能正常到达外网，而不只验证Ping；
  2. 安装并注册官方WARP客户端，切换到“流量和DNS”模式，使用MASQUE；
  3. 保留系统原有WLAN IPv4和DNS设置不动，尝试直接连接WARP；
  4. 通过 warp-cli status 与 curl -4 --noproxy "*" 检查是否已取得真正的IPv4出口；
  5. 只有遇到明确的DNS或路由冲突时，才进行有针对性的进一步实验，并事先准备回滚方案。

本文没有独立验证“完全不改DNS、IPv4绑定，也能从同一未认证校园网成功初始化WARP”这种相对更简单的操作，不能保证一定有效。

12.6 发生故障时的自救方法

WARP卡在Happy Eyeballs、连上后没网： 打开图形界面手动断开，或执行（按本机安装路径）：

$warp = "C:\Program Files\Cloudflare\Cloudflare WARP\warp-cli.exe"
& $warp disconnect
& $warp tunnel protocol set MASQUE
& $warp connect
& $warp status

物理网卡IPv4误被关闭，想恢复日常联网：

Enable-NetAdapterBinding -Name "WLAN" -ComponentID ms_tcpip -Confirm:$false
netsh interface ipv6 set dnsservers name="WLAN" source=dhcp
Clear-DnsClientCache

想确定现在到底是哪一条路径在承担IPv4：

Get-NetAdapterBinding -Name "WLAN" -ComponentID ms_tcpip
Get-NetIPConfiguration | Where-Object IPv4Address | Select-Object InterfaceAlias,IPv4Address,IPv4DefaultGateway
curl.exe -4 --noproxy "*" -sS --max-time 15 https://www.cloudflare.com/cdn-cgi/trace | Select-String "ip=|colo=|warp="

请勿在没有备份的情况下执行全局网络重置（如 netsh winsock reset、删除网卡/驱动、清除全部静态IP），因为这次我们并没有做这些操作，也不需要依赖它们恢复。

13. 结语

最初只是发现，未登录校园网SSO，仍能连接中科大的IPv6测速站。最后在这条已经开放的IPv6通路上实现了几乎所有网络需求的免流效果，比如网络游戏的更新下载和登录游玩、其他IPv4网站的访问、在不开其他代理工具的情况下访问谷歌等网站。

但这些并不意味着“校园网IPv4已经被解锁”。真实变化是，Windows通过WARP虚拟接口把IPv4流量送进MASQUE隧道，底层校园网只需要具备可用的IPv6出口，远端Cloudflare网络承担应用所需的IPv4出口功能。

最终速度不是始终满速，游戏延迟也有几百毫秒，且公共NAT64、WARP的连接状态和出口性能都无法保证长期不变。不过你都免流了还要什么自行车。

本文扯了这么多，其实懂的人一眼就看明白了，一句话省流，其实就是搞了个全局代理，利用了Cloudflare WARP隧道，让电脑通过Cloudflare网络转发流量，一分钱没花，也不用自购带公网IPv6的服务器。

参考资料