投屏按钮按下去,列表里一台设备都没有;网络打印机搜索半天也是空的;可电脑和电视明明连的是同一个路由器。这类情况在开了代理IP 之后特别常见,原因往往不在设备上,而在于”发现”这件事压根不走代理。
设备发现走的是本地链路,代理IP 不参与这一段
设备之间互相找到对方,靠的是广播与组播这一类本地协议:设备在本地网段里喊一声,同网段的同伴回应,列表就这么出来了。这些包的目的地址是本地网段,不会跨网段转发,更不会交给代理IP 去送到公网。
代理IP 接管的是”要出公网的单播请求”——你访问一个网站、调一个接口,这类请求才会被转发。局域网里找设备属于另一条路,两者各走各的,互不干涉。
于是就有了第一个认知上的错位:很多人以为代理IP 一开,所有网络行为都会被接管。实际上本地流量通常被排除在外,而”排除”这个动作做得干不干净,恰恰是问题的高发区。
三类成因:先分类,再动手
本地网段被一起收走了。客户端工作在把全部流量都往外送的模式下时,本该留在本地的请求也被一并交给代理IP 转发,出不去也回不来,发现列表自然为空。这是最常见的一类,特征是关掉代理IP 客户端之后立刻恢复正常。
网络类型被判定成了公用。系统在网络类型为公用时,默认会关闭网络发现与共享。代理IP 改变了系统探测网络的路径,就可能连带改变这个判定。这一类与发现协议本身无关,但表现完全一样。
设备与电脑本来就不在同一网段。访客网络隔离、无线接入点隔离、虚拟局域网划分,都会让设备虽然接在同一个路由器上却彼此看不到。这种情况与代理IP 无关,即便全部关掉也一样搜不到。
- 确认两者在同一网段。对比电脑与设备的 IP 地址前几段是否一致,网段不同就直接查路由器的隔离设置,不用往下走了。
- 看发现用的是哪类协议。用设备名加 .local 后缀去解析的属于一类,靠组播通告的属于另一类,两者的排查入口不一样。
- 核对分流规则是否把本地网段排除。本地网段应当设置为直连,若被一并收进转发范围,把这一段排除掉再试。
- 关掉代理IP 客户端对比一次。关掉之后发现恢复,说明问题出在转发范围或网络类型判定上;关掉依旧搜不到,问题在本地网络本身。
容易误判的两处
一处是把”发现失败”当成”设备坏了”。实际上用设备的 IP 地址直接连,往往一下就连上了。能连上就说明设备没问题,断的是发现那一步,两者要分开看。
另一处是把”应用层能连”当成”发现正常”。不少应用会记住上次连过的设备地址,下次直接按地址去连,不依赖发现也能用。于是问题被掩盖了,直到换一台新设备或者地址变了才暴露出来。
还有一点值得留意:发现协议通常有重试与缓存机制,刚改完设置不一定立刻生效,等上一小会儿或者重启一下应用再看,能避免不必要的反复折腾。
分清”发现”和”连接”这两件事,排查就不会绕远。前者靠本地链路,后者才轮到代理IP 出场。
发现靠本地链路,连接才有代理IP 的份——先弄清断的是哪一段。