Files
blog/content/posts/agent-cant-fake-system.md
T

123 lines
5.0 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
---
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 主机(Clouvider128MiB 内存,真·英国 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 特性无法工作。改回**明文 VLESSsecurity=none**后,数据流立刻通了。
### 链路验证
- 手机浏览器定位:**英国伦敦** ✅
- DNS 解析:走代理出英国 ✅
- UDPVLESS 封装下 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 / 4500IPsec 隧道) | **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 的 IMSIMCC/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 或凭证。*