仅手表端存在的 App，在蓝牙配对状态下全部无法联网；关掉蓝牙就正常

Question

级别 1

4 积分

仅手表端存在的 App，在蓝牙配对状态下全部无法联网；关掉蓝牙就正常

凡是"只有手表上有、iPhone 上没有"的 App，在两者蓝牙连接时全部无法联网：
1. 手表浏览器：访问 https://www.baidu.com 也失败
2. "潮汐"：地点列表能显示，数值一直空白
3. 手表上第三方 App：报错"似乎已断开与互联网的连接"

访问国内站点同样失败——不是域名被拦，而是 App 判断"无互联网连接"，请求没发出去。手表上没有任何第三方代理/VPN 客户端。连手机就挂、断蓝牙就好 → 说明是"配对状态下仅手表端 App 的网络路径"有问题。

对照测试：

| 状态 | 结果 |
| --- | --- |
| 蓝牙连着 + 手机上网络代理类 App 未启用 | ❌ 全部无法联网 |
| 蓝牙连着 + 手机上该 App 启用 | ✅ 正常 |
| 手表上关闭蓝牙（单独连 Wi-Fi） | ✅ 正常 |

环境：
- Apple Watch Ultra4；watchOS 27.0.1 (24R365)
- iPhone：【型号，国行】；iOS：【27.2】
- 运营商：【电信】；地区：中国大陆
- 出问题的浏览器是第三方 App，iOS 侧有配套 App（并非完全独立的 App）

日志中发现两点：
1. 存在 pdp_ip0~pdp_ip5 等蜂窝数据接口，以及 CommCenter 相关进程，说明手表的蜂窝栈是活动的；
2. 但设置里找不到"仅用于手表的 App"这一网络权限开关。想确认它在 watchOS 27 上是否仍存在、是否只有蜂窝版才有。

请教三个问题：
1. 配对状态下，仅手表端 App 联网时实际走 iPhone 还是手表自己的 Wi-Fi/蜂窝？watchOS 有没有单独设置这类 App 网络权限的入口？
2. 为什么配对状态下会判断"无网络"、切断蓝牙后就正常？是已知行为还是异常？
3. 手机侧那类 App 的启用状态为什么会改变手表的联网结果？

已尝试：两机重启、手表重新配对、还原手表网络设置。
需要的话我可以提供完整 sysdiagnose（含 scutil、netstat、路由表）并按需复现。

Apple Watch Ultra 4, watchOS 27

发布日期 2026年10月1日下午2:55

Answer 1

排名最靠前的回复

王涌鉴

级别 4

2,139 积分

2026年10月1日下午5:33 回应 Zhe_Bin

你好！Zhe_Bin

遇到 Apple Watch 在与 iPhone 蓝牙连接时独立 App 无法联网、而断开蓝牙后 Wi-Fi/蜂窝单独联网却正常的现象，属于非常典型的 iPhone 蓝牙网络代理/路由通道异常。

在蓝牙配对状态下，Apple Watch 默认会通过蓝牙低功耗（BLE）借用 iPhone 的网络连接，以节省手表的电量和网络资源。针对你提出的疑问和排查需求，回复如下：

一、解答你的三个疑问

1 配对状态下的联网路径与权限入口

联网路径：蓝牙配对时，所有 App 的网络请求都会优先通过蓝牙通道由 iPhone 进行转发/代理（除非某些要求高带宽的传输会临时触发蓝牙转 Wi-Fi）。

权限入口：watchOS 系统本身没有针对独立 App 单独开闭网络权限的全局开关。手表的网络权限完全继承并依托于 iPhone 侧的管理逻辑；蜂窝网络权限则只能在 iPhone 的 “Watch” App > 蜂窝网络中为支持蜂窝的 App 进行单独开关。

2 为什么配对时提示“无网络”，切断蓝牙后正常？

这是异常行为。当系统判断蓝牙已连接时，watchOS 会将网络路由强制指向蓝牙代理通道，并关闭手表自身的 Wi-Fi/蜂窝链路以省电。

如果此时 iPhone 侧的代理服务（如 NetworkExtension 接口、蜂窝数据共享或 VPN 协议栈）未能正确响应或拦截了手表发出的 TLS/TCP 请求，手表端就会直接认定“无互联网连接”并拦截请求发送。

3 为什么 iPhone 侧网络代理 App 的启用状态会影响手表？

因为在蓝牙连接模式下，手表的流量实质上是由 iPhone 上的 iOS 系统网络栈进行二次转发的。如果 iPhone 上启用了网络代理 App（如某些 VPN 或网络工具），iPhone 的系统路由表及 TUN/TAP 虚拟网卡会接管蓝牙接口（pdp_ip / p2p）的入站流量，导致手表的数据包被强制走 iPhone 的代理规则；而当代理 App 未启用或规则配置不当（例如未勾选“允许局域网/共享设备连接”或拦截了 UDP/DNS 请求）时，转接通道就会中断。

二、建议尝试的解决方法

1.重置 iPhone 的网络设置（关键）

由于问题根源在 iPhone 的蓝牙网络转发路由上，请前往 iPhone 的设置 > 通用 > 传输或还原 iPhone > 还原 > 还原网络设置。

