v2rayN 故障排查大全

无法上网：先分清流量停在哪一层

“无法上网”可能是本地网络断开，也可能是应用没有进入代理、内核启动失败或远端连接不可用。先记下影响范围：所有应用都失败，还是只有浏览器失败；所有网站都失败，还是单个域名失败。范围不同，检查入口不同。不要同时更新订阅、切换内核和打开 TUN，否则即使恢复，也无法知道哪一步起作用。

恢复直连，建立对照基线

在 v2rayN 中选择“清除系统代理”，关闭“启用 Tun 模式”，再确认系统网络设置没有保留手动代理。退出其他代理工具，重新打开浏览器访问平常可以直连的站点。如果仍无法访问，先检查无线连接、网线、网关和网络登录页面，此时客户端不是优先怀疑对象。公共网络可能需要先完成网页认证，代理设置反而会挡住认证页。

直连恢复后，再启动客户端，保持 TUN 关闭，只测试系统代理这一条路径。若退出客户端后全网反而断开，通常要检查残留代理地址是否仍指向本机已经停止的监听端口。清除代理后重新打开应用，避免旧连接继续复用。浏览器显示的缓存页面不能证明网络已恢复，应刷新一个实际需要联网的页面。

检查活动配置和本地监听

确认列表中已经存在可用配置，并将需要测试的配置设为活动项。订阅分组存在不代表分组里已有节点，添加地址也不等于完成更新。随后查看日志，确认内核没有在启动时立即退出。出现配置解析失败、端口绑定失败或资源文件读取失败时，应先处理本地启动问题，反复切换远端节点不能修复这些错误。

打开客户端的基础设置，记下实际监听地址、端口和协议。应用设置里的代理端口必须与这里一致，不能根据教程示例猜测。监听在回环地址时仅供本机使用，这是正常边界。若日志提示地址已被占用，先找出冲突程序，或者修改监听端口并同步修改应用设置；不要只改其中一端。

用最小路径区分入口和出口

先使用一个浏览器、一个测试目标和一条活动配置。将系统代理设为“自动配置系统代理”，暂时停用浏览器中接管代理的扩展。若客户端日志出现对应目标请求，说明流量至少已经到达本地入口；接下来检查路由命中和远端报错。若完全没有请求，优先排查浏览器独立设置、系统代理写入和应用是否绕过代理。

还要看失败请求最终走向直连还是代理。规则把测试域名分到直连时，失败不能用于证明代理节点不可用。可以临时选择客户端提供的明确代理测试路径，完成后恢复原路由。不要为测试永久改成所有流量代理，也不要删除原规则；保持可撤销，才能避免局域网访问、办公资源或其他应用受到影响。

按结果进入下一章

本地入口正常而远端握手失败，进入节点超时章节；域名失败但其他目标正常，进入DNS 问题章节；浏览器正常、终端失败，进入系统代理章节。每次修改后都用相同目标复测，并记录失败提示是否改变。错误从连接拒绝变成握手失败，代表问题位置发生了变化，不应一概记为“仍然不能用”。

节点超时：区分连接、握手与目标响应

超时只是等待超过限制，不直接说明服务端失效。建立连接、协议握手、域名解析和目标页面响应都可能超时。先打开日志，找到与测试时间接近的第一条错误，而不是只看最后一行。前面的解析失败或连接被拒绝，往往比随后连续出现的超时更有定位价值。测试期间减少其他联网操作，让日志中的目标容易辨认。

确认测试测量的是什么

TCP 连通测试通常只能说明指定地址和端口能否建立连接，不能验证身份参数、传输路径或目标网站。实际请求测试更接近使用情况，但又受到测试地址、DNS 与路由影响。某项测试没有返回结果时，不要直接删除配置；先用浏览器访问一个已知目标，并查看客户端是否记录了同一次请求。

若列表里所有配置同时失败，先排查共同因素：本地网络、系统时间、订阅参数和测试目标。若只有一条失败，比较同一订阅内其他配置的表现。比较时保持相同网络和相同测试方式，不要把不同时间、不同目标得到的结果混在一起。大量并发测试也可能触发连接限制，诊断时逐条测试更容易解释。

按日志中的阶段处理

“连接被拒绝”通常表示目标地址可达，但对应端口没有接受连接，或者中间设备主动拒绝。先核对地址和端口，再向服务提供方确认服务状态。“网络不可达”更偏向本地路由、地址族或网络出口问题；“超时”则需要继续分辨是连接建立前还是握手之后。不同内核的报错文本会不同，应结合前后日志理解。

