post: 误判的一天——四个系统都在骗我（今日全会话总结）
This commit is contained in:
@@ -1,122 +0,0 @@
|
|||||||
---
|
|
||||||
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 或凭证。*
|
|
||||||
@@ -0,0 +1,163 @@
|
|||||||
|
---
|
||||||
|
title: "误判的一天：四个系统都在骗我"
|
||||||
|
description: "谁在线判断错、推送路由推错群、字段覆盖率 59% 没人发现、iOS 不认代理 IP——今天修复了四个系统的四种误判，共同点：都在用错的数据源做判断。"
|
||||||
|
date: 2026-08-07T17:50:00+08:00
|
||||||
|
draft: false
|
||||||
|
tags:
|
||||||
|
- 运维
|
||||||
|
- 自动化
|
||||||
|
- 数据源
|
||||||
|
- 排障
|
||||||
|
- 技术边界
|
||||||
|
---
|
||||||
|
|
||||||
|
## 背景
|
||||||
|
|
||||||
|
今天是个"误判日"——四个独立的系统，四个不同的误判，分布在四条完全不同的工作线上：
|
||||||
|
|
||||||
|
1. **谁在线**：定时任务被当成"真人活跃"
|
||||||
|
2. **推送去哪**：寄修单被推给固定供应商群
|
||||||
|
3. **覆盖多少**：最缺的字段 59% 覆盖率，半年没人发现
|
||||||
|
4. **你在哪**：iOS 系统判定，代理 IP 骗不过
|
||||||
|
|
||||||
|
它们的共同点惊人的一致：**都在用错的数据源做判断**。
|
||||||
|
|
||||||
|
## 一、谁在线：定时任务假装成真人
|
||||||
|
|
||||||
|
### 需求
|
||||||
|
|
||||||
|
团队要一个"谁在线"的工具——热线的伙伴们想一眼看到谁在干活。
|
||||||
|
|
||||||
|
### 实现
|
||||||
|
|
||||||
|
基于操作审计库（op_history.db）判断活跃度：每次建单/派单/关单都记录操作人和时间。这比"打开过页面"（凭证上报）准确得多——**记录的是真实操作，不是停留在页面**。
|
||||||
|
|
||||||
|
### 误判
|
||||||
|
|
||||||
|
下午巡检时发现：**黄圆圆每天 10:15 / 10:21 准时"活跃"**——但那是定时任务用她的凭证跑的（巡检批量建单），不是她本人在操作。系统把她标记成"在线"，误导了团队判断。
|
||||||
|
|
||||||
|
### 修复
|
||||||
|
|
||||||
|
把"**审计操作人**"和"**凭证匹配人**"分离：
|
||||||
|
|
||||||
|
```bash
|
||||||
|
create_wo --name 黄圆圆 --op-user "系统自动-黄圆圆"
|
||||||
|
# 审计记录：系统自动-黄圆圆（不干扰在线判断）
|
||||||
|
# 凭证使用：黄圆圆（正常调 API）
|
||||||
|
```
|
||||||
|
|
||||||
|
定时任务链路统一传 `系统自动-` 前缀，Dashboard / who_online 自动过滤。从此**机器干的事和真人干的事分得清清楚楚**。
|
||||||
|
|
||||||
|
**教训**：用操作记录判断"谁在线"，前提是**先区分"谁操作"和"谁的系统在操作"**。自动化系统的影子，会让判断失真。
|
||||||
|
|
||||||
|
## 二、推送去哪：寄修单进了供应商群
|
||||||
|
|
||||||
|
### 需求
|
||||||
|
|
||||||
|
4 个城市的工单要推送到各自的固定供应商群，让服务商第一时间看到单子。
|
||||||
|
|
||||||
|
### 误判
|
||||||
|
|
||||||
|
一个长沙客户的**寄修单**（寄回武汉总仓修，ownerGroupName=电脑工程师(寄修组)），推送时因为"客户在长沙"被判定为"长沙固定供应商单"，**推错了群**——寄修单不该进城市固定供应商群，该进寄修组群。
|
||||||
|
|
||||||
|
### 根因
|
||||||
|
|
||||||
|
推送代码在采集工单时**丢弃了 ownerGroupName 字段**——后续所有判断都基于"客户城市"，根本不看"这个单是寄修还是上门"。
|
||||||
|
|
||||||
|
### 修复
|
||||||
|
|
||||||
|
1. 采集映射**保留 ownerGroupName**
|
||||||
|
2. 寄修单 → 寄修组群（`_pick_repair_engineer`），不再推城市群
|
||||||
|
3. 顺带修了一个脆弱的"武汉判定"：只看地址含不含"武汉"两个字，城市=武汉但地址没写武汉就漏判——改为**城市=武汉即算武汉**
|
||||||
|
|
||||||
|
**教训**：路由判断要有**完整的上下文**。只按一个维度（城市）做决定，就会漏掉另一个维度（寄修/上门）的业务含义。
|
||||||
|
|
||||||
|
## 三、覆盖多少：最低的字段，半年没人发现
|
||||||
|
|
||||||
|
### 需求
|
||||||
|
|
||||||
|
三方平台同步（神州邦邦/修吧/大鱼 → WPS 主表）要检查字段覆盖率，确保数据完整。
|
||||||
|
|
||||||
|
### 误判
|
||||||
|
|
||||||
|
发现"更换备件"字段实际覆盖率只有 **59%（133/224）**——全场最低，却一直没人发现。
|
||||||
|
|
||||||
|
### 根因
|
||||||
|
|
||||||
|
覆盖率检查脚本的字段清单里**漏了"更换备件"**。清单没列它 → 从不检查它 → 它缺失到 59% 也没人知道。
|
||||||
|
|
||||||
|
**检查范围本身就是数据源的一部分**——清单漏字段 = 检查系统自身失明。
|
||||||
|
|
||||||
|
### 修复
|
||||||
|
|
||||||
|
- 补上字段清单，覆盖率 59% → 62%（子表能补的全补完）
|
||||||
|
- 剩余缺失逐条分类：已取消的 11 条（合理）、进行中 31 条（未到备件阶段）、已修复 31 + 待验收 12 条（三方平台本身没返回备件数据——是否漏提取，待深入）
|
||||||
|
|
||||||
|
**教训**：**"检查覆盖率的检查"也要被检查**。没有元检查，最低的字段会永远沉默。
|
||||||
|
|
||||||
|
## 四、你在哪：iOS 不认代理 IP
|
||||||
|
|
||||||
|
### 需求
|
||||||
|
|
||||||
|
一张中国电信 CTExcel UK 的 eSIM，官方要求"在英国或欧盟当地激活"。人在国内，社区玩法：**英国 IP + WiFi Calling + 拨 888** 云激活。
|
||||||
|
|
||||||
|
### 实现
|
||||||
|
|
||||||
|
从零搭跨国链路：
|
||||||
|
|
||||||
|
```
|
||||||
|
手机 (Shadowrocket)
|
||||||
|
→ DE 法兰克福 (WS+TLS de.ippt.cc:443)
|
||||||
|
→ 英国机 (明文 VLESS :8443)
|
||||||
|
→ 英国 IP 出口 (伦敦)
|
||||||
|
```
|
||||||
|
|
||||||
|
踩了 Reality 在容器 NAT 机上不工作的坑（TLS 握手过、数据流不通，改明文 VLESS 才通），链路验证全通过：浏览器定位伦敦 ✅、DNS 出英国 ✅、UDP 通 ✅。
|
||||||
|
|
||||||
|
### 误判
|
||||||
|
|
||||||
|
WiFi Calling 拉不起来。抓了 Shadowrocket 的 PacketTunnel 日志（1938 行），一搜吓一跳：
|
||||||
|
|
||||||
|
| 检查项 | 结果 |
|
||||||
|
|--------|------|
|
||||||
|
| `gs-loc-cn.apple.com`（Apple 中国定位） | **52 次** 🔴 |
|
||||||
|
| `epdg` / `ims` / `3gppnetwork`（WiFi Calling 隧道） | **0 次** |
|
||||||
|
| UDP 500/4500（IPsec） | **0 次** |
|
||||||
|
|
||||||
|
**iOS 压根没发起 WiFi Calling**。它在疯狂访问 Apple 定位服务——**判断设备在哪国，用的是 Apple 定位 + eSIM 的 IMSI，不是你的代理 IP**。
|
||||||
|
|
||||||
|
### 根因
|
||||||
|
|
||||||
|
> 浏览器看到的 IP ≠ iOS 认为你在哪。
|
||||||
|
|
||||||
|
iOS 判断国家靠三样：Apple 定位服务（gs-loc/wloc）、eSIM 的 IMSI（MCC/MNC）、能否连上运营商 EPDG 网关。**代理只能改 IP，改不了这三样**。日志证明 iOS 判定我在中国区，认为在"家"就不需要 WiFi Calling，EPDG 隧道一次都没发起。
|
||||||
|
|
||||||
|
社区能"云激活"成功的人，用的是专门的 IPsec 隧道方案，不是常规 SS/VLESS 代理——iOS 的 `com.apple.epdg` 系统扩展默认不走你的 TUN。
|
||||||
|
|
||||||
|
**教训**：**系统级判定（运营商/OS 的国家识别）用网络层伪装不了**。技术有边界，日志会告诉你边界在哪——10 秒止损，比硬闯一整天更专业。
|
||||||
|
|
||||||
|
## 五、方法论沉淀：判断的四个数据源原则
|
||||||
|
|
||||||
|
| # | 原则 | 今天的事例 |
|
||||||
|
|---|------|-----------|
|
||||||
|
| 1 | **区分"谁操作"和"谁的系统在操作"** | 定时任务冒充真人活跃 |
|
||||||
|
| 2 | **路由判断要有完整上下文** | 只按城市判，漏掉寄修/上门维度 |
|
||||||
|
| 3 | **检查清单本身要被检查** | 字段漏检，59% 半年无人知 |
|
||||||
|
| 4 | **系统级判定，网络层伪装不了** | iOS 不认代理 IP |
|
||||||
|
|
||||||
|
四个误判的共性：**都输在"用什么数据做判断"上**。
|
||||||
|
|
||||||
|
- 判断在线 → 要用"真人操作"数据，排除"系统操作"影子
|
||||||
|
- 判断推送路由 → 要用"城市+寄修状态"全量数据，不能只看城市
|
||||||
|
- 判断覆盖率 → 检查清单要完整，缺失字段本身就是盲区
|
||||||
|
- 判断位置 → 要用系统认可的数据（IMSI/EPDG），IP 代理是无效信号
|
||||||
|
|
||||||
|
## 总结
|
||||||
|
|
||||||
|
> 判断的准确性 = 选对数据源 + 完整上下文 + 检查元层 + 尊重系统边界。
|
||||||
|
|
||||||
|
今天四个误判，没有一个是"代码写错"，全是**"判断依据选错"**。这也提醒我：排障时先问"这个判断依赖什么数据、数据对吗"，往往比盯着代码更快找到真相。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
*本文已脱敏，不含真实域名、IP、UUID 或凭证。*
|
||||||
Reference in New Issue
Block a user