01 / LOCAL CHAIN
已连接但无法上网：先检查本地链路
先把“无法上网”拆成可验证的现象
客户端显示“已连接”通常只表示配置已经交给内核运行，不等于浏览器、终端和其他应用都已成功通过节点访问目标地址。首先关闭系统代理或停止当前配置，确认设备通过原始网络能否访问一个平时稳定的网站。如果直连也失败，应先处理路由器、无线网络、网卡或运营网络问题；如果直连正常、启用客户端后全部失败，故障范围才集中到本地代理、路由规则或远端节点。
随后分别测试浏览器与命令行。浏览器能访问而终端失败，多数是两类应用读取代理设置的方式不同；浏览器和终端都失败，则继续检查本地端口和内核日志。还要区分“所有域名都打不开”和“少数网站失败”：前者更像本地代理或节点链路中断，后者常与分流、DNS、目标站点的网络策略有关。记录准确现象比反复点击连接按钮更有价值。
确认内核进程和本地监听端口
v2rayN、v2rayNG 与 v2flyNG 都需要启动对应内核并建立本地入口。桌面端可在客户端状态区查看当前配置是否运行，再到设置中确认 HTTP、SOCKS 或混合代理端口。不要凭教程中的常见数字猜测，实际端口可能已经修改，也可能因另一个程序占用而自动启动失败。Windows 可用以下命令检查端口，其中的端口号应替换为客户端界面显示的真实值：
netstat -ano | findstr LISTENING
Get-NetTCPConnection -State Listen | Sort-Object LocalPort如果列表中没有对应端口，回到客户端日志查找“address already in use”“failed to listen”或配置加载失败一类信息。端口被占用时，可关闭占用程序，或在客户端设置中改为一个未使用的端口，再完全停止并重新启动内核。仅修改设置但不重启内核，旧进程可能继续占用原端口，系统代理却已指向新端口，从而形成表面连接、实际无流量的错位状态。
核对系统代理指向和路由模式
系统代理开启后，应指向本机回环地址与当前监听端口。Windows 中常见目标是 127.0.0.1，不应误填局域网网卡地址；如果客户端提供“自动配置脚本”“全局代理”和“清除系统代理”等选项，应明确当前使用哪一种。自动配置脚本依赖规则判断目标地址，全局代理则把支持系统代理的请求统一送到本地入口，两者的故障表现不同。排查时可暂时切换到规则较少的模式验证基础链路，确认可用后再恢复原有分流。
自定义路由规则也可能把目标流量送往错误出站。特别要检查规则顺序，因为内核通常按先匹配先生效处理；一条范围过大的直连规则放在前面，会遮住后面的代理规则。反过来，局域网地址被送往远端也可能导致打印机、路由器管理页或内部服务无法访问。建议临时停用新增规则，只保留客户端默认规则进行对比，不要直接删除原配置。测试成功后逐条恢复，才能找到真正产生影响的规则。
用本地代理请求确认数据是否进入内核
在桌面端，可以绕过系统代理，直接指定客户端的本地端口发起请求。这样能把“系统代理没有生效”和“节点本身不可用”分开。以下示例假定 HTTP 代理端口为 10809；实际执行时必须使用客户端当前端口：
curl.exe -I --proxy http://127.0.0.1:10809 https://example.com/
curl.exe -v --proxy http://127.0.0.1:10809 https://example.com/如果直接指定代理可以得到 HTTP 响应，而浏览器仍失败，重点转到浏览器代理策略、扩展冲突或系统代理设置；如果命令立即提示无法连接到 127.0.0.1，说明本地端口没有监听或端口填写错误；如果已经连接本地端口但等待后超时，则请求进入了内核，下一步应检查节点握手、DNS 和路由日志。日志中最好同时观察入站、路由命中和出站错误三部分，而不是只看最后一行错误。
完成排查后，将系统代理恢复到一个明确状态。若暂时不再使用客户端，应先执行客户端的“清除系统代理”再退出；若仍需连接，则确认系统代理端口与当前内核一致。异常退出可能留下旧代理地址，造成下次开机后所有读取系统代理的应用无法联网。此时重新打开客户端并清除系统代理，通常比在多个系统面板中反复改值更直接。
02 / REMOTE HANDSHAKE
节点超时与握手失败：定位中断层级
区分 TCP 超时、TLS 错误与协议拒绝
“节点超时”不是单一原因。连接可能在建立 TCP 之前就中断，也可能已经连到服务器但 TLS 握手失败，或者 TLS 成功后被 VMess、VLESS、Trojan 等协议层拒绝。三类问题应依据日志区分。出现 i/o timeout、context deadline exceeded 或连接目标地址超时时，先查网络可达性；出现证书域名、握手或 serverName 相关错误时，检查系统时间与 TLS 参数；出现认证失败、无效用户或协议响应异常时，再核对端口、用户标识和传输配置。
不要仅依据客户端测速列表中的颜色判断节点状态。测速可能只测试 TCP 建连，也可能测试完整请求，不同客户端与测试方式不能直接横向比较。更可靠的方法是选择一个节点，固定当前网络和路由模式，发起一次真实请求，同时观察从解析目标地址、建立连接到握手完成的完整日志。重复测试时保持其他条件不变，才能判断错误是否稳定。
先检查目标主机与端口是否可达
Windows 可使用 PowerShell 的 Test-NetConnection 检查节点域名与端口。命令只验证基础网络连接，不证明上层协议配置正确，但能快速排除端口完全不可达的情况：
Resolve-DnsName node.example.com
Test-NetConnection node.example.com -Port 443
Test-NetConnection node.example.com -InformationLevel Detailed若域名无法解析，转到 DNS 章节；若解析到地址但 TCP 测试失败，可换一个网络再次测试，例如从家庭网络切到移动网络。仅某一网络失败，通常说明链路路径、路由器策略或网络出口存在差异；所有网络都失败，则需要确认节点地址、端口和服务端状态。测试时不能把网站的普通 HTTPS 端口结果当作节点端口结果，两者必须是同一个目标主机与同一个端口。
若节点使用域名，避免直接把解析出的 IP 填回配置作为长期方案。TLS 连接通常依赖域名完成证书校验与 SNI 匹配，直接改成 IP 可能让原本的 TCP 可达问题变成新的证书错误。临时用 IP 只适合判断 DNS 是否参与故障，测试完成后应恢复原始域名和对应的 serverName。
核对系统时间、SNI 与证书域名
TLS 校验依赖设备时间。系统日期、时区或自动校时异常时，证书可能被判断为尚未生效或已经过期。先在系统设置中启用自动时间与自动时区，再手动同步一次；虚拟机、双系统切换和长期休眠后的设备尤其需要检查。校时后应完全重启客户端内核，因为部分连接与会话状态可能仍保留旧时间条件。
serverName 或 SNI 必须与服务端证书覆盖的域名对应，而不一定与连接地址字段完全相同。订阅导入后如果手动编辑过节点，应对照原始节点参数检查地址、端口、传输方式、TLS 开关、SNI、路径和主机头是否仍成组匹配。只复制地址和端口、遗漏传输参数，是常见的握手失败来源。相关排查还可参阅TLS 握手失败与证书错误处理。
逐项比对协议与传输参数
协议层参数必须整体一致。VMess 需要正确的用户标识、加密与传输组合；VLESS 需要核对用户标识、流控及安全层设置；Trojan 需要核对认证内容与 TLS 入口；Shadowsocks 则要确认加密方法和认证内容成对匹配。WebSocket、gRPC、TCP 等传输方式还各自带有路径、服务名、Host 或安全层字段。任何一项被空格、换行或手工替换破坏，都可能表现为连接后立即关闭。
最有效的对比方式是重新从订阅导入到一个独立分组，不覆盖现有手工配置，然后测试新导入节点。如果新节点可用，说明旧节点在编辑或迁移过程中发生了参数偏差；如果新旧节点错误一致，应检查订阅源、网络环境或远端状态。不要在不清楚含义时启用跳过证书验证作为固定方案，它可能暂时掩盖时间、域名或证书部署问题，却不能修复协议参数不一致。
| 日志阶段 | 常见现象 | 优先检查 |
|---|---|---|
| 解析前 | 找不到主机、解析失败 | DNS、域名拼写、网络接入 |
| TCP 建连 | 超时、连接被拒绝 | 节点地址、端口、基础可达性 |
| TLS 握手 | 证书域名或时间错误 | 系统时间、SNI、TLS 开关 |
| 协议认证 | 连接后立即关闭 | 用户参数、流控、传输组合 |
如果同一节点偶发成功、偶发超时，还应检查本地网络丢包、无线信号切换和设备休眠恢复。连续执行少量测试并记录发生时间，不要用高频并发测试制造额外负担。稳定的错误按配置排查，随网络切换变化的错误按链路排查，这一分类能显著缩短定位时间。
03 / SUBSCRIPTION INPUT
订阅更新失败：从地址、响应到节点解析
确认订阅地址完整且没有混入多余字符
订阅失败首先要区分“没有取到响应”和“取到响应但解析失败”。从聊天工具、文档或二维码复制地址时，末尾可能混入句号、空格、换行或全角字符；某些地址还包含较长的查询参数，复制不完整会让服务器返回登录页、错误页或空内容。应在客户端订阅设置中重新粘贴完整地址，检查协议头、域名、路径与查询参数是否连续，并确认没有把节点分享链接误放进订阅地址栏。
v2rayN 通常以订阅分组管理多个来源，v2rayNG 与 v2flyNG 则在订阅设置中维护地址。修改订阅后，需要保存设置并主动执行更新；仅编辑名称不会触发拉取。为了避免旧缓存干扰，可以新建一个临时分组，使用同一地址更新并观察结果。新分组成功而旧分组失败时，重点检查旧分组的更新设置、过滤条件和缓存状态。
读取 HTTP 状态和响应类型
日志若出现 HTTP 状态码，应按响应含义处理。认证失败或禁止访问通常与地址中的授权参数、账户状态或来源限制有关；找不到资源通常说明路径不完整或地址已变更；服务器错误则应稍后重试并确认是否只有该订阅源异常。收到成功状态也不代表内容一定可解析，因为响应可能是网页、登录提示或网关说明，而不是订阅数据。
桌面端可在不展示地址内容的前提下，用命令确认请求过程。订阅地址通常包含敏感授权参数，不应把完整地址粘贴到公开日志或截图中。以下命令中的地址是示意值，实际测试时只在本机终端使用自己的订阅地址：
curl.exe -I "https://subscription.example/subscription"
curl.exe -L --connect-timeout 15 "https://subscription.example/subscription" -o subscription.txt-I 只读取响应头，适合检查重定向和状态；部分订阅服务不支持只取响应头，此时应使用第二条命令保存响应，再确认文件是否为空以及内容类型是否合理。不要把响应文件直接发布，因为其中可能包含节点地址和认证参数。若请求发生多次重定向，应确保客户端支持该流程，并确认最终地址仍属于预期订阅入口。
判断更新请求是否需要经过当前代理
订阅更新和节点连接是两条相关但不同的链路。有些客户端可选择“通过代理更新订阅”，此选项要求当前已经存在一个可工作的节点；如果唯一节点已失效，更新请求又被强制送入该节点，就会形成无法更新的闭环。排查时可先关闭代理更新，通过原始网络请求订阅；若原始网络不可达而已有节点可用，再反向测试通过代理更新。
系统代理残留也会影响订阅请求。客户端已退出但系统仍指向旧的本地端口时，重新启动客户端之前的网络请求可能全部失败。先确认本地端口正在监听，或清除系统代理后再更新。企业网络和需要网页登录的公共网络还可能在首次访问时返回认证页面，应先用浏览器完成当前网络的正常接入，再进行订阅请求。
处理格式、编码与节点过滤问题
订阅响应可能包含编码后的节点集合，也可能包含逐行分享链接。客户端必须识别响应格式，才能生成节点列表。出现“解析成功但节点数为零”时，不要立刻认定订阅为空，应检查是否启用了关键字过滤、去重、只保留指定协议或删除无效节点等规则。过于严格的过滤表达式可能把所有条目排除，尤其是分组名称或节点备注发生变化后。
如果日志明确提示某一行格式错误，可先确认整体更新是否仍导入了其他有效节点。有些客户端会跳过单条异常记录，有些会终止整个处理过程。重新获取一次响应可排除传输中断；持续在同一位置失败，则需要订阅来源修正对应条目。不要手工解码后长期维护订阅副本，因为节点参数更新时副本不会同步，后续会出现地址、证书域名与传输参数逐渐不一致的问题。
建立可重复的订阅检查流程
完整流程应当是：检查系统时间与基础网络，核对订阅地址，确认更新是否经过代理，查看 HTTP 响应，再检查解析日志和过滤条件，最后选择新导入节点做真实连接测试。更新后仅看到节点名称并不足以证明可用，应检查节点参数是否完整并完成一次访问验证。详细的入口操作可参阅v2rayN 与 v2rayNG 订阅导入说明。
频繁自动更新失败时，还要检查设备休眠、后台限制和网络切换。桌面设备在休眠期间不会按计划执行更新，恢复后客户端可能需要重新建立网络；Android 设备若后台活动受限，定时任务也可能被延后。将自动更新视为维护功能，而不是连接成功的唯一前提：始终保留最近一次可工作的配置，并在更新后观察日志和节点变化。
04 / THROUGHPUT
连接速度慢：分离节点、线路与本机开销
先定义慢在建立连接还是持续传输
打开网页等待很久但下载开始后速度正常，通常是 DNS、首次握手或连接复用问题；网页很快出现但大文件持续传输缓慢，更可能与线路带宽、丢包、服务器负载或设备性能有关；只有视频、即时通信或某一应用缓慢，则应检查该应用走的是 TCP 还是 UDP，以及路由规则是否把相关域名分散到不同出站。把所有情况统称为“节点慢”会遗漏关键差异。
测试前先固定环境：选择同一个节点、同一个网络、同一个目标资源和相近时间段，关闭占用带宽的同步与下载任务。不要同时开启多个测速工具，因为并发请求会争用带宽并改变节点负载。先测原始网络，再启用客户端测试，两组结果用于判断瓶颈是否已经存在于本地接入。如果原始网络本身波动明显，应先改善无线信号、网线连接或路由器状态。
使用可重复请求观察阶段耗时
curl 可以分别输出解析、连接、TLS 和总耗时，用于判断慢点出现在哪一阶段。以下示例通过本地 HTTP 代理访问保留示例域名，端口应改为客户端真实值：
curl.exe -o NUL -s -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} start=%{time_starttransfer} total=%{time_total}\n" --proxy http://127.0.0.1:10809 https://example.com/解析耗时高时转查 DNS；连接耗时高时关注远端地址可达性和线路距离；TLS 耗时异常可能与丢包、证书链处理或网络重传有关；首字节慢而连接阶段正常，可能是目标站点响应或远端出口负载。单次结果不能代表长期表现，应间隔执行几次并观察是否稳定，不需要追求大量样本。排障的目标是找到耗时集中在哪一段，而不是生成排名。
比较节点时只改变节点本身
同一订阅中的节点可能使用不同地区、协议、传输方式和出口线路。比较时保持客户端模式、DNS 和目标地址不变，逐个切换节点完成相同请求。若所有节点都慢，优先检查本机网络、客户端模式、DNS 与设备资源；只有某个节点慢，则问题更集中于该节点路径或远端负载；同一节点在不同网络差异明显，则需要考虑两条接入网络到节点之间的路由质量。
客户端的延迟测试只反映测试方式覆盖的阶段，低延迟不保证大流量传输速度，高延迟也不一定导致持续吞吐很低。TCP 在存在丢包时会降低发送窗口，表现为速度周期性下降；无线干扰、移动网络切换和跨区域链路都可能触发这一现象。实际使用应同时看连接稳定性、网页首字节和持续传输，不要只依据单一延迟值选节点。
检查路由规则是否让同一业务走了不同路径
现代网页会同时请求主域名、静态资源域名、接口域名和内容分发地址。如果规则只匹配主域名，附属资源可能走直连或另一个出站，页面就会出现主体很快、图片或脚本长时间等待的情况。打开内核访问日志，观察同一次页面加载中各域名命中的出站规则。发现分散后，应根据业务域名组调整规则，而不是简单把单个域名不断追加到列表末尾。
规则顺序同样影响性能。过多正则表达式、范围宽泛的域名匹配和重复规则会增加判断复杂度，也使维护困难。应优先使用清晰的域名、后缀、IP 范围和内置数据集规则，把高确定性的规则放在前面，默认规则放在末尾。调整后清理 DNS 缓存并重新启动内核，以免旧解析和旧连接继续沿用原路径。
评估传输、复用和设备资源
连接复用可以减少频繁建立连接的开销，但并非所有网络和服务端组合都适合。出现少量连接正常、并发后明显卡顿时，可对比开启与关闭复用的结果。不要盲目提高并发数；设备性能有限时，更多并发会增加加密、上下文切换和内存压力。Android 设备在省电或温度较高时还可能降低后台处理能力，桌面端则应观察 CPU、内存和磁盘是否被其他任务长期占用。
不同传输方式带有不同封装开销，但配置正确和链路稳定通常比理论开销更重要。不要为了追求速度单独修改传输字段，因为客户端与服务端参数必须一致。若要比较协议组合，应使用订阅中已经提供且确认可用的完整节点，而不是从一个节点复制地址后自行拼接另一套传输参数。关于协议特性与选择边界，可阅读VMess、VLESS、Trojan 与 Shadowsocks 对比。
05 / NAME RESOLUTION
DNS 解析异常：核对域名从哪里解析
识别典型 DNS 症状
DNS 问题常表现为输入域名失败、直接访问 IP 有响应、首次打开网站等待很久、同一域名在不同应用得到不同结果，或切换客户端模式后部分站点突然不可用。节点域名解析失败会阻止内核连接远端；目标网站域名解析失败则可能只影响特定访问。排查时必须先确定失败的是“节点地址”还是“访问目标”，两者使用的解析路径可能不同。
浏览器可能启用自己的安全 DNS，系统使用另一组服务器，内核又根据配置处理代理请求中的域名，因此同一设备上可能同时存在多条 DNS 路径。浏览器成功不能证明系统解析正常，系统命令成功也不能证明内核使用了相同结果。应结合浏览器设置、系统网络配置和内核日志判断实际解析者。
从系统解析结果开始检查
Windows 可使用 Resolve-DnsName 或 nslookup，macOS 与 Linux 可使用 dig 或 nslookup。先测试节点域名，再测试出现异常的目标域名，并记录返回类型和地址：
Resolve-DnsName node.example.com
nslookup node.example.com
nslookup example.com
# macOS 或 Linux
dig node.example.com
dig example.com A
dig example.com AAAA命令返回超时表示当前 DNS 服务器没有及时响应；返回不存在则要确认域名拼写和记录状态；得到地址后仍无法连接，问题已经从解析推进到路由、端口或握手阶段。若同时返回 IPv4 与 IPv6 地址，而当前网络的 IPv6 连通性不完整，应用可能先尝试不可达地址并等待回退。可临时比较 A 与 AAAA 记录的连接结果，但不要长期通过删除系统协议支持来掩盖网络配置问题。
清理缓存并避免旧结果干扰
系统、浏览器和客户端内核都可能缓存解析结果。修改 DNS 设置后，旧连接与旧缓存不会立即消失，因此应依次关闭相关浏览器标签页、停止内核、清理系统缓存，再重新启动客户端。Windows 可执行：
ipconfig /flushdns
Clear-DnsClientCache
Get-DnsClientServerAddress清理缓存只能让下一次请求重新解析，不能修复错误的服务器地址、路由规则或域名配置。如果每次清理后短暂正常、随后再次异常，应检查是哪个组件重新写入了错误结果，例如系统网络切换、路由器下发 DNS、浏览器独立解析或客户端规则把请求送往不可达服务器。
理解本地解析、远端解析与域名规则
当应用把域名交给 SOCKS 或 HTTP 代理时，域名可能由本地先解析为 IP，也可能保持域名形式进入内核，再由内核选择解析服务器。两种方式会影响路由匹配：如果过早转换为 IP，基于域名的规则可能无法获得原始域名；如果始终保留域名，则内核需要一条可靠的 DNS 出站路径。配置时应明确希望在哪一层解析，而不是同时叠加多个互相覆盖的选项。
内核 DNS 配置通常包含服务器列表、匹配域名和查询策略。规则应与出站路径配套：用于解析节点域名的服务器必须在节点尚未建立前就能访问；依赖代理出站的 DNS 不能反过来承担建立该代理所需的首次解析，否则会形成循环依赖。最稳妥的基础结构是保留一条能在原始网络上解析节点地址的路径，再根据目标域名和路由需求安排其他查询。
检查 hosts、过滤规则和浏览器独立设置
系统 hosts 文件中的静态记录优先级通常高于普通 DNS 查询。旧测试记录、错误地址或重复条目会让某个域名长期指向过期目标。检查时只修改自己明确添加的记录，并在修改前保留副本。安全软件、路由器过滤、家长控制和企业网络策略也可能返回特定地址或阻止查询，需要通过切换到另一网络进行对比。
浏览器的独立 DNS 设置可能绕过系统路径。如果只有一个浏览器异常，先使用干净配置或其他浏览器测试，再检查该浏览器是否启用了独立解析、代理扩展或缓存策略。如果所有应用都异常，则优先检查系统和内核。不要让浏览器扩展、系统代理工具和 V2Ray 客户端同时修改同一层设置，否则成功请求也难以确认实际经过哪条路径。
| 现象 | 可能位置 | 验证方法 |
|---|---|---|
| 节点域名无法解析 | 系统 DNS、基础网络 | 停止客户端后查询节点域名 |
| 只有浏览器正常 | 浏览器独立 DNS 或系统代理差异 | 对比命令行与浏览器设置 |
| 域名失败、IP 可连接 | 目标域名解析路径 | 查询 A 与 AAAA 记录并查看内核日志 |
| 切换网络后恢复 | 当前网络下发的 DNS 或路由 | 记录两种网络的服务器与解析结果 |
完成修复后，应分别验证节点域名解析、目标域名解析和真实访问，不能只看查询命令返回。DNS 返回地址只证明解析阶段完成，后续仍需经过路由、连接和协议握手。将三段结果分开记录，后续网络切换或规则调整时更容易发现是哪一层重新发生变化。
06 / APPLICATION ROUTING
系统代理不生效：浏览器与终端分别核对
先理解系统代理的作用边界
系统代理是一组供应用读取的连接设置，不会自动接管所有网络流量。浏览器和部分桌面软件通常会读取系统代理，命令行工具、游戏、后台服务和自行实现网络栈的应用可能忽略它。于是会出现浏览器经过客户端、终端仍然直连的情况，这并不必然表示内核故障。排查应先确认目标应用支持哪种代理方式，再选择系统代理、环境变量、应用内代理或 TUN 模式。
详细的场景对照可参阅浏览器与终端系统代理排查。本章重点是建立统一判断方法：先验证本地端口，再确认系统代理值，然后检查应用是否读取该值。不要仅通过任务栏图标或客户端菜单状态推断流量已经进入内核。
核对代理地址、类型和端口
HTTP 代理、SOCKS 代理和混合代理不是同一个概念。应用填写代理时，类型必须与客户端监听入口匹配。把 SOCKS 端口填进只支持 HTTP 的系统代理栏，可能直接连接失败；把 HTTP 端口作为 SOCKS 使用也会出现握手错误。优先从客户端设置复制地址与端口，并确认内核重启后仍在监听。
Windows 可查看当前用户的代理配置，并通过直接指定代理进行对比：
netsh winhttp show proxy
Get-ItemProperty "HKCU:\Software\Microsoft\Windows\CurrentVersion\Internet Settings"
curl.exe -I --proxy http://127.0.0.1:10809 https://example.com/WinHTTP 与普通桌面应用使用的代理来源可能不同，netsh winhttp show proxy 的结果不代表浏览器一定使用同一配置。需要根据具体程序判断。如果直接指定代理成功，而应用仍直连，说明节点与本地端口基本可用，后续应集中检查应用设置；如果直接指定代理也失败，则回到本地监听或节点章节处理。
终端工具使用环境变量时要同时处理大小写
许多命令行程序读取 HTTP_PROXY、HTTPS_PROXY 和 ALL_PROXY，但不同工具对变量大小写和协议支持存在差异。临时设置适合单次测试，关闭当前终端后自动失效。PowerShell 示例：
$env:HTTP_PROXY="http://127.0.0.1:10809"
$env:HTTPS_PROXY="http://127.0.0.1:10809"
curl.exe -I https://example.com/
Remove-Item Env:HTTP_PROXY
Remove-Item Env:HTTPS_PROXYmacOS 或 Linux 的 shell 可使用：
export HTTP_PROXY="http://127.0.0.1:10809"
export HTTPS_PROXY="http://127.0.0.1:10809"
export http_proxy="$HTTP_PROXY"
export https_proxy="$HTTPS_PROXY"
curl -I https://example.com/
unset HTTP_PROXY HTTPS_PROXY http_proxy https_proxy若使用 SOCKS 入口，应确认工具支持对应写法以及域名是在本地还是由代理侧解析。环境变量不应长期残留在无法保证客户端常驻的启动文件中，否则客户端未运行时终端网络会全部指向空端口。需要永久设置时，应同时记录清理方法，并确保端口不会随配置切换发生变化。
检查自动配置脚本与绕过列表
自动代理配置会根据 URL 或主机名决定直连还是使用代理。脚本地址无法加载、缓存未刷新或规则遗漏时，部分网站可能绕过客户端。排查时可暂时切换到明确的手动代理配置，确认本地端口和节点可用，再恢复自动脚本。恢复后应重新启动浏览器，使其重新读取系统设置和脚本内容。
绕过列表通常包含本地地址、局域网主机或指定域名。范围写得过宽会让大量目标直连，例如错误的通配规则可能匹配所有子域名。反之，没有绕过局域网地址可能导致内部设备访问失败。检查时优先保留回环地址和明确的内网范围，再逐条恢复自定义条目。系统设置、客户端规则和浏览器扩展都可能拥有各自的绕过列表，应避免三处重复维护。
TUN 模式的检查重点不同
TUN 模式通过虚拟网络接口处理更多不读取系统代理的流量，但会引入路由表、DNS 接管、系统权限和其他网络软件冲突等新变量。开启后若完全断网，先查看虚拟接口是否创建成功、默认路由是否写入、DNS 是否指向有效入口，以及客户端是否获得所需系统权限。退出客户端后还应确认路由和 DNS 已恢复。
不要把 TUN 模式作为系统代理失败时的第一步。先证明节点和普通本地代理端口可用，再启用 TUN，才能把新问题限定在虚拟接口层。若设备同时运行虚拟机网络、容器网络、企业接入软件或其他接管路由的程序，应逐个停用进行对比。冲突通常来自路由优先级和 DNS 接管顺序，而不是节点协议本身。
最终验证应覆盖三类请求：浏览器读取系统代理、命令行显式指定代理、不支持系统代理的应用通过其自身设置或 TUN 访问。三类路径分别成功，才能说明配置边界清晰。某一类失败时只处理对应入口，不必重置已经工作的其他部分。
07 / CLIENT RUNTIME
客户端崩溃或内核退出：保留证据后分层恢复
区分界面退出、内核退出与配置加载失败
客户端窗口消失、界面仍在但连接停止、点击启动后立即回到未运行状态，分别对应不同层级。界面进程崩溃时，系统托盘图标也可能消失；内核退出时，界面通常还在并能看到错误日志；配置加载失败则常发生在切换节点或修改设置后，内核尚未开始监听端口就结束。先记录是哪一层退出，再决定查看应用日志、内核日志还是系统事件。
发生异常后不要立即反复重装。先保存错误时间、操作步骤和日志末尾内容，并记录崩溃前是否刚导入订阅、编辑路由、切换内核设置、恢复休眠或更新系统。能够稳定复现的步骤比模糊的“偶尔闪退”更容易定位。公开求助时应删除节点地址、订阅参数、用户标识和其他连接凭据，仅保留错误类型与调用阶段。
从最后一次配置变更开始回退
如果问题在导入新节点后出现，切换回已验证节点；在修改路由后出现，则暂时停用新增规则；在调整端口后出现，检查新端口是否被占用；在启用 TUN 后出现，先恢复普通系统代理模式。一次只回退一类设置，并在每次回退后重新启动客户端。直接删除全部配置虽然可能暂时恢复，却会丢失定位依据，也可能让同一错误在重新导入后再次发生。
配置文件为 JSON 时，常见错误包括尾随逗号、引号缺失、字段层级错误以及把数字写成无法识别的文本。下面是结构完整的最小路由片段示例，用于说明数组、对象和逗号位置；实际配置还需与客户端生成的完整结构合并：
{
"routing": {
"domainStrategy": "AsIs",
"rules": [
{
"type": "field",
"ip": [
"geoip:private"
],
"outboundTag": "direct"
},
{
"type": "field",
"domain": [
"geosite:private"
],
"outboundTag": "direct"
}
]
}
}不熟悉完整配置结构时，优先通过客户端界面编辑，不要把片段直接覆盖整个配置文件。客户端生成的字段还会引用入站与出站标签，标签名称不一致也会导致启动失败。日志若指出具体字段或行号，应围绕该位置检查上一级对象，而不是只修改报错字符。
检查端口、权限与运行目录
内核启动即退出的常见原因之一是监听端口被占用。使用端口检查命令找到进程编号后，再确认该进程属于旧内核、其他代理工具还是正常系统服务。不要直接结束不明系统进程；更安全的做法是关闭相关应用或为客户端选择未使用端口。若旧内核进程残留，可先从客户端执行停止，等待进程退出后再启动。
TUN、路由写入和某些系统级功能需要相应权限。普通代理模式可用而 TUN 启动失败时，应检查权限提示、虚拟接口创建和系统安全策略。安装目录没有写入权限时，客户端也可能无法保存配置、日志或解压运行组件。将程序放在当前用户可读写的常规目录，避免直接从压缩包内部运行，也不要在多个目录同时启动同一份配置。
隔离订阅数据、客户端界面和内核
v2rayN 是 Windows、macOS 与 Linux 的桌面客户端，v2rayNG 使用 Xray 内核，v2flyNG 使用 v2fly 内核。它们的界面、配置管理和内核实现并非同一层。节点导入成功但内核无法加载，可能是节点参数与当前内核能力不匹配；内核可独立运行但界面崩溃，则重点检查客户端状态文件、界面运行环境和系统日志。
隔离测试时可建立新的空白配置目录或使用客户端提供的备份与恢复功能，不应覆盖唯一数据。先启动不含订阅和自定义路由的基础环境，再逐步导入一个已知配置。如果空白环境稳定、导入后崩溃，问题集中于配置或数据；空白环境也崩溃，则更应检查安装文件、运行环境、权限和系统兼容性。需要重新获取客户端时，从下载页选择与平台和架构对应的安装包。
处理日志增长、休眠恢复与安全软件拦截
长期启用详细日志会增加磁盘写入和文件体积。磁盘空间不足时，配置保存、更新和日志写入都可能失败。排查结束后应把日志级别恢复到日常设置，并按客户端提供的方式清理旧日志。不要在内核运行时手工锁定或移动正在写入的日志文件，以免引发新的异常。
设备从休眠恢复后，网卡地址、DNS 和默认路由可能变化，而内核仍持有恢复前的连接。此时先停止连接，等待系统网络稳定，再重新启动内核，通常比直接重启整台设备更快。若每次休眠后都复现，应记录恢复时的网卡、路由和日志变化，确认是网络重建还是客户端进程异常。
安全软件可能阻止新下载的可执行文件监听端口、创建虚拟接口或访问网络。应查看系统安全记录是否明确拦截对应客户端和内核进程，并依据实际路径处理。不要关闭全部系统防护作为长期方案；通过事件记录确认具体拦截对象，才能在保持其他规则不变的情况下恢复运行。
恢复完成后应做一次完整回归：客户端启动、端口监听、节点连接、系统代理切换、订阅更新和退出清理依次验证。只确认窗口能够打开并不足以说明故障已经消失。若问题仍可稳定复现，将最小复现步骤与处理过的日志一起记录，再查阅常见问题中的对应条目。
08 / ANDROID RUNTIME
Android 专项：授权、后台断连与分应用代理
首次连接先确认系统授权
v2rayNG 和 v2flyNG 在 Android 上通常通过系统 VpnService 建立本地虚拟网络。首次连接时系统会显示授权提示，只有用户确认后客户端才能接管相应流量。点击连接后没有状态图标、日志立即返回未授权或界面仍停留在未连接状态时，应检查授权是否被取消，以及系统中是否已有另一个使用同类接口的网络应用正在运行。
系统通常只允许一个此类连接同时处于活动状态。切换客户端前应先停止原来的连接，等待状态图标消失，再启动 v2rayNG 或 v2flyNG。强制结束前一个应用但没有正常断开时，系统可能短暂保留旧接口；此时进入系统网络设置断开旧连接，或重启网络后再试。不要同时让多个应用轮流自动重连，否则会出现连接刚建立就被另一应用替换的现象。
后台断连优先检查电池与进程限制
锁屏后数分钟断开、切到其他应用后停止传输、系统清理后台后无法自动恢复，通常与电池优化、后台活动限制或设备厂商的进程管理有关。应把正在使用的客户端加入系统允许后台运行的列表，允许必要的后台网络活动，并避免在任务清理界面中手动结束进程。不同 Android 系统的设置名称可能不同，但判断标准相同：客户端进程和 VpnService 在锁屏后仍应保持运行。
仅关闭一处电池优化不一定足够。有些设备同时提供应用电量策略、自启动管理、后台数据、休眠应用和锁屏清理。应逐项确认，并在修改后锁屏等待一段时间做真实请求，而不是只看状态栏图标。状态图标仍在但请求失败时，还需检查网络是否从无线切换到移动数据，以及内核是否成功重建连接。
Android 的省电模式可能延迟后台任务和网络访问。订阅自动更新、连接保活和网络恢复都可能受影响。排查时先关闭系统省电模式进行对比；若问题消失，再针对客户端调整单应用策略，不必长期改变整个设备的电量设置。更完整的操作说明见v2rayNG 授权、省电与分应用代理。
处理无线网络与移动网络切换
从无线网络切换到移动网络时，本地 IP、默认路由和 DNS 都会变化，已有 TCP 连接通常不能继续复用。客户端应检测网络变化并重新连接，但系统限制、弱信号或内核状态可能让恢复延迟。遇到切换后无法访问时，先等待系统网络本身可用，再在客户端中停止并重新连接，不要连续快速点击开关。
如果无线网络可用、移动网络失败，使用相同节点检查目标端口可达性和 IPv4、IPv6 差异；反向情况则检查路由器 DNS、局域网过滤和无线网络登录状态。公共无线网络常要求先完成网页登录，在虚拟网络建立前应先关闭客户端完成接入认证，再重新连接。只有某一种网络失败时，不要重置订阅或节点参数，因为相同配置在另一网络已经证明可以工作。
分应用代理要明确“包含”与“排除”
分应用代理通常提供仅代理所选应用或绕过所选应用两种逻辑。两者名称相近但结果相反。启用前先确认当前模式，再检查目标应用是否在列表中。若选择“仅代理”，未选中的浏览器和测试工具不会经过客户端；若选择“绕过”，列表中的应用会直接使用原始网络。排障时可暂时关闭分应用规则，确认全局连接可用后，再逐个加入或排除应用。
应用更新或重装后，其系统标识可能变化，旧规则不一定继续匹配。出现某个应用此前可用、更新后突然直连或断网时，应重新打开分应用列表并保存。系统组件、内嵌网页和应用调用的外部浏览器可能属于不同进程，只选择主应用不一定覆盖完整登录流程。观察内核访问日志能确认请求是否真正进入客户端。
Android DNS 与私有 DNS 的叠加关系
系统私有 DNS、客户端内核 DNS 和应用自身解析可能同时存在。连接后只有域名失败、直接 IP 请求有响应时，先检查系统私有 DNS 当前是自动、关闭还是指定主机，再查看客户端日志中的 DNS 错误。指定的私有 DNS 主机若在当前网络不可达，会让建立虚拟网络前后的解析都受影响。可暂时切换到系统自动模式进行对比，确认后再决定长期配置。
启用本地 DNS 接管时，应确保查询能通过当前出站完成，同时节点域名仍有可用的初始解析路径。与桌面端相同，不能让解析节点所需的 DNS 完全依赖尚未建立的节点。网络切换后若解析持续使用旧结果，可以停止连接、开启再关闭飞行模式以重建网络，然后重新连接客户端。此操作会中断当前所有网络任务，应在保存工作后执行。
应用能连接但无法访问时的最短流程
先关闭分应用代理，选择一个已验证节点，确认系统授权存在；然后查看连接日志是否完成节点握手，再用浏览器测试域名访问。如果握手失败，按节点超时章节处理；握手成功但没有任何访问日志，说明应用流量没有进入虚拟网络，应检查授权和分应用设置；有访问日志但 DNS 报错，则处理系统私有 DNS与内核 DNS；请求进入出站后超时，则比较无线与移动网络。
若只有特定应用失败，检查该应用是否启用了独立代理、私有 DNS、后台数据限制或仅限无线网络下载。清除整个客户端数据会删除订阅和路由设置，不应作为第一步。更稳妥的方式是导出或记录现有设置，新建一个最小配置进行对比，再决定是否重置。v2rayNG 首推用于 Xray 内核配置，v2flyNG 可作为 v2fly 内核备选；切换客户端测试时应使用参数完整的同一节点，并注意两者支持的内核能力可能不同。
| Android 现象 | 优先检查 | 处理动作 |
|---|---|---|
| 点击连接后立即停止 | 系统授权、配置加载日志 | 重新授权并核对节点参数 |
| 锁屏后断开 | 电池优化、后台活动 | 允许客户端持续后台运行 |
| 切换网络后失效 | 路由重建、DNS、节点可达性 | 确认基础网络后重新连接 |
| 只有部分应用失败 | 分应用模式、应用独立设置 | 关闭筛选验证，再逐项恢复 |
移动端问题往往由系统生命周期与网络切换共同触发。稳定配置的标准不只是点亮连接状态，还包括锁屏后保持、无线与移动网络切换后恢复、目标应用确实命中分流规则。每完成一项调整都应执行对应场景测试，避免在前台短暂成功后就结束排查。