遇到证书、服务器名称或握手相关错误时，核对传输安全设置、服务器名称、传输类型及路径。某些配置的连接地址与服务器名称本来就不同，不能为了看起来一致而自行改写。涉及 REALITY 的配置，还应检查公钥、短标识和指纹是否完整。优先重新导入服务方提供的原始链接，避免逐项猜测造成新的偏差。

检查时间、地址族与网络差异

启用操作系统的自动日期与时间，并确认实际时刻正确。时间偏差可能影响证书有效期判断和部分协议认证；只修改时区而不修正时刻并不能解决问题。若设备刚从休眠恢复，先等待网络和时间同步完成，再重启客户端测试。不要通过关闭证书验证来掩盖时间或名称错误，这会改变原有连接安全边界。

节点域名可能同时返回 IPv4 与 IPv6 地址。网络具有 IPv6 地址不代表对应远端路径一定可用；反过来，也不能假定 IPv6 必然有问题。可以在客户端支持的地址策略中临时限制一种地址族，进行单变量对照，测试后恢复。切换另一条获准使用的网络也有帮助：若结果随网络变化，应继续调查出口路由，而不是立即重建全部配置。

保留参数，向提供方反馈有效信息

刷新订阅后再次测试，确认服务方是否调整了地址、端口或传输参数。若同一配置在不同网络仍持续失败，提供节点显示名称、测试时间、错误阶段和脱敏日志，请对方确认服务端运行状态。不要公开身份参数，也不要用其他配置的密码或标识拼接尝试。客户端能选择内核，不代表任意内核都能解释同一组扩展参数。

节点恢复后，再检查原本失败的实际业务，而不是只看连通测试。若握手成功但单个网站仍超时，调查该网站的路由、解析和目标服务限制。协议字段的含义可查术语表，VMess 与 VLESS 的识别方式可阅读协议区别说明。理解字段用途后再修改，比反复切换选项更容易得到稳定结果。

订阅失败：分开检查地址、下载和解析

订阅更新包含三个环节：客户端向订阅地址发出请求、服务器返回正文、客户端把正文转换为配置列表。任何环节失败都可能显示“更新失败”，但处理办法不同。先判断是请求没有完成，还是请求成功却没有识别到配置。不要只根据分组名称判断成功与否，也不要为了重新导入而直接清空当前仍能使用的配置。

保存地址后执行更新

在“订阅分组设置”中核对地址是否完整保存，再执行“更新全部订阅”。只添加分组不会自动得到节点。复制时注意前后的空格、换行，以及聊天工具附加的标点；带有查询参数的地址尤其不能截断。示例地址 https://example.com/sub?token=xxxx 仅展示格式，实际应使用服务方给出的专属地址。

订阅地址与单节点分享链接不是同一种入口。一个普通网页链接、登录后的控制面板地址，也不一定是订阅接口。应从服务方明确标注的订阅入口复制，不要凭页面外观判断。如果地址已经重置，旧链接可能返回拒绝访问或空内容；此时应替换为新地址，而不是反复修改客户端的解析选项。

判断请求失败还是返回内容异常

查看更新日志中的状态与错误。名称解析失败先检查 DNS；连接超时先检查当前网络到订阅服务的路径；证书错误核对系统时间和服务域名。出现拒绝访问，通常需要检查订阅资格、地址是否过期或访问限制。服务器忙碌时连续点击更新可能加重限流，应等待后再试，并保留首次错误信息。

请求成功也不等于返回了配置。接口可能返回登录页、维护提示或网络认证页面，客户端自然无法解析。若需要查看响应，只在本机受控环境操作，并避免将完整地址写入公开记录。能在浏览器打开某个页面，只能说明浏览器获得了内容；浏览器可能使用不同代理、登录状态和 DNS，不能直接推断客户端请求路径也相同。

选择可工作的更新路径

当前直连能够访问订阅服务时，先用直连更新，减少依赖。若直连不可达，而客户端已有可用配置，可以使用界面提供的经代理更新方式；具体菜单随界面有所变化，以实际设置为准。已有配置全部失效时，经代理更新会形成依赖循环：必须先连接才能更新，却又需要更新才能连接。这时应取得新的有效地址或单节点配置。

更新前记录所用路径，更新后核对日志。不要以为打开系统代理就能强制客户端自身的订阅请求走代理；更新模块可能有独立的网络选择。也不要把无法访问的订阅地址交给不明在线转换服务。订阅通常含有访问凭据，转换方能够读取内容。确需格式转换时，应确认接收方、处理方式和凭据暴露范围。

