KFChost 新玩具 5GPN 试玩——更优雅的移动上网方式

KFChost的新玩具———5GPN. 它最大亮点就是：可以把所有路由/配置/线路/分流/落地，都搬到云端。手机上看起来就只插了张普通的联通卡，但是一切都已经默默完成。

1. 目标

不是搭一个普通节点：

• 手机端不装任何 VPN / Clash / 小火箭这类代理 App；

• 出口能在多个落地之间切换，换出口不用重装手机配置；

• 国内网站本地直连，不绕路、不损耗；

• 尽量减少 DNS 泄露、出口 IP 混乱、App 绕过。

• 不和WiFi、其他手机卡流量冲突

不是完整的 VPN/TUN，它有边界；但效果已经比较实用。

2. 好处非常实在：

• 一台 1 vCPU、内存几百兆的小鸡就能扛，主要处理 DNS 查询和 TLS 握手的“分流决策”；
• 国内站点零绕路、零损耗（本地直连）；
• 没有客户端 = 没有耗电、没有“已连接 VPN”图标、不影响其他 App 的本地网络策略。
• 适合装逼

3. 总体架构

▲ 图 1:KFC 5GPN 总体架构 —— 控制节点只做 DNS + SNI 决策,国内流量绕过网关直连

▲ 图 2:蜂窝走 5GPN、WiFi 退回本地,由 OnDemand 自动切换

4. 手机侧：安装描述文件（iOS）

可以参考的设计是：

• 手机蜂窝网络可达 5GPN 内网路径时，启用 5GPN DNS；
• WiFi 或其他网络不可达时，自动断开，回到系统 DNS；

关键就在 OnDemandRules：

<dict>
  <key>PayloadType</key>    <string>com.apple.dnsSettings.managed</string>
  <key>PayloadVersion</key> <integer>1</integer>
  <key>DNSSettings</key>
  <dict>
    <key>DNSProtocol</key>    <string>TLS</string>
    <key>ServerName</key>     <string>dot.example.com</string>
    <key>ServerAddresses</key><array><string>198.51.100.10</string></array>
  </dict>

  <!-- ★★★ OnDemandRules 和 DNSSettings 平级 ★★★ -->
  <key>OnDemandRules</key>
  <array>
    <dict><key>InterfaceTypeMatch</key><string>WiFi</string>
          <key>Action</key><string>Disconnect</string></dict>
    <dict><key>InterfaceTypeMatch</key><string>Cellular</string>
          <key>Action</key><string>Connect</string>
          <key>URLStringProbe</key><string>http://198.51.100.10:81/probe</string></dict>
    <dict><key>Action</key><string>Disconnect</string></dict>
  </array>
</dict>

规则含义：WiFi → 断开（用系统/路由器 DNS）；蜂窝 → 且探测端点可达时才启用（确认确实在专网路上）；其余 → 断开。

• WiFi 规则要排在 Cellular 规则之前；
• 加一个 probe 识别双卡手机的第二张卡；
• OnDemand 的 Disconnect 实际等价于回到系统 DNS。

5. DNS 即策略：直连白名单 + 兜底代理

整套系统让上网变优雅的地方：用 DNS 应答本身来表达路由策略。

▲ 图 3:解析器对每条 DNS 查询的判定(直连 / 拒绝 / 代理兜底)

6. 443 主路径：SNI 路由

绝大多数 App 流量还是 HTTPS 443/tcp，流程是：

▲ 图 4:443 主路径 —— 只读 SNI、不解密的四层转发

这里不解密 TLS，只看 SNI。控制节点用 nginx stream 做，核心就几行：

stream {
    map $ssl_preread_server_name $backend {
        hostnames;
        default              selected-landing:18443;   # 默认落地
        .some-group.example  special-landing:18443;    # 指定域名走指定落地
    }

    server {
        listen 443;
        ssl_preread on;
        proxy_pass $backend;        # 只按 SNI 转发，不解密
    }
}

落地节点也用 stream，并且只允许控制节点访问：

stream {
    server {
        listen 18443;
        allow 5gpn-control-node;
        deny all;

        ssl_preread on;
        proxy_pass $ssl_preread_server_name:443;
    }
}

7. 非 443 的处理：窄口白名单，别一上来就做透明代理

我对手机上的常用App做了一次审计，结果大致是：

• 绝大多数是 tcp/443；
• 没发现明显硬编码 IP；
• 没发现明显内置 DoH/DoT；
• 少量非 443 是证书/OCSP 和某个 App 的特殊端口。

所以我的处理不是“打开所有非 443”，而是窄口白名单。

