网络排障
先还原现场：哪些内容能用，哪些不能用
先检查新 Wi-Fi 是否真正联网。有些网络需要门户认证，设备虽显示已接入，却还没有访问外网的条件。访问平时可用的 HTTPS 网站；若其他应用也失败，先恢复基础联网。
lantern排查时，把现象记录到具体范围：是浏览器所有网页打不开，还是一个应用的某个页面失败？问题只出现在家中网络，还是移动网络也一样？这样的比较可以帮助区分新网络、客户端会话和目标站点。
第一步：恢复接入，再重新建立会话
确认 Wi-Fi 完成正常认证之后，查看系统 VPN 状态与应用状态是否一致。网络切换可能让旧会话失效，可以先断开再连接，必要时重新打开应用。每调整一项，就重试原来失败的任务。
lantern重新连接后，如果本来可用的普通网页恢复，而某一个目标仍失败，问题范围已经缩小。保留这些差异，继续检查，不必立刻重置路由器或清空设置。
第二步：把模式和例外一起核对
智能路由按规则选择进入隧道的请求，某个目标可能没有按你预期进入服务网络；分流例外还可能让指定应用或网站始终直连。若只看到“已连接”，就跳过这些规则，容易误判为客户端完全失效。
lantern可以尝试切换 Full Tunnel 作为对比，同时核对目标是否仍在绕过名单。每次只改一项并比较目标结果，仍失败也不能直接认定是 DNS 问题。
第三步：看到解析错误，再检查 DNS
DNS 负责把域名解析成地址。浏览器明确显示解析错误，才是优先检查这一层的线索之一。应先确认系统或路由器是否使用了自定义解析设置，网络切换后这些设置是否仍适用，并保留原配置以便恢复。
不要照着陌生列表反复更换 DNS 地址。解析服务、网络设置与应用处理方式可能不同；即使解析成功，后续隧道或目标连接仍可能失败。
第四步：检查其他 VPN、防火墙与权限
lantern与其他处理系统网络的工具同时工作时，可能出现配置占用或路径冲突。检查系统里正在生效的 VPN，必要时暂时退出另一工具做对比。安全软件的明确拦截提示也应记录，但不要直接关闭全部防护并长期保持。
Android 需要确认 VPN 授权及适当后台条件，Mac 则可能涉及网络扩展权限。系统更新后先查权限变化，再判断是否需要重装。
第五步：目标网站也有自己的状态
若其他网站都正常，目标自身服务故障、地区策略或对 VPN 出口的限制，也可能解释当前表现。用同一设备在另一可信网络上做对比，有助于缩小范围，但不要为测试敏感账户而连接来路不明的开放 Wi-Fi。
| 得到的结果 | 说明什么 | 接下来做什么 |
|---|---|---|
| 所有网络任务失败 | 基础联网或系统层问题更值得先查 | 回到 Wi-Fi 认证与设备网络设置 |
| 只在某模式失败 | 路径规则可能参与影响 | 记录模式、例外和目标 |
| 只在一个站点失败 | 可能与目标或其连接路径有关 | 查目标状态，准备具体反馈 |
| 重连后恢复 | 旧会话可能受换网影响 | 保留发生条件，观察是否重复 |
把可复现结果交给支持，而不是交出密钥
lantern问题仍持续时，通过应用内支持提供设备、系统、网络类型、失败目标和已做的检查。截图先遮盖账号、订单与私人接入配置。完整的检查顺序可在十二项故障知识库继续查看，路由关系则见智能分流专题。
换网后的故障可能涉及多个环节。逐层记录与复查，能缩小原因，也能避免反复改乱原本正常的设置。