处理格式兼容与更新后的列表变化

正文非空却提示没有有效配置时，先确认服务方提供的是适合当前客户端的格式。客户端与内核承担不同职责：客户端解析订阅，内核运行生成后的配置。切换内核一般不能修复订阅格式识别问题。可以从安装包页选择适合系统的客户端，再用备份配置做独立测试，不必覆盖现有可用环境。

更新后条目减少，可能是提供方移除了配置，也可能是分组过滤条件隐藏了部分内容。先清除列表筛选，再检查该订阅分组的更新结果。确认新的条目能用后，再整理旧项。若还需比较问题，可保留少量脱敏的协议类型和错误信息，但不要保存或转发完整身份字段。

速度慢：把吞吐、响应和应用差异分开测

打开网页慢、视频缓冲和大文件下载慢，不能简单归为同一种故障。网页受解析、握手和多资源请求影响；连续下载更依赖吞吐与拥塞；实时通信还依赖抖动和丢包。先写清楚“慢在哪里”，再选择相应测试。列表中的响应时间只是某种测试条件下的结果，不代表所有业务的速度排名，更不是服务质量的完整结论。

用相同条件建立对照

选一个稳定目标，在同一设备、同一网络、相近时间内比较直连与代理。暂停系统更新、云盘同步和其他大流量任务，避免后台流量占满上行。无线网络还应留意信号、频段与路由器负载；电脑离路由器很近也不代表无线环境没有干扰。条件允许时，用有线连接作为对照，先排除本地接入层波动。

每次只比较两条配置，保持相同路由和 DNS。不要同时运行多个测速工具，也不要以单次极端结果下结论。测速会产生实际流量，使用按量服务时应控制测试规模。若在某个时段普遍变慢，而其他时段恢复，记录时间分布比反复重装更有价值；这通常需要继续检查网络拥塞或服务端负载。

检查实际出口和目标服务

先确认慢的请求确实经过预期代理。路由规则可能把网页主体和资源域名分到不同出口，导致正文打开但图片卡住。日志中找出具体失败域名，检查是否存在重复重试或某类资源始终走直连。不要因为页面最终打开就忽略其中的超时，浏览器可能等待多个资源后才完成加载。

只有某个网站慢时，还要考虑网站自身、内容分发节点和账户限制。更换代理出口可能改变目标分配的服务节点，但不保证一定改善。若普通页面快、单个下载源慢，应先用另一个合法下载源或同站不同资源对照。目标端限速无法通过调整本地监听端口解决，客户端设置也不能突破实际链路带宽。

识别连接复用、UDP 与路径问题

多路复用会改变连接组织方式，并非越多越快。服务端兼容、丢包情况和应用类型都会影响结果。诊断时先保留默认或服务方推荐设置，若怀疑复用相关问题，再单独关闭进行对照。不要把其他内核的参数直接照抄到当前内核；同名概念的实现和可用字段可能不同，错误参数反而会使内核无法启动。

浏览器可能尝试基于 UDP 的传输，而当前路径对 UDP 的处理与 TCP 不同。若只有某类应用异常，可在应用支持的范围内临时切换传输方式验证，不要立即禁用系统全部 UDP。开启 TUN 后大文件卡住而普通页面正常，还可能涉及路径 MTU；这需要结合网络环境测试，不应照搬一个固定数值作为所有设备的答案。

把优化建立在可复现结果上

如果降低并发后明显稳定，先调查连接限制和拥塞；如果首个请求慢、随后请求快，优先检查 DNS 与首次握手；如果锁屏或休眠恢复后才慢，检查网卡状态和客户端重连。每种现象对应不同方向。简单记录目标、时间、出口、传输方式和结果，通常比保存一张单独的测速截图更有帮助。

确认有效的修改可以保留，其余恢复原值。网络优化没有通用参数包，批量调整会失去对照基础。需要进一步检查解析路径时，继续阅读下一章。

DNS 问题：确认由谁解析、经过哪条路径

DNS 把域名转换为地址，但代理场景里不一定只有一个解析入口。操作系统、浏览器、客户端内核以及远端代理都可能参与。网页提示找不到域名，只能说明某个环节没有得到可用结果。先区分节点服务器域名无法解析，还是目标网站域名无法解析；前者会阻止代理建立，后者通常出现在代理已运行之后，两者不能用同一种办法处理。