HTTP/80：证书和 OCSP

观察到的 80 主要是：

ocsp.example-ca.com:80
certs.example-ca.com:80

处理方式：

手机 -> 5GPN:80 -> 当前落地:18480 -> 真实 Host:80

控制节点只允许少数 Host，非白名单直接 403：

map $host $http80_host {
    default "";
    ocsp.example-ca.com  ocsp.example-ca.com;
    certs.example-ca.com certs.example-ca.com;
}

特殊 TCP/4443

某个 App 会访问 device.example.com:4443，处理方式：

手机 -> 5GPN:4443 -> 当前落地:18444 -> device.example.com:4443

同样只允许这个 SNI，其他 SNI fail closed。

NTP / UDP

还会看到系统访问 time.apple.com:123/udp。这个我没有强行处理，它更像系统 NTP，不是 App 业务流量。如果未来真要处理 UDP，就另做 UDP 设计，不建议混进这套 TCP/SNI 架构里凑。

8. 几个关键点

① 注入「中国 ECS」解决 GeoDNS 选错区。

② 国内 DNS 走 TCP，别用 UDP。 从境外突发一批 UDP DNS 到国内，会被限速/丢包（改 UDP-first 直接更慢甚至连不上）。老老实实 TCP 查国内DNS。

③ AAAA / HTTPS(SVCB) 要分情况。 对代理域名全部回空，能把 App 逼回 IPv4 + 抑制 ECH；但对直连域名要回真实的 HTTPS 记录，否则部分 App（尤其苹果系）会异常。

④ 上游解析做并发竞速 + TTL 缓存，全部失败再合成 SERVFAIL，体感更快也更稳。

9. 避坑指南

▲ 图 5:OnDemandRules 嵌进 DNSSettings(❌)vs 与之平级(✅)

坑 ：苹果联网探测域名（captive.apple.com 等）须直连。

captive.apple.com 是 iOS 判断“这网到底有没有网”的探测，App 的可达性判断跟着它走。而且这个探测走的是 HTTP :80，根本过不了只听 :443 的 SNI 网关，必然失败。

解法：把苹果联网/iCloud/推送这类国内本就可直连的域名加进 direct 名单。如果担心国内收不到海外软件消息推送之类的问题，至少要放 captive.apple.com 。

坑 ：QUIC / HTTP3 绕过 SNI 路由。 如果允许 UDP/443，很多浏览器和 App 会走 QUIC，SNI 路由就看不到了。

解法：对手机源 UDP/443 做 reject；DNS 对 HTTPS/SVCB 返回空；让流量回到 TCP/443。

坑 ：内嵌“墙外 SDK”反而拖慢启动。 有些国内 App （也做老外生意的，比方说智能家居啥的）嵌了 Facebook/Google 之类 SDK。平时在国内它们秒失败（被墙），App 照常启动；一旦你给了它们可达的出海能力，这些 SDK 会老老实实做完整握手，反而把启动拖慢几秒。要么保持代理、要么干脆让它直连“快速失败”——按需取舍。

10. MJJ喜闻乐见的测速环节：比"国际漫游卡"强多少

• 手机 5GPN → 美国出口
• 手机 T-mobile国际漫游流量 → 美国出口

同一脚本、锚定固定目标、各 20 次:

▲ 图 6:同为「中国手机 → 美国出口」,5GPN 三项全胜

• 国内分流直连带来巨大差距:
  T-mobile漫游卡按归属地把所有流量(含国内站)甩到美国,访问百度要绕「美→中」一圈 ≈ 1922ms;
  5GPN 让国内域名直连,150ms —— 约 13×。
• 国际也不吃亏:611ms vs 889ms,且抖动只有漫游卡的六分之一;下行还快约 2×。
• 主干很稳:中国蜂窝 → 日本网关 RTT ~77ms、0 丢包(90+ 采样)。

三落地对比

路径:手机(China SIM,5G)→ KCloud(日本)→ 落地 → Cloudflare。每落地 30 次采样。

主干(到 KFC 日本): p50 77ms, 抖动 10–39ms, 90+ 采样 0 丢包。
DoT(:853)握手 connect ~78ms + TLS ~181ms,稳定。

分析

• 主干(中国蜂窝→日本)恒定 ~77ms、0 丢包，足够稳
• 落地间差异全在"KFC→落地→目标"那一段

PO0 链路 vs 5GPN 链路

无线vs有线，比不过是肯定的，但还是拉出来遛遛，看看差距

PO0比手机 5G 更快更稳; 但对"移动网络"而言, 5GPN 已经足够顶尖。