WLOC iOS 虚拟定位：纯网络层 MITM 拦截方案

来源：X @getkaozhu

WLOC：基于网络层拦截的 iOS 虚拟定位方案

在 iOS 中修改地理位置，常见做法需要越狱、连接电脑或使用 TrollStore（巨魔商店），这些流程可能增加设备变砖风险，也可能因系统签名验证导致功能失效。WLOC 是一个开源方案，通过网络层拦截技术，在不修改系统底层、不安装 App 的前提下，替换苹果服务器返回的网络定位数据。

核心机制：MITM 与 gs-loc 拦截

WLOC 基于中间人攻击（MITM, Man-in-the-Middle）技术。iOS 设备进行网络定位时，向苹果地理定位服务器 gs-loc.apple.com 发起请求，请求中包含当前 WiFi MAC 地址和基站信息，服务器返回经纬度坐标。

WLOC 利用代理工具（如 Surge、Shadowrocket）作为中间代理。当设备访问 gs-loc.apple.com 或国内节点 gs-loc-cn.apple.com 时，代理工具通过预先安装的信任证书解密 HTTPS 流量，将服务器返回的 JSON 数据包中的坐标字段替换为预设值。这一过程在应用层与网络层之间完成，不修改 GPS 硬件驱动或系统内核，因此不易触发系统完整性检查。

“只改网络，不改 GPS”的效果取决于 App 的定位源。在室内或 WiFi 信号较强而 GPS 被遮挡的环境中，App 主要依赖网络辅助定位，WLOC 可以生效；在户外开阔地带，若 App 强制读取 GPS 硬件数据，则 WLOC 无效。这也正是其不被系统底层检测到的原因。

部署流程

实现该方案不需要编译环境，依赖已有的代理工具链。需要准备：运行 iOS 26+ 的设备（兼容旧版本）、支持模块配置的代理工具（Shadowrocket 或 Surge）、一个能正常解析域名的代理节点。

1. 基础环境搭建

在代理工具中添加 WLOC 模块配置。不同工具对应不同格式：Shadowrocket 使用 .module 文件，Surge 使用 .sgmodule，Quantumult X 使用 .conf 文件。这些配置文件定义路由规则和重写逻辑，只处理特定的苹果域名流量。

HTTPS 解密是必须步骤。将 gs-loc.apple.com 和 gs-loc-cn.apple.com 加入 MITM 域名列表，并在 iPhone 的「设置」→「通用」→「关于本机」中信任已安装的证书。不开启解密，代理工具只能看到加密数据包，无法替换内容。

2. 快捷指令辅助

开发者提供两个 iCloud 快捷指令：

• 设置地理位置：配合地图 App，在地图上长按选点，通过分享菜单调用指令，将坐标写入缓存。
• 清理恢复位置：一键清除伪造数据，恢复真实定位。

操作流程：打开地图 App → 长按目标地点 → 点击分享 → 选择“wloc 设置地理位置”。之后系统会自动触发代理规则重载。由于 iOS 定位服务存在缓存，有时需要手动关闭再开启定位服务，或重启设备，新坐标才能生效。

3. iOS 26+ 的缓存处理

iOS 26 及更高版本加强了定位数据的本地缓存，简单的切换开关可能无法立即刷新定位。为确保新坐标生效，可以按以下步骤操作：

1. 设置好目标位置。
2. 开启飞行模式并关闭定位服务。
3. 重启手机（清空系统内存中的残留定位缓存）。
4. 关闭飞行模式，开启代理模块。
5. 重新开启定位服务并验证。

局限性

WLOC 的局限性来自其技术原理：

• GPS 依赖场景失效：户外运动类 App 或对精度要求高的游戏，可能直接读取 CoreLocation 框架中的 GPS 硬件数据，绕过网络辅助定位。此时 WLOC 无效。
• IP 地址暴露风险：坐标被替换后，请求仍来自用户实际 IP。若服务端将 IP 与基站信息交叉比对（Fingerprinting），可能发现异常。
• 合规性风险：该技术只适用于技术探索或隐私保护。用于违反 App 服务条款（如游戏作弊、打卡造假）可能导致账号封禁。若 Apple 更新证书吊销机制或加强 TLS 双向认证，该方案可能失效。

与需要连接电脑的 PC 端方案相比，WLOC 不需要安装额外 App，代码在 GitHub 上公开，用户可以审查。它也不涉及越狱，不会带来保修失效的问题。在易用性、安全性和有效性之间，WLOC 是一个折中方案。

延伸

以下为编辑延伸解读，非原素材内容。

虚拟定位的技术演进与对抗

虚拟定位技术在 iOS 平台上经历了从“暴力破解”到“优雅欺骗”的演变。早期的方案多依赖于越狱插件（如 iSpoofer），直接 Hook 系统底层的 CLLocationManager API。这种方式效果最彻底，能欺骗所有 App，但代价极高：不仅破坏系统完整性，还极易被 Apple 的安全机制（如 Checkra1n 的检测）识别，导致设备被远程锁定或功能受限。

iOS 安全性提升后，TrollStore 等半越狱方案兴起，允许永久安装签名证书。但这依然需要连接电脑，且随着 iOS 版本的更新，签名的有效期成为瓶颈。WLOC 代表的“网络层伪装”则是另一种思路：它承认 GPS 硬件数据的真实性，仅在 App 依赖网络辅助定位时提供“虚假信息”。这种“部分欺骗”反而降低了被系统级反作弊引擎捕获的概率，因为从操作系统层面看，硬件传感器数据是完全正常的。

同类方案横向对比

开放性问题：未来防御机制

如果 iOS 对网络安全要求继续提高，Apple 可能会引入更严格的 Certificate Pinning（证书绑定）技术，即 App 不再信任系统根证书，而是只信任特定的服务器证书。一旦普及，像 WLOC 这样依赖系统证书信任链的 MITM 方案将彻底失效。届时，虚拟定位技术是否会回归到更深层的系统内核注入？这将取决于 Apple 与开发者社区之间的安全博弈。此外，如何区分“ legitimate privacy protection ”（正当隐私保护）与“fraudulent activity ”（欺诈行为），也是平台方在设计此类防御机制时面临的伦理与技术难题。