比较系统解析与代理内解析

在 Windows 终端中，可以使用下面的系统命令检查目标域名是否得到响应。示例域名用于说明操作，应换成实际出错的域名。记录应答服务器、地址族和报错信息；不要只看到一行地址就判定解析路径正确，因为不同解析器可能返回不同的内容分发地址。

nslookup example.com

系统查询成功，不表示内核远程 DNS 一定成功；系统查询失败，也不表示代理必然失败，某些请求会把域名交给远端处理。接着查看客户端日志中的 DNS 请求与最终连接地址。如果浏览器开启了独立的安全 DNS，应单独记录该状态。诊断时可暂时使用一种明确的解析路径，完成对照后再决定是否恢复浏览器原设置。

避免解析入口形成循环

使用加密 DNS 时，解析器本身可能需要先解析域名、建立连接，再发送查询。如果这个解析器只能通过代理访问，而代理服务器域名又依赖它解析，就会形成启动依赖循环。应明确节点域名的引导解析路径，让代理建立前也能完成必要查询；不同内核的设置名称和配置结构并不相同，不要混用字段。

检查客户端的本地 DNS、远程 DNS 与路由设置是否互相匹配。直连目标交给不可直达的解析器，或者代理目标使用不适合当前网络的系统应答，都可能导致异常。修改后重新建立连接再测，避免旧缓存影响判断。只清理浏览器缓存无法清除所有层的 DNS 结果，必要时还应重启客户端与相关应用。

理解 TUN 接管与局域网名称

TUN 可以接管更多流量，但并不意味着所有解析请求自动遵循同一策略。应检查 DNS 劫持、虚拟网卡、应用排除和路由规则是否生效。如果应用使用独立的加密解析通道，普通 DNS 劫持不一定能处理。不要只看 TUN 开关状态，要结合日志确认请求是否进入内核，再确认采用了哪个解析器。

打印机、文件服务器和办公内网可能依赖本地 DNS 或特定搜索域。把所有查询强制发送到外部解析器，可能使这些名称失效。应保留局域网及组织内部域名的解析路径，并遵守网络管理员的设置。只给私有地址配置直连规则还不够：如果内部域名在解析阶段就失败，请求根本不会进入后续地址路由。

分别验证解析正确与隐私边界

能正常打开网页与解析请求符合预期，是两个检查目标。在线检测页显示的是该页面触发的部分查询，不能代表设备上所有应用；解析器运营方的位置也不一定等于实际网络出口。应结合浏览器设置、内核日志和应用行为判断，不要仅凭检测页的一个地区标签就认定泄漏或修复成功。

修复后至少测试普通域名、原故障域名和需要保留的局域网名称，再检查 IPv4、IPv6 是否出现不同结果。记录修改前后的解析器与出口，避免下一次切换网络后无法复现。更完整的检测步骤可阅读DNS 泄漏检测与配置实操，其中的选项仍需结合当前内核和实际界面使用。

系统代理不生效：浏览器与终端分别定位

系统代理是一组供应用读取的网络设置，不是对全部网络流量的强制转发。应用可以遵循它、使用独立代理，也可以直接联网。因此浏览器能用而终端不能用，并不矛盾。先确定出问题的应用采用哪种代理机制，再检查入口地址和端口。只有应用请求确实进入客户端后，路由和节点设置才会影响这次请求。

核对三种系统代理模式

“自动配置系统代理”用于让客户端按自身设置配置系统代理；“清除系统代理”用于移除相应代理设置；“不改变系统代理”表示客户端不主动修改当前状态，不等同于清除。若其他程序已经设置了代理，选择不改变后它可能仍然存在。检查时应直接打开操作系统网络设置，确认当前实际值，而不只看客户端菜单。

设置完成后重新打开需要测试的应用，有些程序只在启动时读取代理。若界面显示已切换但系统值没有变化，检查权限、组织策略，以及其他代理程序是否立即覆盖。受管理设备应遵循组织要求，不要强行修改策略。也不要让两个客户端同时持续写入系统代理，这会产生看似随机的切换和连接失败。

排查浏览器独立设置与扩展

关闭浏览器中接管代理的扩展，再检查浏览器自己的网络设置。有些浏览器可使用系统代理，也可手动指定另一组代理。旧的 PAC 地址、手动代理或绕过列表都可能改变流量方向。使用全新浏览器配置做对照，比只开隐私窗口更可靠，因为部分扩展和策略仍可能在隐私窗口生效。