注意：此操作会清除 iPhone 保存的 Wi-Fi 密码和蓝牙配对记录，但能有效修复系统网络路由栈损坏问题。

2.检查 iPhone 上的代理/网络扩展配置

前往 iPhone 的设置 > 通用 > VPN 与设备管理。

如果安装过代理工具或网络配置文件，请检查其设置中是否开启了“局域网共享”或“Tun 模式”。可以尝试完全移除相关 VPN 配置描述文件，重启 iPhone 后观察蓝牙配对下的手表联网是否恢复。

3.关闭并重新开启 iPhone 的蓝牙与无线局域网

在 iPhone 的设置中（而非控制中心）彻底关闭蓝牙和无线局域网，等待 10 秒后再重新打开，强制两端重新握手建立网络桥接通道。

4.更新系统或提交 Feedback / 诊断日志

如果你使用的是 iOS 27 / watchOS 27 早期版本，这可能是新系统版本中 CommCenter 配合蓝牙网络代理协议栈的兼容性 Bug。既然你可以提取 sysdiagnose 日志，建议通过 Apple 的 Feedback Assistant 提交日志，反馈给 Apple 工程师进行修复。

Answer 2

Zhe_Bin 作者

级别 1

4 积分

2026年10月2日下午8:57 回应王涌鉴

感谢回复，方向有帮助，但有三点用实测日志能更正，供参考（均为 watchOS 27.0.1 / iOS 27.0.1，同一配对）：

一、"iPhone 侧路由/代理拦截"这条不成立

我抓了 iPhone 侧 sysdiagnose（20:22）：

Primary IPv4 = en0 / 192.168.0.112

DNS Addresses = 192.168.0.252、114.114.114.114、fe80::1

默认路由 = 192.168.0.252 → en0

连通性自检：ping 路由器 ✅ ping DNS ✅ 解析 captive.apple.com ✅

route get www.apple.com → 183.250.178.8 ✅

iPhone 自己的 DNS 与上网完全正常，没有 VPN 描述文件，NetworkExtension 里也没有代理配置。

二、手表侧是先建立伴生链路并借道成功，卡在"解析器没传过来"

手表侧（19:40，Wi-Fi 关闭）：

logs/NetworkRelay/companion_link_status_watch.txt

Primary Link: [1, PRIMARY, Bluetooth(P), Ready, ipsec1, Bluetooth, iPhone]

resolver keys: { } ← 空

Prefer Wi-Fi request: NO

WiFi/ifconfig.txt 里 ipsec1 的定义：

type: Companion Link Bluetooth (0x1)

functional type: companionlink

agent … type:CompanionProxy desc:"CompanionProxy via iPhone"

WiFi/network_status.txt → DNS Addresses: None

logs/Networking/route-info.txt → route: bad address: www.apple.com

WiFi/diagnostics-connectivity.txt → Could not resolve 'captive.apple.com'

即：链路是 Ready、借道是成立的（默认路由确实走在 ipsec1 上），

但链路没有向手表提供任何 DNS 解析器，手表自身 DNS 也是 None。

三、关键对照：iPhone 侧 resolver keys 同样是空的

iPhone 侧 logs/NetworkRelay/companion_link_status_phone.txt：

Companion link is currently enabled

NRDLD[…8BD12814…] name "Zhe的Apple Watch" registered, enabled,

Has Authenticated Using Identity: YES

SOCKS port: 62742 / SOCKS server: [SP1 SHOES]

Link Manager - Bluetooth State: Ready（ipsec5）

Link Manager - WiFi [17, PRIMARY, WiFi(Ifr), Ready, ipsec8,

192.168.0.112:0 -> 192.168.0.26:57878]

resolver keys: { } ← 手机侧也是空

对比：手表 Wi-Fi 打开时（17:01）DNS = 192.168.0.252 / 114.114.114.114 / fe80::1，

Prefer Wi-Fi request: YES，全部自检通过、route get 正常返回。

所以定位到的环节是：iPhone 有可用 DNS，但这条 Companion Link 没有把解析器传递给手表；

而不是"iPhone 侧路由/代理拦了请求"。（另外手表侧并无第三方代理 App，只有系统 nesessionmanager / nehelper / networkserviceproxy。）

四、关于你给的建议

"重置 iPhone 网络设置"我已试过，无效 —— 与上述机制一致：解析器根本没在链路上注册，

不是本机路由表损坏。手表 Wi-Fi 关闭时链路本身是通的，这也不是"桥接中断"。

五、想再请教（或供其他遇到的人参考）

1) 你了解 iOS 27 / watchOS 27 上 Companion Link（NetworkRelay）是否应当向手表提供 DNS 解析器吗？

还是说它设计上只承载部分服务、不提供通用上网 DNS？

2) 如果是设计限制，有没有用户侧可行的规避方式（watchOS 无手动配置 DNS 的入口）？

目前我的绕行办法是保持手表 Wi-Fi 常开，或让手表连 iPhone 个人热点。

我已按建议抓了三份 sysdiagnose（手表故障态 / 手表正常态 / iPhone 对照）并准备提交 Feedback，

如果你需要我也把关键行贴上来。