一、客户端已启动，却无法上网
先区分“所有网站都打不开”和“只有部分网站打不开”。前者优先检查代理入口与服务器连接；后者优先检查路由规则和 DNS。浏览器显示无法连接，并不能单独证明服务器故障：请求可能根本没有进入客户端，也可能进入后被路由到不合适的出口。按下面的顺序做，每一步都保留测试结果。
确认选中服务器与运行状态
在 v2rayN 服务器列表中确认有一条当前选中的服务器。只导入订阅而没有选中条目，或订阅更新后原条目被替换，都可能让后续检查失去对象。打开客户端日志，先看启动时有没有配置读取错误、内核启动失败、端口占用或连接失败。若启动阶段就报错，先处理日志中的第一条明确错误，不要直接修改 DNS。
临时选择另一条已知可用的服务器复测。如果只有一条失败，优先检查该条目的地址、端口和传输设置；如果全部失败，再看本机代理入口和网络环境。服务器信息应以订阅提供方或自行管理的服务端配置为准，不要凭记忆补填用户 ID、PublicKey、ShortId。修改前可以先复制原条目，便于对照和回退。
核对系统代理与访问范围
在 v2rayN 的系统代理菜单检查当前状态。浏览器依赖系统代理时，客户端运行并不等于操作系统已经把浏览器流量交给它；把系统代理切到需要的模式后，关闭并重新打开一个浏览器窗口测试。还要查看浏览器是否配置了独立代理或扩展，这些设置可能覆盖系统代理。其他应用是否遵循系统代理，取决于应用自身实现。
若只想验证代理链路，可以短暂切换到全局代理测试同一个目标。全局模式可访问、原路由模式不可访问，说明入口和服务器大体可用，应转去核对路由规则，而不是反复重装。测试结束后恢复原模式，避免将一次诊断改动长期留在日常配置里。TUN 能接管更多流量，但不适合拿来掩盖尚未确认的系统代理问题。
用日志定位请求停在哪一层
在客户端打开日志视图，然后只访问一个测试页面，观察是否出现对应的连接记录。完全没有记录时，先检查系统代理、应用独立代理或 TUN 入口；有请求记录但显示目标解析失败，转到本页的 DNS 章节；出现连接远端超时，转到节点超时章节。日志里若直接指出规则匹配了直连或阻断出口，则应查看路由配置。
测试时保持同一个浏览器、同一个目标和同一条服务器，避免多个标签页的请求混在一起。不要把日志中的“客户端已启动”理解成“目标网站已经通过代理连通”：它只证明程序进入运行状态。必要时分别测试一个通常走直连的站点与一个明确需要当前代理规则处理的站点，比较两次请求的匹配结果。
排除本机网络与代理残留
暂时关闭客户端的系统代理设置，确认设备在当前网络下能否正常访问原本允许直连的页面。如果直连也不通，先处理 Wi-Fi、有线连接、网关或操作系统网络设置；代理客户端无法修复断开的基础网络。再检查是否有其他代理应用占用同一监听端口，或在系统里留下旧代理地址。日志中的端口占用通常比反复切换节点更值得先处理。
完成排查后，把系统代理和路由模式恢复到计划使用的状态，并重复最初失败的操作。若问题只发生在某个应用，先查该应用的代理选项与网络权限，不要把单个应用的行为概括为整机故障。关于“连接成功但打不开网页”等短问答，还可以查阅帮助中心；需要逐步重建基础配置时回到教程。
二、节点超时或连接反复断开
节点超时表示一次连接未在规定时间内完成，并不自动指向某个固定原因。服务器地址解析、目标端口、传输协议、传输层安全和当前网络都可能参与其中。先看是否只有一条节点超时，再核对其配置；如果同一订阅下全部超时，要先检查共同使用的网络入口、订阅内容和客户端运行状态。
先比较范围，不把测速当最终结果
在同一网络里分别测试当前条目和另一条已知可用的条目，记录是“单节点失败”“同一分组失败”还是“全部失败”。客户端的延迟测试只探测特定连接路径，结果不能代替网页或应用的实际访问测试。延迟测试通过而网页失败时，应继续查路由、DNS 和应用代理；延迟测试失败但某些业务可用时，也不要仅凭一个读数删除服务器。
再换一个正常可用的网络进行对照，例如从当前 Wi-Fi 切换到移动网络。若同一配置只在一个网络中失败，检查该网络的 DNS、网关以及是否允许相应的连接方式。若不同网络均失败，而且其他节点正常，重点落在该条目的服务端状态和字段匹配上。保留测试时间和日志中的错误类型，向配置提供方反馈时会比一句“节点不能用”更有用。
逐字段核对服务器配置
在“编辑服务器”中依次核对地址（address）、端口（port）、用户 ID（id）、传输协议（network）和传输层安全（TLS）。这些字段需要与服务端保持一致，不能仅靠协议名相同就假定可互换。使用 VLESS 与 REALITY 时，还应核对 SNI、Fingerprint、PublicKey、ShortId，以及服务端要求的流控（flow）；某些字段允许留空，但是否留空由实际服务端配置决定。
修改时每次只动一个有依据的字段，并记录修改前的值。服务器地址是域名时，先检查域名能否被当前网络解析；它是 IP 地址时，DNS 通常不是该连接入口的第一嫌疑。若使用 WebSocket 等传输方式，还需查看相应的路径和主机名设置。把订阅导入时得到的字段与手动编辑后的条目对比，能发现复制时漏掉的传输参数。
看清日志里“超时”的位置
日志显示解析服务器域名失败，应先查本机 DNS 或订阅所用的域名；显示建立远端连接超时，则检查地址、端口、基础网络和服务端运行状态；若连接建立后才出现安全握手错误，就应重点核对 SNI、证书相关设置或 REALITY 参数。错误发生的阶段不同，解决路径也不同，不建议看到“timeout”就直接更换内核。
在 Windows 可用系统自带的名称查询命令辅助判断域名是否能解析。下面的域名只是查询语法示例；实际排查时，替换为自己有权检查的服务器域名。查询能返回地址，只说明解析阶段完成，不代表远端端口可达，也不代表协议握手成功。
nslookup v2raypeizhi.com断开后自动恢复与稳定性
若连接最初正常，使用一段时间后才中断，记录中断时设备是否休眠、网络是否从有线切到无线、系统是否从待机恢复。移动网络切换或电脑睡眠会让既有连接失效；此时先重新发起请求，确认新连接能否建立。只有新连接也持续失败，才按节点故障继续排查。不要把应用保持的旧连接错误与新建连接能力混为一谈。
同时检查客户端是否存在多个同时运行的实例，及本机安全软件是否拦截内核进程或监听端口。若某条节点长期不稳定，保留其原始配置并与同分组其他条目对照；不要批量覆盖所有服务器设置。需要理解 Xray 与 V2Fly 的功能差异，可读内核选择笔记，但换内核应建立在协议兼容性判断上。
三、订阅更新失败或服务器列表为空
订阅更新涉及“获取订阅内容”和“解析内容并写入分组”两个阶段。报错时先分清请求没有取得内容，还是取得内容后客户端无法识别；列表为空还可能只是当前过滤条件隐藏了服务器。不要在原订阅上反复改地址、分组和过滤词，先保存现有设置，再逐项确认。
核对订阅地址和当前网络
进入 v2rayN 的订阅分组设置，确认地址没有复制进多余空格、换行或被截断，并检查该分组是否仍处于启用状态。订阅地址通常含有访问凭据，应当视作私密信息：不要把完整地址贴进公开截图或求助帖。需要向提供方反馈时，只描述错误类别、发生时间和客户端，不公开整条链接。
更新失败时先确认设备本身可以访问普通网页，再根据订阅分组中的更新方式检查请求是否需要经由已有代理。第一次导入时尚无可用节点，若把获取订阅的路径设成只能依赖当前代理，就可能形成“必须先有节点才能更新”的循环。已有节点能用、只有订阅请求失败时，则分别测试直连与通过代理更新的设置，选择符合订阅地址实际可达性的方式。
区分网络错误与内容错误
日志提示域名解析失败或连接超时，优先检查地址对应域名、网络连通性和获取路径；提示访问被拒绝或返回的内容不是订阅格式，应联系订阅提供方核对授权与内容类型。客户端能下载到一个网页，并不代表网页就是可导入的节点清单。如果地址在浏览器里打开的是登录页、说明页或错误页，继续点击更新也不会生成有效服务器。
如果日志指出解析失败，先不要手工把返回内容塞进服务器编辑窗。订阅通常包含多条配置，单条服务器字段并不能完整表达分组、过滤和更新规则。可新建一个临时订阅分组，只填入已经确认的地址测试；临时分组能正常更新，说明原分组的更新方式或过滤配置更值得检查。确认原因后删除临时分组，避免重复服务器长期并列。
服务器已导入却看不到
检查当前选中的订阅分组、列表搜索框和关键词过滤条件。分组切换后，列表可能只展示该分组；过滤词也可能把所有条目隐藏。先清空搜索条件并显示全部服务器，再看日志或更新结果是否确实写入了条目。不要因为空列表立刻认定订阅源失效，特别是在刚调整过关键词规则之后。
导入成功但数量与预期不同时，确认订阅提供方是否调整了内容，再检查去重、筛选和分组归属。不同订阅的服务器名称可能相似，不能只用名称判断配置完全相同。多个来源日常整理的方法见v2rayN 多订阅分组管理；排查阶段建议暂时使用最少的过滤条件，恢复可见性后再逐条加回。
让更新过程可复现
记录“手动更新一次”的准确结果，而不是连续快速点击。一次请求尚未结束时再次触发更新，日志可能交错，难以判断究竟哪次失败。更新前后分别看分组名称、服务器列表和最后一次明确错误；如果同时有多个订阅，逐组更新，找出只有一个来源失败还是所有来源都失败。所有来源都失败通常更值得先查设备网络与请求方式。
若旧节点仍能使用，先保留它们完成网络验证，不要为修订阅问题删除整组现有服务器。若旧节点也同时失效，检查是否发生了网络切换或系统代理状态变化，再回到无法上网章节确认入口。订阅更新与节点连接是两条不同链路：前者失败不必然使已保存的节点立即不可用，后者正常也不保证订阅地址一定可访问。
四、能连接，但打开页面或下载很慢
速度问题先拆成“首次打开慢”“持续传输慢”和“只有某个应用慢”。首次打开常涉及 DNS、建连与安全握手；持续传输还受服务器负载、线路和本地网络影响。不要只看客户端延迟排序就断定吞吐表现，也不要同时换节点、改 DNS、开启 TUN 后把改善归功于其中一项。
建立可对照的测试条件
在同一设备、同一网络和相近时间，分别用原节点与另一条已知可用节点访问同一类页面。先关闭正在运行的大文件传输，再观察是首屏等待长还是页面资源持续加载慢。若只有一条节点慢，优先检查该节点及其远端状态；若全部节点都慢，还要测试设备不使用代理时的基础网络。基础网络自身拥堵时，更换客户端设置通常不会解决根因。
浏览器会缓存资源，重复打开同一页面的结果可能被缓存影响。对照时可选多个常用页面，关注是否普遍出现同一现象，而不是追求一次测试得出精确速度。观察客户端日志里是否有大量重试、握手失败或连接被重置；这些现象比单个延迟数值更能说明网络传输不稳定。测试时保留原路由模式，以免改变实际经过的出口。
判断是不是路由绕行
如果本来应该直连的服务也变慢，查看 v2rayN 路由设置中的规则顺序、匹配条件和出口。规则通常按顺序匹配，放在前面的宽泛规则可能先捕获请求，让后面的精确规则没有机会生效。打开日志，针对一个明确变慢的目标查看它匹配了哪条规则，再决定是否调整；不要靠随意移动整组规则来碰运气。
短时间切到全局代理做对照可以帮助判断分流，但不能单独证明某个路由规则有错：全局模式也可能把原本直连的流量改道。若“某些站点慢、另一些正常”，应分别记录域名、解析结果与路由出口。修改规则后至少复测原来慢的目标和原来正常的目标，避免修好一个场景却让另一类请求走错路径。
检查 DNS 等待与连接重试
页面长时间空白后突然完整出现，先看浏览器网络信息和客户端日志是否停在解析或首次建连。DNS 问题不一定表现为彻底失败，解析到不可达地址、上游响应慢或解析与路由不一致，都可能拖长等待。相关检查可直接跳到DNS 章节；需要理解分流解析与路由联动，可看DNS 分流配置笔记。
如果日志显示不断重新连接同一远端，先按节点超时章节核对传输设置和网络稳定性。不要将重试产生的等待直接归咎于 DNS。使用 TUN 时，还要比较关闭 TUN、只用系统代理时的表现；若问题只随 TUN 出现，应检查 TUN 接管范围与本机其他网络工具是否冲突，而不是先更换所有订阅。
确认应用、设备和网络边界
只有一个应用慢时，查看该应用是否自己设置了代理、是否复用了旧连接，以及是否有独立的 DNS 或网络加速设置。浏览器正常而下载器慢，常说明两者走了不同入口；先弄清流量路径，再讨论节点性能。电脑从休眠恢复后出现短暂慢速，可先重新建立连接并在稳定网络下复测。
如果多台设备在同一网络下都变慢，检查路由器负载、无线信号及网络提供方状态；如果同一设备换网络立即恢复，则更应检查原网络。必要时把“网络、客户端、节点、目标应用、路由模式、是否开启 TUN”记成一张简单对照表。这样能明确变化发生在哪个变量上，也便于之后恢复原设置。
五、DNS 解析错误、污染或解析与路由不一致
DNS 负责把域名转换成连接可用的地址；路由决定请求从哪个出口发出。两者不是同一个开关。浏览器报找不到服务器、某个域名偶尔能打开、使用域名失败但使用已知地址能连通，都值得检查解析链路。先确定“谁在解析、何时解析、解析结果交给哪个出口”，再考虑更换上游或启用 FakeDNS。
先查服务器域名，还是目标网站域名
连接节点之前，客户端可能需要解析服务器地址；代理连接建立之后，访问目标网站又可能触发另一轮解析。日志中的失败域名属于哪一层非常关键：服务器域名解析失败，会使该节点从一开始就无法连接；目标网站域名解析失败，则可能表现为只有部分网站打不开。先记下日志中明确出现的域名类型，不要把两类问题混成一个“DNS 不好”。
可使用系统自带的查询命令观察当前设备能否取得域名记录。示例使用本站域名，只展示操作形式；解析结果随网络和时间变化，不应照抄为固定配置。命令成功不等于客户端一定使用同一个解析器，浏览器、操作系统、客户端和 TUN 环境可能走不同的解析路径。比较结果时要写清是在哪个入口执行的查询。
nslookup v2raypeizhi.com按域名与出口核对 DNS 设置
查看 v2rayN 的 DNS 设置和路由设置，确认目标域名最终走直连还是代理，再看对应路径采用哪个解析方式。直连流量若得到只在另一网络可达的地址，或代理流量提前在本地得到不合适的解析结果，都可能造成“规则看起来正确但连接失败”。调整前备份现有 DNS 配置；一次只改一个上游或一类域名规则。
使用自定义 DNS 配置时，关注规则匹配顺序与默认上游：精确域名规则没有匹配时，请求会落到默认路径。DoH、传统 DNS 与系统解析可以按需求搭配，但新增上游本身也需要具备可达的网络路径；若上游域名尚需解析，还要考虑它的引导解析。具体配置块与排查顺序见V2Ray DNS 分流配置详解。
什么时候检查 FakeDNS
FakeDNS 会先为域名分配虚拟地址，再结合流量嗅探把后续连接关联回域名。它常用于需要接管设备流量、又希望保留域名供路由匹配的场景；不是“DNS 出错就打开”的通用修复按钮。若嗅探没有覆盖实际流量，或某个应用直接依赖解析得到的真实地址，开启后反而可能产生新的不兼容现象。
排查时先在原设置下记录失败目标，再单独改变 FakeDNS 相关设置并复测同一个应用。只有启用或停用这一项能稳定改变结果，才继续检查嗅探、虚拟地址映射及路由规则。使用原理与边界可查FakeDNS 原理说明。不要把分配到的虚拟地址当作远端服务器的真实地址，也不要据此修改服务器条目的 address 字段。
处理缓存与偶发解析差异
改过 DNS 以后，浏览器、操作系统或应用可能继续使用此前缓存的结果。先关闭并重新打开测试应用，再在相同网络下复测；必要时使用系统提供的 DNS 缓存清理功能。清缓存只能清除旧答案，不能修复错误的上游选择或错误的路由出口。若短时间后故障重现，应继续比较实际请求路径，而不是反复清缓存。
若仅某个域名异常，记录域名、故障时段、所用网络、路由匹配结果和解析阶段的日志；若所有域名都异常，先检查本机网络及 DNS 上游是否可达。对照时不要同时启用新的 DoH、FakeDNS 和 TUN。把每一步的“改变了什么、结果是什么、是否回退”写下来，才能确认到底是哪一层解决了问题。
六、系统代理已开启，但应用没有走代理
系统代理是操作系统提供给应用参考的一组代理设置，不是强制接管所有网络流量的总开关。v2rayN 可以设置系统代理，也可以通过 TUN 接管更多流量；两者的作用范围不同。排查重点是先确认应用是否读取系统代理，再确认代理地址与客户端实际监听入口一致，最后才决定是否需要 TUN。
检查设置是否写入系统
在 v2rayN 中检查“系统代理”当前选择，确认不是关闭状态。切换后重新启动要测试的应用，避免它继续使用旧的代理设置或长连接。Windows 的系统代理界面可用于交叉确认当前代理是否写入；如果界面显示旧地址或旧端口，先检查是否同时运行了其他会修改系统代理的工具，再回到 v2rayN 重设。
某些应用提供独立代理选项，可能优先使用应用内设置，也可能明确选择“不使用代理”。先在应用设置里查“使用系统代理”“自动检测”或“手动代理”一类选项，不要默认它会跟随操作系统。浏览器可工作而某个命令行工具不可工作，是常见的入口差异；应按该工具的代理机制处理，不能只依据系统代理开关判断。
区分系统代理、路由与 TUN
系统代理决定哪些遵循系统设置的应用把流量送到客户端；路由决定已经进入客户端的请求从哪个出口出去。若日志里完全没有目标应用的请求，改路由规则通常不会有帮助。先解决“请求是否进入”，再解决“进入后去哪里”。反过来，日志里能看到请求且匹配了错误出口，就应查路由，而不是反复开关系统代理。
TUN 适合需要处理不遵循普通系统代理的流量，但启动它可能涉及系统权限、虚拟网络接口和与其他网络软件的兼容性。先在只开系统代理的情况下建立一个可复现的测试，再开启 TUN 比较差异。若 TUN 一开就断网，立即关闭并检查客户端日志、权限与本机其他虚拟网卡；不要同时保留多个接管同一路由的工具。
按平台理解代理入口
桌面端以 v2rayN 为主，但不同操作系统和不同应用对系统代理的遵循程度不一致。检查时使用同一应用做开启前后的对照，再看客户端日志是否出现它的请求。以下表格用于判断排查方向，不表示表中所有应用必然采用同一种代理方式；具体行为仍以应用设置和实际日志为准。
| 环境 | 优先检查 | 进一步验证 |
|---|---|---|
| Windows · v2rayN | 系统代理状态、应用独立代理 | 客户端日志是否出现应用请求 |
| macOS · v2rayN | 当前网络服务的代理设置 | 切换网络后重新检查设置 |
| Linux · v2rayN | 桌面环境及应用各自的代理选项 | 对照应用是否读取相应设置 |
| Android · v2rayNG / v2flyNG | 连接状态、VPN 授权 | 前台测试应用请求是否恢复 |
清理旧设置并复测
客户端异常退出后，操作系统可能仍保留指向本机代理端口的设置。此时应用会把流量送往已经停止监听的入口，表现为客户端关闭后网页也打不开。重新启动 v2rayN 并正确关闭系统代理，或在操作系统网络设置中核对并清除旧代理；再确认直连访问恢复。不要在未知代理地址仍生效时直接删除配置目录。
如果切换网络、从休眠恢复或启动另一个网络工具后问题再现，记录哪个动作改变了系统代理设置。最后分别测试直连、系统代理和目标应用：直连是否正常、客户端是否收到请求、路由出口是否符合预期。按这个顺序得到的三项结果，比“代理开着但没用”更能准确定位下一步。
七、客户端无法启动、闪退或内核启动失败
界面进不去、界面能打开但内核起不来，是两类不同故障。先确认失败发生在哪一步：双击后没有窗口、窗口打开随即退出、导入配置后退出，还是点击连接时内核报错。保留日志和当前配置，再处理安装环境与配置错误；不要先删除所有用户数据重新安装。
检查安装包与运行环境
确认安装的是与操作系统、处理器架构相符的客户端。桌面端优先使用 v2rayN；Windows 用户可在下载中心 Windows 区区分桌面版与经典 WPF 版，macOS 与 Linux 用户应分别按平台选择。把应用放到有正常读写权限的位置，避免从权限受限或只读的位置直接运行，也不要在下载仍未完成时打开文件。
如果更新后才发生启动问题，先记下更新前后的操作、所用安装形式与报错内容，再检查是否有旧进程仍在运行。重复启动多个实例可能造成监听端口冲突；在系统任务管理工具中结束已停止响应的旧实例后，再尝试单独启动一次。重装前保存订阅分组和自行编辑的配置，避免把“程序启动故障”变成“配置丢失”。
界面正常但内核报错
打开 v2rayN 日志，关注第一条明确的配置解析、端口监听或内核启动错误。端口占用时，找出是否有另一个客户端实例或本机软件占用了对应入口；配置解析错误时，回看最近一次修改的服务器字段、路由或 DNS 配置。不要只复制日志末尾的“启动失败”，因为那通常是前面具体错误的结果。
可临时选择另一条未经手动改动的服务器，并停用最近新增的自定义规则复测。如果这样能够启动，再逐项恢复原设置，定位是哪一项触发错误。使用不同内核时，还要确认所选协议与参数是否被当前内核支持；Xray 与 V2Fly 并非所有功能完全对应。具体差异见Xray 与 V2Fly 内核区别。
排除权限、安全软件与配置损坏
如果日志显示文件读写失败，检查程序所在目录和配置目录的权限，以及磁盘剩余空间。安全软件提示拦截时，先查看它给出的实际文件、动作和时间，再判断是否与此次启动失败对应；不要为了排错直接长期关闭系统保护。需要更换安装位置时，先备份自己的订阅信息和自定义设置，再用正确平台的安装包重新部署。
若程序只在加载现有配置时退出，可在保留完整备份的前提下，用干净配置测试能否打开界面。干净配置可启动，说明问题更可能在原配置或其引用的文件；仍不能启动，则更应检查安装环境与系统日志。不要将含订阅地址的完整配置文件公开上传，求助时可只提供隐去敏感字段后的错误信息。
建立可重复的恢复顺序
先让界面稳定打开，再确认内核能够启动，接着导入一条有依据的服务器配置，最后恢复订阅、路由和 DNS 自定义项。每恢复一步都启动并查看日志，就能定位哪一步重新引入故障。若直接导入全部旧设置后问题重现，仍无法知道是哪一部分引起，因此恢复顺序本身就是诊断过程。
解决后再检查系统代理是否仍指向当前运行的客户端，以及退出程序后系统代理能否正常关闭。崩溃和代理残留经常连续出现，但应分别处理：前者看程序与配置，后者看操作系统代理状态。若只是遇到常见安装疑问，可先查帮助中心；需要从头配置时按教程重新走一次主线。
八、Android 连接、后台运行与应用分流
Android 端优先检查 v2rayNG；需要使用 V2Fly 内核对应客户端时可选择 v2flyNG。两者都应按下载中心 Android 区的设备架构选择安装入口。桌面端“设置系统代理”的排查方法不能原样套到手机：Android 客户端主要依赖系统 VPN 授权建立设备上的流量入口，还会受到后台限制和应用分流设置影响。
连接按钮已点，先看 VPN 授权
在客户端选中服务器后启动连接，留意系统是否弹出 VPN 连接请求。首次使用、重新安装或权限变化后，可能需要再次确认授权。客户端显示正在连接却始终没有稳定的系统 VPN 状态时，先检查授权流程是否完成，以及系统里是否已有另一个 VPN 服务正在占用入口。不要在两个同类服务之间反复快速切换，先停止其中一个再测试。
如果已显示连接状态，但所有应用都无法访问，打开客户端日志，检查服务器地址、端口和传输层设置，再用另一条已知可用的服务器对照。手机从 Wi-Fi 切换到移动网络后，已有连接可能断开，应重新发起请求确认是否恢复。若同一配置只在一个网络里失败，重点记录该网络条件，而不是先删除手机上的所有服务器。
只有个别应用不通
检查客户端的分应用代理或绕行设置，确认出问题的应用是否被排除。再看该应用是否只在后台无法访问，还是保持在前台也无法访问：前台失败更值得检查分流与应用本身的网络设置；仅后台失败则还需看系统对后台活动的限制。某些应用会持有切换代理前建立的旧连接，完全关闭后重开再做一次对照。
如果浏览器能访问、某个应用不能访问，先不要认定节点失效。保持同一节点和同一网络，分别测试两个应用，并观察客户端日志是否有请求进入。没有请求记录时检查应用分流、VPN 接管与系统权限；有请求但匹配了不同出口时检查路由设置。应用自己采用的解析方式也可能不同，必要时结合本页 DNS 章节比较。
锁屏或切后台后断开
手机系统可能限制后台活动或省电状态下的网络连接。先测试客户端保持前台时是否稳定，再锁屏一段时间复测；如果问题只出现在后台，检查系统针对该客户端的电池管理、后台运行和通知权限设置。不同设备的菜单名称不完全相同，按系统实际界面查找，不必照搬另一品牌手机的设置路径。
即使允许后台运行，网络在 Wi-Fi 与移动数据之间切换时也可能需要重建连接。发生断开时记录是否同时切网、是否开启省电模式以及客户端是否仍显示运行状态。只调整一个系统设置并复测，避免为了保持后台连接一次关闭多项与问题无关的系统限制。恢复后，再确认设备日常使用时的电池消耗符合个人需要。
订阅与两款客户端的配置差异
Android 订阅失败时，同样先分辨获取失败、内容解析失败与列表被过滤。复制订阅地址时注意不要带空格或换行，也不要在公开截图里展示完整地址。若 v2rayNG 中使用了依赖特定内核能力的配置，不应假定 v2flyNG 导入后具有完全相同的行为；应依据实际协议参数和客户端日志判断兼容性。
排查结束时，检查选中的服务器、VPN 状态、应用分流、后台权限和当前网络，逐项记录最终生效的设置。若桌面端与手机端使用同一订阅，两个设备出现不同结果，先比较各自的网络和内核能力，不要立即修改订阅源。想了解三款客户端各自适用的平台与定位，可看客户端对比；基础导入步骤仍以教程为起点。