留意“本地地址不使用代理”等绕过规则，它们会使某些目标直接连接。访问局域网资源时这通常是合理行为，不能因为日志没有记录就认定系统代理失效。若要测试代理入口，应选择不在绕过列表中的目标。浏览器的独立 DNS 设置也要一并记录，否则同一代理设置下仍可能出现解析差异。

让终端显式使用正确的协议

命令行工具对系统代理的支持各不相同，可以用显式代理参数做单次测试。下面假定本机 HTTP 监听确实设为 127.0.0.1:10809；执行前必须改成客户端显示的实际 HTTP 或混合监听端口。这是测试示例，不是对默认端口的约定。Windows PowerShell 中使用 curl.exe 可明确调用对应程序。

curl --proxy http://127.0.0.1:10809 --head https://example.com

若使用 SOCKS 入口，则应选择工具支持的 SOCKS 代理参数。socks5h 通常表示将域名交给代理端解析，而 socks5 的本地解析行为需要按工具文档确认。不能把 HTTP 代理地址直接填到只接受 SOCKS 的选项里。还应检查 http_proxy、https_proxy、ALL_PROXY 与 NO_PROXY 是否残留旧值。

明确 TUN 与局域网共享的边界

确实不读取代理设置的应用，可以在了解影响后测试 TUN。桌面端通常需要管理员权限或相应授权，还应检查虚拟网卡和默认路由。先关闭其他虚拟专用网络或代理接管功能，避免争用路由；但组织要求保留的连接不应擅自关闭。TUN 不负责修复错误的节点参数，也不是系统代理失败时必然有效的替代方案。

手机通过电脑共享代理时，不能填写手机自己的回环地址。电脑需要允许局域网连接，手机填写电脑内网地址及正确端口，防火墙只对所需可信网络放行。详细操作见局域网代理共享教程。浏览器与终端的完整对照过程见系统代理不生效专项排查，修复后记得移除测试用的长期环境变量。

客户端崩溃：分清界面退出与内核停止

窗口消失、进程退出和内核停止是不同事件。先检查任务栏托盘与系统进程列表：关闭窗口可能只是隐藏到托盘；界面仍在但代理停止，则可能是内核启动失败。记录问题发生在启动、导入配置、切换节点还是休眠恢复之后。触发动作比“闪退”这个概括更有价值，也决定应检查运行环境、配置内容还是权限。

先保存数据，再建立独立测试环境

在能够打开界面时，使用客户端提供的导出或备份功能，妥善保存订阅分组和必要设置。无法打开时，先复制原有用户数据再继续处理，不要直接删除整个目录。配置中可能包含凭据，备份应放在受控位置。迁移或测试时也应避免把同一份正在写入的数据目录交给两个实例同时使用，以免产生锁定或内容冲突。

从安装包页选择与操作系统、处理器架构匹配的包。Windows 桌面版采用跨平台界面，WPF 版保留经典界面；两者可用于界面兼容性对照，但不能据此断言节点参数也已改变。建立独立测试环境时先不导入全部历史设置，只添加一条已知有效配置，确认基础启动是否正常，再逐步恢复其他内容。

检查系统运行条件和文件权限

启动前确认磁盘空间充足、用户目录可写，并完成系统提示的必要运行依赖安装。安装目录可读取，不代表日志、缓存和用户配置目录也可写。若日志提到权限拒绝，定位具体路径再处理，不要给整个磁盘放宽权限。安全软件隔离文件时，先核对告警原因和获取来源，不要以关闭全部防护作为长期解决方式。

Linux 桌面启动失败时，可从终端运行安装后的启动命令，观察缺失库、图形会话或权限提示；实际命令应以本机安装入口为准，不猜测二进制路径。macOS 应通过系统正常的应用授权流程处理运行提示，不应整体关闭系统保护。平台部署细节可查Linux 安装与自启动说明，先解决手动启动，再配置自动启动。

从第一条错误定位内核问题

若界面能开而内核立即退出，先检查配置解析错误。错误常包含字段名称或附近位置，可能来自不兼容参数、残缺导入内容或错误的自定义设置。先恢复最近修改的一项，再重启内核。Project V、V2Fly 与 Xray 属于相关生态，但配置结构和扩展能力并不完全一致，不能假定任何片段都能跨内核直接使用。

端口被占用、资源文件不可读和权限不足也会使内核退出。遇到端口冲突，关闭重复实例或修改监听端口；遇到资源文件报错，检查应用安装是否完成、路径是否可读以及内置更新是否成功。不要从不明来源拼装内核文件。TUN 相关错误则先关闭 TUN，确认普通代理能运行，再单独处理授权与虚拟网卡。

