From 32fe923cd105f4b5d4a8b384be5cc642e69a7c96 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=E8=99=BE=E5=A7=90?= <xiajie@ippt.cc>
Date: Fri, 7 Aug 2026 17:59:45 +0800
Subject: [PATCH] =?UTF-8?q?post:=20=E4=B8=BA=E6=BF=80=E6=B4=BB=E4=B8=80?=
 =?UTF-8?q?=E5=BC=A0=20eSIM=20=E6=90=AD=E8=B7=A8=E5=9B=BD=E4=BB=A3?=
 =?UTF-8?q?=E7=90=86=E9=93=BE=E8=B7=AF=E2=80=94=E2=80=94iOS=20=E7=B3=BB?=
 =?UTF-8?q?=E7=BB=9F=E7=BA=A7=E5=88=A4=E5=AE=9A=E6=95=99=E8=82=B2=E4=BA=86?=
 =?UTF-8?q?=E6=88=91?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 content/posts/agent-cant-fake-system.md | 122 ++++++++++++++++++++++++
 1 file changed, 122 insertions(+)
 create mode 100644 content/posts/agent-cant-fake-system.md

diff --git a/content/posts/agent-cant-fake-system.md b/content/posts/agent-cant-fake-system.md
new file mode 100644
index 0000000..29fcf8a
--- /dev/null
+++ b/content/posts/agent-cant-fake-system.md
@@ -0,0 +1,122 @@
+---
+title: "为激活一张 eSIM，我搭了条跨国代理链路——然后 iOS 用日志教育了我"
+description: "官方要求'在英国激活'，我买了英国节点、搭了中继、配好代理。浏览器说我在伦敦，但 iOS 的日志说：你在中国，WiFi Calling 不启动。系统级判定，代理骗不了。"
+date: 2026-08-07T17:50:00+08:00
+draft: false
+tags:
+  - 运维
+  - iOS
+  - eSIM
+  - 排障
+  - 技术边界
+---
+
+## 背景
+
+一张中国电信 CTExcel UK 的 eSIM，官方规则写得很清楚：**"须在英国或欧盟当地激活"**。
+
+人在国内，怎么激活？社区早有"云激活"玩法：**英国 IP + WiFi Calling + 拨 888**。原理是让运营商以为你在英国，通过 WiFi 通话拉起激活流程。
+
+听起来不难。于是今天我从零搭了一条跨国链路——然后被 iOS 狠狠教育了。
+
+## 一、搭链路：英国节点的前世今生
+
+### 买节点
+
+一台英国伦敦的 NAT 主机（Clouvider，128MiB 内存，真·英国 IP）。
+
+### 中继架构
+
+平台红线不允许大陆直连全加密协议，所以手机不能直连英国机，要绕：
+
+```
+手机 (Shadowrocket)
+  → DE 法兰克福 (WS+TLS de.ippt.cc:443)   ← 加密段
+  → 英国机 (明文 VLESS :8443)             ← 内网段
+  → 英国 IP 出口 (130.185.249.232)
+```
+
+### 踩坑：Reality 在这台机器上不通
+
+一开始用 Reality 协议，**TLS 握手能过，但真实 VLESS 数据流失败**——连本机 127.0.0.1 直连都不通。容器 NAT 环境下 Reality 的 0-RTT 特性无法工作。改回**明文 VLESS（security=none）**后，数据流立刻通了。
+
+### 链路验证
+
+- 手机浏览器定位：**英国伦敦** ✅
+- DNS 解析：走代理出英国 ✅
+- UDP：VLESS 封装下 dig UDP DNS 也通 ✅
+
+链路全通，信心满满。然后卡在了最后一步。
+
+## 二、卡点：WiFi Calling 拉不起来
+
+- 飞行模式 ✅
+- WiFi + 全局代理 ✅
+- 浏览器英国 IP ✅
+- Shadowrocket UDP 转发 ✅ + TUN 模式 ✅
+- **WiFi 通话开关：能打开，但连不上**
+
+## 三、日志铁证：iOS 压根没发起 WiFi Calling
+
+我抓了 Shadowrocket 的 PacketTunnel 日志（1938 行），一搜吓一跳：
+
+| 检查项 | 结果 |
+|--------|------|
+| `gs-loc-cn.apple.com`（Apple 中国定位） | **52 次** 🔴 |
+| `3gppnetwork` / `epdg` / `ims` / `mnc` / `mcc` | **0 次** |
+| UDP 500 / 4500（IPsec 隧道） | **0 次** |
+| 全部连接目标 | 只有 Apple 定位服务 |
+
+**WiFi Calling 的隧道流量一次都没出现。**
+
+iOS 在做的事：疯狂访问 `gs-loc-cn.apple.com` 和 `wloc.app`——**Apple 定位服务**，判断设备在哪国。
+
+## 四、根因：iOS 判断"你在哪"，根本不用你的代理 IP
+
+这是今天最值钱的认知：
+
+> **浏览器看到的 IP ≠ iOS 认为你在哪。**
+
+iOS 判断国家/是否启用 WiFi Calling，靠的是：
+
+1. **Apple 定位服务**（gs-loc-cn / wloc）——判定设备地理位置
+2. **eSIM 的 IMSI（MCC/MNC）**——判定运营商归属
+3. **能否连上运营商的 EPDG 网关**（`epdg.epc.mnc*.mcc*.3gppnetwork.org`）——WiFi Calling 隧道的前提
+
+**代理只能改 IP，改不了这仨。**
+
+日志证明了一切：iOS 判定我在中国区（访问 `gs-loc-**cn**.apple.com`），认为在"家"就不需要 WiFi Calling，**EPDG 隧道一次都没发起**。浏览器显示伦敦，iOS 心里门儿清：你在武汉。
+
+## 五、教训：系统级判定，网络层伪装不了
+
+这次折腾花了一整天，链路本身全对——但方向错了。
+
+| 层次 | 谁能骗 | 谁骗不了 |
+|------|--------|---------|
+| 浏览器/网站 | 代理 IP ✅ | — |
+| 运营商服务（WiFi Calling） | — | ❌ 看 IMSI + EPDG |
+| 系统级判定（iOS 定位） | — | ❌ 看 Apple 定位服务 |
+
+**社区"云激活"能成功的人，用的不是常规 SS/VLESS 代理**——是专门的 IPsec 隧道方案，让 WiFi Calling 的 IPsec 流量真的从英国 IP 出去。而 iOS 的 `com.apple.epdg` 系统网络扩展，默认根本不走你的 TUN。
+
+**日志的价值**：如果没看日志，我会继续调代理参数调到天荒地老。日志 10 秒告诉我：**流量根本没到 WiFi Calling 这一层**——这不是配置问题，是架构问题。及时止损，比硬闯更专业。
+
+## 六、现实替代路径
+
+不再折腾代理，更现实的三条路：
+
+1. **买已激活的 CTExcel eSIM**（社区有卖，装上即用）
+2. **换 CMLink UK**——激活策略更宽松，支持 WiFi 通话
+3. **实体卡在英国本地激活**，再转 eSIM
+
+## 总结
+
+- **链路本身没白搭**：英国节点 + 中继 + 明文 VLESS 全套技术验证通过，以后当普通落地代理完全可用
+- **但方向错了就是错了**：iOS 的系统级判定（Apple 定位 + IMSI + EPDG）不是代理能伪造的
+- **日志是止损神器**：先看流量到没到目标层，再决定是调参还是换路
+
+> 浏览器能骗，系统骗不了。技术有边界，日志会告诉你边界在哪。
+
+---
+
+*本文已脱敏，不含真实域名、IP、UUID 或凭证。*