同一节点电脑能看手机不能看：两端走的不是一条路
一句话结论
电脑通常走系统代理，几乎所有流量都被接管；手机 App 常常绕过系统代理直接使用自带 DNS，或者在蜂窝网络下启用 IPv6 直连。结果是两端的实际出口并不相同，判定自然不同。先确认手机是否开启 TUN/全局接管，再关掉 IPv6 复测，多数情况就能对齐。
同一份订阅、同一个节点、同一个账号，电脑上一切正常，手机上就是不行——这种情况几乎每个用久了的人都遇到过，而且第一反应通常是怀疑机场。
绝大多数时候，节点在这里是常量。真正的变量是流量在离开设备之前经历了什么：谁接管了它、谁替它做的域名解析、走的是 IPv4 还是 IPv6、当前网络是 Wi-Fi 还是蜂窝。这几处只要有一项不同，两端的实际出口就可能完全不是一回事。
所以排查的方向不该是「这个节点行不行」，而是「我的流量到底有没有真的从这个节点出去」。这两个问题的答案经常是相反的。
先确认一件事：两端的出口 IP 是不是同一个
在动任何设置之前，先把这个基本事实测出来，否则后面全是猜。
- 电脑端查一次出口。在开着代理的浏览器里打开一个 IP 归属查询页面，记下 IP、国家、城市与 ASN 四项。
- 手机端查一次出口。用手机浏览器打开同一个查询页面，记下同样四项。
- 手机 App 内再验一次。如果问题出在某个具体 App，在它内部找一个能反映地区的位置（比如内容分区、语言设置或账单地区），看它认定的地区是否与第二步一致。
三次结果可能出现的组合不多，对照下面这张表即可：
| 电脑出口 | 手机浏览器出口 | 结论 |
|---|---|---|
| 目标地区 | 与电脑不同或显示本地 | 手机端根本没走节点，问题在客户端接管范围 |
| 目标地区 | 与电脑相同，但 App 内地区不同 | App 绕过了系统代理或用了自己的解析 |
| 目标地区 | 完全一致，App 内也一致 | 出口没问题，问题在平台侧判定或 IP 被标记 |
第三种情况已经不属于本文范围，那说明流量确实出去了，接着该看的是流媒体节点为什么这么容易失效。前两种才是设备侧的问题，往下看。
系统代理和 TUN 模式的接管范围差在哪
这是跨端差异最大的一处。两种模式接管的东西完全不在一个量级：
| 模式 | 接管方式 | 能覆盖 | 覆盖不到 |
|---|---|---|---|
| 系统代理 | 通过系统的代理设置，由各应用自行遵守 | 浏览器、遵守代理设置的应用 | 不读代理设置的 App、部分命令行工具、多数游戏 |
| TUN / 虚拟网卡 | 建一块虚拟网卡，在网络层接管流量 | 几乎所有 IP 层流量，包括不遵守代理的 App | 明确走系统直连白名单的流量 |
电脑端很多人默认开着 TUN 或全局模式，接管范围大，所以「什么都能用」。手机端如果只开了普通模式，遇到不遵守代理设置的 App 就会漏出去。
开启 TUN 意味着更大范围的流量接管，请确认你信任当前订阅来源。接管范围越大，配置写错时的影响面也越大，建议改动后立刻用上一节的方法复测出口。
App 自带 DNS：为什么浏览器能看 App 不能看
域名解析这一步经常被忽略，但它决定了你「以为在连的服务器」和「实际连上的服务器」是不是同一台。
部分 App 出于性能或防劫持的考虑，会内置自己的解析逻辑，不使用系统 DNS，也不一定遵守客户端的解析规则。于是出现一个割裂状态：连接本身走了节点，解析结果却是按另一个位置返回的，平台据此认定的地区自然对不上。
处理方向是把解析统一到客户端手里。下面是一段结构示例，说明需要关注哪几个字段，不是可直接使用的配置：
# 结构示例：仅演示需要关注的字段，服务器地址一律用 example.invalid
ipv6: false
dns:
enable: true
ipv6: false
enhanced-mode: fake-ip
nameserver:
- https://example.invalid/dns-query
fallback:
- https://example.invalid/query关键点有三个：解析功能要打开，解析层面的 IPv6 要关掉，解析请求本身要走加密通道而不是明文发出去。具体字段名各客户端不同，Clash 系的完整写法见Clash 配置专题，iOS 侧的对应设置见Shadowrocket 使用专题。
关于解析出口与连接出口不一致会被平台看成什么，IP 地区判定原理的五层拆解里有专门一层在讲。
Wi-Fi 正常、切到流量就不行，通常是哪一项在作怪
这个现象的成因集中在三处，按出现频率排：
| 成因 | 典型表现 | 验证方式 |
|---|---|---|
| 蜂窝网络默认启用 IPv6 | 切到流量后部分服务直连出去 | 关掉客户端的 IPv6 后复测 |
| 网络切换后连接未重建 | 切换瞬间断流，手动重连即恢复 | 手动关闭再开启客户端 |
| 系统对后台 VPN 的策略更严 | 息屏一段时间后回来就失效 | 保持前台使用时复测一次 |
三项都与节点无关，也都能在手机上自己验证。逐项排掉之后，如果 Wi-Fi 与蜂窝下的出口 IP 终于一致，问题基本就解决了。
IPv6 直连怎么悄悄绕过了你的节点
很多节点只处理 IPv4 流量。当本地网络同时提供 IPv6 且目标服务也有 IPv6 地址时，系统往往会优先走 IPv6——而这条路径没有经过节点，是从你本地运营商直接出去的。
结果就是那种最让人困惑的现象：客户端显示已连接、延迟正常、日志里也有流量，但平台看到的还是你的真实位置。
排查动作很简单：
- 在客户端里关掉 IPv6 相关开关，包括解析层面的和路由层面的，两处都要关。
- 必要时在系统网络设置里也把 IPv6 关掉，部分场景下客户端的开关覆盖不到系统层。
- 重新查一次出口 IP，确认返回的是 IPv4 地址且地区正确。
- 确认无误后再开回来，如果开回去问题复现，就说明症结确实在这里，保持关闭即可。
关闭 IPv6 属于排查手段，长期关闭对绝大多数使用场景没有影响，但如果你的本地网络或内网服务依赖 IPv6，请在确认影响范围后再决定。
iOS 与安卓各自最容易踩的一个坑
两个系统的高频坑点不一样，分开说更实用。
iOS 一侧最常见的是「VPN 配置装了但没真正生效」。系统设置里的 VPN 开关显示已连接，客户端内部的连接状态却是断开的，或者规则模式下目标域名根本没命中任何规则而走了直连。检查顺序是：先看客户端内的连接状态而非系统开关，再看规则命中日志，最后确认没有开启会绕过代理的省电或数据节省选项。
安卓一侧最常见的是「系统或厂商层面的后台限制」。省电策略会在息屏后限制客户端进程，表现为用一会儿正常、放一会儿就失效。此外，部分厂商系统提供的「智能选网」「双通道加速」等功能会在 Wi-Fi 与蜂窝之间自动切换或叠加，直接破坏客户端的接管状态。把客户端加入后台白名单、关掉这类加速功能，是安卓端的固定动作。
两端调整完之后，务必用同一套方法在两端各测一遍，不要只测出问题的那一端。
对齐两端之后仍然不一致，说明什么
如果出口 IP 已经完全一致、解析也统一了、IPv6 也关了，结果还是一边行一边不行，那差异就不在你这里了。
有三种可能。App 可能仍在使用切换出口之前缓存的地区信息，退出账号重新登录或清除 App 数据可以强制刷新。平台也可能对 App 端采用了更严格的判定，比如叠加了设备与商店账号信息，这类差异靠改网络配置解决不了。还有一种是该 IP 段已经被标记，只是网页端的拦截阈值更宽松，表现出来就像只有 App 有问题。
到这一步，正确动作是换一个节点复测，用结果来区分是节点问题还是平台策略。Netflix 上这几种状态的区分方法，Netflix 地区判定是怎么算的里有对照表。如果连接本身也不稳定，那就属于另一类问题，连接失败排查专题更对症。
小结
电脑能看手机不能看，问题几乎总在流量离开设备之前的那一段，而不是节点本身。排查从测出口 IP 开始：两端不一致就是接管范围问题，一致但 App 内地区不同就是解析问题。TUN 模式解决接管范围，统一 DNS 解决解析归属，关闭 IPv6 解决静默直连，这三步能覆盖绝大多数情况。Wi-Fi 与蜂窝表现不同时，优先怀疑 IPv6 和网络切换后的连接重建。全部对齐之后仍不一致，就该换节点验证，而不是继续在客户端里改配置。
常见问题
电脑能看手机不能看，是不是节点只支持一台设备？
几乎不是。同一订阅的设备数限制表现为连不上或被踢下线，而不是能连上却看不了。能连上但结果不同，说明两端的实际出口或解析路径不一样。
为什么浏览器能打开，同一台手机上的 App 却不行？
浏览器一般遵循系统代理设置，部分 App 会使用自带的解析逻辑或直连接口，绕过代理规则。结果是同一台设备上两条路径的实际出口不同，平台看到的也就不是同一个 IP。
关掉 IPv6 是不是就一定能解决？
不一定，但它是排查里性价比最高的一步。IPv6 直连会让部分流量完全绕开只处理 IPv4 的节点，先把它关掉复测，可以一次性排除掉一大类干扰。
Wi-Fi 下正常、切到流量就不行，问题在哪？
常见于三处：蜂窝网络下运营商默认启用 IPv6、客户端在网络切换后未重建连接、以及部分系统对后台 VPN 在移动网络下的策略更严。先手动重连客户端再复测。
两端都对齐了还是不一致，说明什么？
说明差异不在你的配置里，而在平台侧或链路侧。可能是 App 缓存了切换出口前的地区信息，也可能是该 IP 段对 App 端的判定更严。此时该换节点验证，而不是继续改客户端。