按顺序恢复，避免把异常带回去

独立环境正常后，依次恢复订阅、路由、自定义 DNS 和 TUN，每一步重启并测试。若导入某组设置后复现，比较这组设置与基础环境的差异，而不是继续覆盖安装。出现数据库占用或配置损坏提示时，保留原始备份，优先使用应用支持的恢复方式，不要在不了解结构时直接编辑数据文件。

如果问题只在开机自动启动出现，检查是否早于网络就绪、工作目录不同或权限环境不同；如果只在休眠后出现，先等待网络恢复再重启内核。需要反馈时提供系统架构、包类型、触发步骤和脱敏错误片段，不必公开整份配置。恢复使用后检查系统代理是否仍指向有效监听，防止界面已退出而应用继续连接一个不存在的本地入口。

安卓专项：授权、应用分流与后台断连

Android 上以 v2rayNG 为主要选择，其使用 Xray 内核；v2flyNG 是采用 V2Fly 内核的备选客户端。两者的界面和参数支持可能不同，切换应用不是自动修复配置的手段。先记录设备系统、客户端名称、连接方式和触发场景，再判断是首次无法连接、个别应用失败，还是熄屏后中断。不同现象应沿不同路径检查。

确认系统授权和唯一接管者

首次连接时，按系统提示授予建立虚拟专用网络连接的权限。若授权窗口没有出现或被拒绝，先回到系统相关设置检查，再重新发起连接。Android 通常不允许普通应用同时各自占用同一用户环境中的这类连接，因此应检查是否有其他网络接管工具正在运行。工作资料与设备管理策略也可能改变可用范围，应遵循管理要求。

系统显示连接标识，只能证明相应网络服务已建立，不能证明远端节点已经可用。打开客户端日志，再访问一个明确目标，检查是否收到请求以及远端是否握手成功。若所有应用都失败，先测试本地网络和活动配置；若只有一个应用失败，则优先检查应用分流、独立 DNS 或该应用自己的代理设置，不必马上重置全部数据。

处理熄屏、后台与网络切换

连接在前台正常、熄屏后中断时，检查系统电池优化、后台活动限制和设备厂商的应用管理规则。对需要持续连接的客户端按系统提供的方式允许必要后台运行，再观察通知和进程是否被终止。不同设备菜单名称不同，不能照搬某个固定路径。放宽后台限制会增加耗电，应只对确有持续连接需求的应用调整。

从无线网络切换到移动网络后，原有连接可能需要重建。先等待网络获得地址，再在客户端停止并重新启动连接，观察是否恢复。若仅在一种网络失败，比较 DNS、地址族和网络认证情况，而不是立即更换协议。启用“始终开启”或阻止未通过连接的流量时，节点不可用可能表现为整机断网；诊断期间应理解该策略的作用再调整。

检查应用分流和解析范围

应用分流通常有仅代理所选应用、绕过所选应用等不同方向，列表相同而方向相反，会得到完全不同的结果。先确认当前模式，再检查目标应用是否被选中，保存后按需要重新连接。应用更新、工作资料中的副本或不同安装来源，可能对应不同应用标识，不能只凭图标相同认定规则已经覆盖。

如果网页正常但某个应用始终失败，查看该应用是否依赖 UDP、是否使用独立加密解析，以及是否受到目标服务限制。Android 的私人 DNS 与客户端 DNS 设置可能同时影响解析，应做单变量对照。局域网设备发现异常时，还要检查私有网段直连和本地名称解析；让流量绕过代理，不等于自动恢复所有广播发现机制。

安装包、订阅与恢复验证

在Android 安装包入口选择适合设备的架构。主流较新设备通常使用 arm64，但仍应以设备架构为准；无法确定时查看系统信息，或使用页面提供的通用版。安装失败还可能来自系统兼容条件、存储不足、应用签名不同或降级限制，不要只重复下载同一文件。替换已有应用前先备份设置，避免卸载后丢失订阅与分流规则。

订阅更新失败时，沿用本页地址、请求、解析三层检查，不要把剪贴板权限问题和服务端返回错误混为一谈。恢复后分别测试前台访问、熄屏唤醒、无线与移动网络切换，再确认需要代理和需要直连的应用都符合预期。记录有效设置即可，测试用的临时规则应撤销；后续日常操作可返回快速上手教程，概念疑问则查阅常见问题。