VPNRH 故障排查手册

先建立可复现的排查基线

多数网络故障并不是单一原因造成的。客户端、当前接入网络、系统代理、DNS、线路类型、目标网站和账户状态都可能影响结果。如果一上来同时更换客户端、线路和网络，即使恢复连接，也无法知道究竟是哪项改动生效；下次出现相同现象时仍要从头尝试。更可靠的方法是先记录现状，确定故障影响范围，然后每次只替换一个变量。

第一步是把主观描述改成可验证的现象。“不好用”无法指导排查，应改写为“客户端显示连接失败”“客户端显示已连接，但浏览器打不开任何网页”“只有某个应用无法访问”“网页可以打开，但视频持续缓冲”“切到后台后连接中断”等。现象越具体，判断路径越短。还要记录问题是持续存在，还是仅在某类网络、某个时段或某条线路出现。

第二步是划定范围。先在同一设备上访问一个常用国内站点与一个需要跨境线路的站点，再换另一个浏览器或应用复查。如果所有网络访问都失败，应优先检查本地接入网络与系统网络配置；如果国内访问正常而跨境访问失败，应检查客户端连接、线路和代理模式；如果浏览器正常而单个应用异常，重点转向应用分流、系统代理读取方式和应用自身的网络缓存。

第三步是保存基线信息。需要记录使用的平台、客户端界面显示的连接状态、当前线路名称与线路类型、故障发生的大致时段、当前使用的接入网络，以及报错文字。不要只截取一个红色图标，应让截图包含线路名、连接状态和完整错误提示。涉及账户页面时应遮盖订阅链接、访问令牌、用户名和付款信息，工单不需要这些敏感内容的完整值。

使用最小变量法复测

最小变量法的顺序应从外部环境向客户端内部推进。先保持线路和客户端不变，仅切换接入网络；再保持网络不变，仅切换同地区的另一条线路；随后才考虑更换协议或重建客户端配置。这样可以迅速区分“当前网络不允许建立连接”“单条线路异常”和“客户端本地状态损坏”。如果每次修改后立刻连续点击连接，旧会话可能尚未释放，观察到的错误会互相干扰。应先主动断开，等待客户端状态回到未连接，再发起下一次测试。

复测时不要用大型下载、测速站或直播作为唯一判断工具。这类业务同时受目标站限速、内容分发网络、磁盘写入和应用缓冲策略影响，不能直接说明线路是否可用。更适合的基线是：客户端能否完成连接、普通网页能否打开、多个不同站点是否表现一致。确认基础访问恢复后，再测试视频、AI 工具或长连接场景。

先查账户与流量状态，再查网络

网络排查之前，应登录面板确认订阅处于可用状态，并核对月订阅流量是否已经用完。月订阅有 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按开通日每月重置，中途升级差价折算成剩余天数。流量包为 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止，永久不过期。若账户状态或剩余流量不满足连接条件，更换 DNS 和线路不会解决问题。

不要凭自然月日期判断流量是否应当恢复，因为月订阅按开通日重置。也不要把流量包与月订阅的重置规则混为一谈。若面板显示与预期不一致，先保存套餐名称、页面状态和出现时间，再提交工单核对，避免通过反复退出、删除配置等操作掩盖原始状态。

常用的无敏感信息检查命令

桌面系统可以使用系统自带工具观察域名解析与基础访问。以下示例只访问公开测试域名，不包含真实订阅地址或凭据。命令成功不代表所有应用都正常，但可以帮助区分 DNS 解析失败、连接建立失败和浏览器自身异常。

nslookup example.com
curl -I https://example.com

nslookup若无法返回解析结果，应优先阅读本页的 DNS 章节；能够解析但 curl 无法建立访问，则继续检查系统代理、客户端路由与当前线路。部分环境未预装 curl，此时可直接使用浏览器访问测试域名，不需要为了排障额外安装来源不明的工具。

客户端完全连不上

“完全连不上”是指客户端从未进入已连接状态，或连接后立即回到断开状态。此时不要先处理浏览器、流媒体和应用分流，因为流量通道尚未建立。应先判断失败发生在配置读取、域名解析、服务器握手、系统权限还是当前网络接入层。完整错误文字通常比状态颜色更有价值，例如超时、解析失败、认证失败、配置无效和权限不足分别指向不同分支。

先区分单条线路与全部线路

在不删除现有配置的前提下，选择同一地区的另一条线路测试。如果只有一条线路失败而其他线路可以连接，故障范围已经收窄到单条线路或其当前入口，不需要重装客户端。此时可暂时使用可连接线路，并把失败线路名称、线路类型和发生时段写入工单。如果多条不同地区、不同线路类型都失败，再继续检查本地网络、系统权限与订阅状态。

VPNRH 提供 120+ 国家 / 170+ 线路，线路页会说明 IEPL 专线、中转与直连的用途差异。排查时不要只在同一种线路类型内来回切换。若当前接入网络对某类连接方式兼容性较差，切到另一线路类型更有诊断价值。可先查看服务器与线路说明，理解线路标签后再做对照测试。

替换接入网络以确认限制位置

保持客户端、订阅和线路不变，仅切换到另一种可用网络。如果更换网络后立即恢复，说明客户端配置和账户大概率正常，问题集中在原接入网络的 DNS、出口策略、认证页面或链路质量。公共网络经常要求先在浏览器完成入口确认；在确认页面尚未完成时，普通网页可能被重定向，客户端连接也可能直接超时。应先断开代理，在浏览器中确认本地网络可以正常访问，再重新连接。

如果多个接入网络下都无法连接，应检查系统日期是否准确、客户端是否获得建立网络连接所需的系统权限，以及安全策略是否阻止客户端运行。系统日期偏差会让加密握手中的证书检查失败，表现可能只是连接超时或握手错误。修正日期后应彻底退出客户端并重新打开，让旧连接状态被清除。

检查系统权限与残留会话

Windows 与 macOS 上，客户端需要创建系统代理或虚拟网络接口；iOS 与 Android 会在首次建立连接时请求网络配置权限。若曾拒绝权限，客户端可能仍能导入订阅和显示线路，却无法真正建立通道。应进入系统网络设置确认对应配置存在且允许启用，而不是反复点击客户端里的连接按钮。权限恢复后，先关闭其他同类网络工具，避免多个工具同时争用系统代理或虚拟接口。

旧会话残留也会造成“点击无反应”或连接立即断开。规范做法是先在客户端内断开，再完全退出客户端，然后到系统网络设置确认旧代理和旧连接状态已经释放。重新打开后只保留一个需要测试的配置。直接强制结束进程有时会留下系统代理地址，使浏览器表现为完全无法访问；这并不意味着新线路也故障，而是系统仍把流量发往已经退出的本地端口。

认证失败与配置错误如何处理

认证失败通常不是通过频繁切线解决。先在面板确认订阅状态，再在客户端执行订阅更新。如果错误出现在手工编辑配置后，应撤销自定义改动，恢复由订阅生成的原始配置。协议名称、服务器地址、端口、认证字段和传输参数彼此关联，任意字段被输入法替换、被换行截断或带入多余空格，都可能让配置看似完整却无法握手。

若订阅来源曾被粘贴到公开页面、聊天截图或不受信任的工具中，应在面板内重置订阅后重新导入。不要把真实订阅地址直接发进工单正文。客服需要的是订阅更新时的状态、客户端报错与线路名，而不是可直接使用的完整链接。教学或复现时只能使用类似 https://example.com/sub?token=YOUR_TOKEN 的明显假值。

何时停止本地尝试

在不同接入网络上均失败、账户与流量状态正常、订阅已更新、不同线路类型都无法建立连接，并且系统权限已经确认后，就应提交工单。继续删除系统网络组件或安装多个客户端会增加变量。工单中附上平台、客户端名称、完整错误文字、失败线路、接入网络类型、已经完成的排查步骤和大致发生时段。若某条线路单独失败，也应说明其他哪类线路可以正常连接，这个对照结果比“全部试过”更容易定位。

已连接但网页打不开，或出现 DNS 异常

客户端显示已连接，只能说明连接动作已经完成，不代表域名解析、系统代理和应用流量都进入了通道。网页打不开时，应先用“域名访问”和“直接连接状态”两个角度拆分。常见原因包括系统代理未生效、DNS 请求仍走原网络、浏览器启用了独立代理设置、旧缓存保留错误解析结果，以及客户端规则把目标域名分到了不合适的出口。

判断是全部网页还是特定域名

先访问多个互不相关的网站。如果所有网站都无法打开，同时断开客户端后仍无法访问，应优先检查本地网络或残留系统代理，而不是线路。如果断开后国内网页恢复、连接后全部网页失败，重点检查客户端的代理模式、虚拟接口与 DNS 配置。如果只有特定站点失败，说明基础通道仍在工作，应检查该站点的地区策略、浏览器缓存、线路出口和分流规则。

不要用一个长期打开的标签页反复刷新作为唯一结果。浏览器可能复用旧连接、缓存失败页面或保留旧 DNS。应新开隐私窗口，或完全关闭浏览器后重新测试。若隐私窗口正常而普通窗口异常，问题通常在浏览器扩展、缓存、独立代理或安全 DNS 设置，不需要修改订阅。

识别 DNS 解析失败

DNS 的作用是把域名转换为可连接的地址。解析失败时，浏览器通常在建立网站连接之前就报找不到地址；解析到错误或过期地址时，则可能表现为长时间等待、证书名称不匹配或只有部分资源无法加载。可以在桌面系统执行 nslookup example.com，观察公开测试域名能否获得结果。若解析失败，先断开并重新连接客户端，让客户端重新接管 DNS，再复测。

系统、浏览器和客户端可能各自维护 DNS 设置。排障时应避免同时启用多套自定义方案，否则请求究竟走哪一路很难判断。可暂时恢复浏览器的自动设置，让系统与客户端负责解析；如果此前手工指定过 DNS，应记录原值后再恢复自动获取。修改完成后，需要关闭旧标签页并重新建立连接，单纯刷新可能继续复用旧解析。

检查系统代理是否指向已退出的客户端

客户端异常退出后，系统代理可能仍指向本机代理端口。此时浏览器把请求交给一个已经不存在的本地服务，表现为所有网页立即失败或持续等待。检查系统代理设置，如果客户端已经退出而代理仍开启，应先关闭残留代理，再重新启动客户端。不要随意填写网上找到的代理地址，也不要把订阅中的服务器地址直接写进系统代理框；客户端本地代理与远端线路是不同层级。

若系统代理设置正确，但某个浏览器仍无法访问，应检查浏览器是否使用独立代理扩展。扩展可能覆盖系统设置，或根据旧规则把目标站点送到另一个出口。最直接的判断方法是在没有扩展的浏览器环境中复测。确认扩展导致问题后，再逐项检查扩展规则，而不是修改整个系统的线路配置。

网页能开但图片、视频或登录接口失败

现代网页通常会从多个域名加载脚本、图片、视频和登录接口。主页面可以打开，不代表所有关联域名都走了相同出口。若页面框架正常但内容缺失，应打开浏览器开发者工具的网络面板，观察失败请求的域名和错误类型。无需提交完整网页内容，只需记录失败域名、请求状态和复现步骤。目标站的资源域名若被错误分流，可能需要切换全局模式做对照测试。

登录循环也可能由出口变化或 Cookie 状态引起。先保持同一线路，不要在登录过程中频繁切换地区。清理目标站点自身的 Cookie 后重新登录，而不是清空全部浏览数据。如果更换地区后恢复，应继续使用该地区完成当前会话。涉及流媒体地区选择时，可阅读体育直播线路选择指南，了解高峰期和地区出口对播放会话的影响。

DNS 泄漏提示不等于连接必然失效

某些检测页会同时列出多个解析出口。判断时要结合客户端模式、系统设置和实际访问结果，不能只看到不同地区名称就认定线路完全不可用。更重要的是确认跨境域名的解析与访问是否按预期经过客户端，以及断开后系统设置能否恢复。若检测结果在同一配置下反复变化，应先关闭浏览器独立安全 DNS，再重建客户端连接，减少并行解析路径。

当所有域名解析失败、不同网络下结果一致、客户端重连和系统代理检查均无效时，应提交工单。请附上解析命令的文本结果，但不要包含真实订阅地址。若只有某个域名失败，应同时提供一个可正常访问的对照域名，这能帮助区分整体 DNS 故障与目标站点问题。

速度慢与晚高峰卡顿怎么判断

速度问题必须先确认基础连接已经稳定。如果连接本身频繁重建，测速和视频缓冲只是在重复观察断线结果。确认普通网页可以连续访问后，再判断问题是首屏加载慢、持续吞吐不足、交互响应迟缓，还是仅在晚高峰发生。不同现象对应的线路选择不同，不能只凭一个测速结果决定整条线路是否可用。

区分延迟、吞吐与稳定性

延迟影响点击后的响应、终端交互、AI 工具对话和在线操作；吞吐影响大型文件、高清视频和持续传输；稳定性则决定长连接能否保持。某条远距离线路可能吞吐充足，但交互响应仍比邻近地区慢；另一条线路短时加载很快，却在持续传输中波动。排查时应根据实际任务选择指标，而不是追求一个笼统的“最快”。

浏览网页时重点观察首次打开和连续跳转是否稳定；使用 AI 编程工具时观察补全、对话和终端会话是否中断；观看视频时观察清晰度是否反复下降与缓冲是否集中在特定时段。关于长连接选择，可参考AI 编程工具线路建议。文章侧重使用场景，本章侧重把故障范围缩小。

用同地区对照排除地理距离

先选择地理位置较近的地区，并在同一地区内切换不同线路。这样可以减少地理距离变化对结果的干扰。如果同地区只有一条线路明显变慢，而其他线路正常，可以暂时避开该线路并记录时段。如果同地区所有线路都慢，再换邻近地区测试；若邻近地区恢复，问题可能集中在原地区出口或目标站点到该地区的路径。

线路页提供 IEPL 专线、中转和直连等标签。IEPL 专线适合重视稳定性的场景，中转可在不同接入环境下提供另一种路径，直连则更依赖当前网络到远端的原始质量。实际选择应通过同一接入网络下的对照测试完成，而不是把线路标签当成绝对排序。前往全部线路可查看地区和类型说明。

晚高峰只在固定时段出现

若白天正常、晚高峰卡顿，先不要重装客户端。固定时段问题更可能与接入网络、跨网路径或目标站并发有关。应在问题发生时保留当前线路结果，然后切换同地区另一线路和不同线路类型进行对照。如果只有目标视频站异常，而普通网页与其他视频站正常，还要考虑目标站自身内容分发节点和账户地区策略。

对照记录应包含同一时段、同一设备、同一接入网络和同一目标任务。若上午测试网页、晚间测试大型下载，结果没有可比性。更有效的记录是：晚高峰期间同一视频在原线路持续缓冲，切到同地区另一线路后恢复；或所有线路都出现相似问题，但更换接入网络后恢复。这样的对照可以直接指出线路侧或接入侧。

先暂停后台传输再复测

系统更新、云盘同步、照片备份和其他设备的大型传输都会竞争当前网络。VPNRH 同时在线不限台数，但“不限台数”不等于每个接入网络拥有无限带宽。多个设备同时传输时，瓶颈可能在本地网络、路由设备或宽带出口。排查时应暂时停止后台同步，只保留当前测试任务；恢复后再逐步开启其他任务，观察哪一项造成明显变化。

套餐流量也要核对。月订阅流量按开通日每月重置，流量耗尽与线路变慢是不同问题。若需要调整用量，可查看套餐与流量包。不要通过重复测速消耗更多流量来证明问题，短时间持续测速容易放大本地网络波动，也无法代表长连接的真实稳定性。

避免常见的错误结论

单次测速低不能证明服务整体故障，单次测速高也不能证明长连接稳定。测速站可能自动选择不同测试服务器，目标内容站也可能使用完全不同的网络路径。应把测速作为辅助，优先记录真实业务是否可复现。不要在连接过程中频繁切换线路后立刻判断，每次切换都需要让旧连接结束，并让目标应用重新建立会话。

如果问题仅发生在特定线路、固定时段且多次可复现，应提交线路名、线路类型、目标站点、接入网络和发生时段。若更换接入网络后所有线路都恢复，也应明确写出这个结果。客服不需要夸大的“全部都慢”，而需要可比较的路径信息。无法稳定复现时，可以先保留记录，等现象再次出现再补充，不必不断修改系统设置。

频繁断线与移动端后台掉线

频繁断线需要区分“客户端通道断开”和“应用会话失效”。前者通常伴随客户端状态变化、系统连接图标消失或所有应用同时中断；后者可能只影响某个网站、视频或 AI 对话，客户端仍保持连接。先观察断线发生时客户端状态，不要仅凭某个页面转圈就判断整个通道已经断开。

判断断线是否跟随网络切换

设备从一个接入点切到另一个接入点，或从无线网络切换到其他网络时，原有连接路径会变化。部分客户端能够自动重连，但应用里的旧会话可能不会自动恢复。若断线总发生在网络切换后，应在切换完成后主动确认客户端状态，必要时断开再连接，而不是继续使用已经失效的旧会话。

移动端从弱信号区域恢复时，也可能保留一个表面在线、实际不可用的网络状态。可以先关闭并重新开启当前网络连接，确认普通访问恢复，再重连客户端。如果每次在同一地点发生，问题可能来自接入网络质量；如果不同网络下都在相似操作后断开，则应检查系统后台策略和客户端权限。

处理移动端后台限制

iOS 与 Android 会根据电量、后台活动和网络状态管理应用。若客户端进入后台一段时间后被系统暂停，重新回到前台时可能需要重新建立通道。应在系统设置中允许客户端保持必要的后台网络活动，并检查省电策略是否限制该应用。不同系统界面名称可能不同，本手册不依赖具体版本菜单；可以从应用信息、电量使用和后台活动相关入口查找。

不要同时开启多个具有网络接管能力的应用。系统通常只能让一个主要连接配置生效，另一个工具启动时可能替换当前配置，表现为 VPNRH 客户端突然断开。清理冲突时应逐个退出其他工具，再重启当前客户端。仅从最近任务界面移除图标不一定代表连接组件已经退出，最好使用应用内断开功能。

区分休眠恢复与持续断线

若只在设备锁定、休眠或网络切换后发生，而持续使用时稳定，重点是系统后台和网络恢复逻辑。若前台持续使用也反复断线，应转向线路、协议和接入网络检查。保持同一线路，更换接入网络后复测；如果恢复，说明原网络的连接保持能力较差。保持网络不变，更换线路类型后恢复，则说明路径或协议兼容性更值得检查。

桌面系统从休眠恢复后，系统代理、虚拟接口和 DNS 状态也可能不同步。最稳妥的恢复顺序是先确认本地网络已恢复，再在客户端中断开并重新连接，最后重新打开目标应用。若直接恢复旧浏览器标签页，它可能继续使用休眠前的失效连接，从而误判为客户端仍然断线。

长连接应用为什么更容易暴露问题

普通网页请求完成后连接可以结束，而 AI 工具、终端会话、实时协作和直播会长时间保持连接。短暂网络切换对网页可能只表现为刷新变慢，对长连接则会直接中止当前任务。因此排查这类问题时，不能只测试网页能否打开，还要观察完整工作过程是否持续。若应用支持自动重连，也要记录自动重连后上下文是否保留。

为了确认线路稳定性，应选择一个可以安全重复的实际任务，保持设备、网络和线路不变，观察断线是否出现在固定操作之后。不要同时运行多个大型传输作为压力测试，因为这会把本地带宽竞争与线路稳定性混在一起。如果暂停后台同步后长连接恢复，应先处理本地资源占用，再判断线路。

连接保持设置应谨慎修改

部分客户端提供自动连接、按需连接、休眠后恢复和网络变化时重连等选项。应先使用默认配置确认问题，再逐项开启所需功能。一次启用多个自动化选项会让客户端在网络变化时重复发起连接，反而出现状态来回切换。修改后应记录选项名称和结果，确认无效就恢复原状。

如果同一账户在多个设备上使用，VPNRH 同时在线不限台数，因此设备数量本身不是频繁断线的正常原因。但多个设备共享同一个接入网络并持续传输，仍可能影响本地网络稳定性。测试时可以暂时停止其他设备的大型任务，但不需要删除设备或退出所有账户。

提交断线工单需要什么

可复现的断线工单应说明平台、当前线路、接入网络、断线发生前的操作、客户端状态是否变化、是否经过休眠或网络切换，以及更换网络或线路后的结果。若客户端提供不含凭据的运行日志，可截取故障前后的错误行；提交前检查日志中是否包含完整订阅地址或认证字段。无法确认时只提交错误文字和截图，不要上传整个配置文件。

订阅更新失败或线路列表不变化

订阅更新是客户端取得线路列表和配置参数的入口。更新失败不等于所有已有线路立即失效：客户端可能仍保留上一次成功更新的本地副本，但无法取得后续变化。排查时应先区分“订阅地址无法读取”“读取后解析失败”“更新成功但界面仍显示旧列表”和“导入到了错误的配置组”。

从面板重新复制，不手工修补链接

登录用户面板，从订阅入口重新复制完整链接。复制时应使用界面提供的复制操作，避免长按选择时遗漏开头、结尾或查询参数。不要手工替换域名、协议头或认证字段，也不要在链接前后添加引号。真实订阅地址属于账户凭据，不应粘贴到搜索引擎、在线格式化工具、公开代码仓库或工单正文。

用于教程和问题复现的链接必须是明显假值，例如：

https://example.com/sub?token=YOUR_TOKEN

如果复制后更新失败，可先把链接粘贴到本地纯文本编辑器检查是否被换行，但不要保存到会自动同步或公开分享的位置。确认没有空格和换行后，再回到客户端覆盖原订阅地址。不要把真实地址放进终端历史记录或截图。

区分网络错误与格式错误

更新时提示超时、无法解析域名或连接失败，通常是客户端无法访问订阅入口，应先验证本地网络和 DNS。提示格式无效、解析失败或配置字段错误，则说明内容已经取得，但客户端无法理解返回格式。此时应确认导入方式与客户端支持的订阅格式匹配，并优先使用本站客户端与面板提供的导入入口。

若浏览器可以打开普通网页，但客户端更新始终失败，应检查客户端是否被系统防火墙、独立代理或旧网络设置限制。更新订阅时不要同时开启另一个网络工具。可以先断开当前连接，在基础网络正常的情况下更新；更新完成后再连接新线路。若当前网络无法直接取得订阅，也可在已有可用线路保持连接时尝试，但应记录哪种状态成功，便于识别网络路径差异。

更新成功但线路列表没有变化

先确认客户端正在查看刚更新的配置组。部分客户端允许保存多个订阅，更新结果可能进入另一个组，而当前选择仍停留在旧配置。核对订阅名称、最后更新状态和当前启用的配置，不要仅凭线路数量判断，因为线路调整不一定改变总量。VPNRH 的覆盖事实为 120+ 国家 / 170+ 线路，客户端本地显示方式可能按地区、协议或策略组重新组织。

如果客户端提示更新成功但内容明显仍旧，可完全退出后重新打开，让界面重新读取本地配置。仍无变化时，先导出或记录必要的自定义规则，再删除旧订阅项并重新导入。不要直接清空整个客户端数据，因为这会同时删除其他诊断信息和个人规则，使问题更难复现。

配置解析失败后的恢复顺序

先撤销手工修改，恢复订阅生成的原始内容。若曾将配置复制到其他格式再导回，转换过程可能丢失协议参数或策略组关系，应停止使用转换后的副本。回到面板重新取得订阅，通过客户端原生订阅入口导入。导入完成后先测试默认线路，不要立刻添加复杂规则。

若新导入可以工作，说明问题位于旧配置或自定义修改。可以逐项迁移必要规则，每迁移一项就复测。若原始订阅也解析失败，应记录客户端名称、平台、完整错误文字和订阅更新动作，不要把配置正文直接发送给客服。客服可以根据错误类型检查订阅输出，无需取得可使用的完整认证信息。

订阅泄露后的处理

如果真实订阅链接曾出现在公开位置，或被发送给不应取得访问权限的人，应登录面板重置订阅，再在所有使用中的客户端更新。旧链接失效后，未更新的设备会表现为订阅更新失败或线路不可用，这属于预期结果。应逐一替换旧配置，不要为了恢复旧设备而再次公开新链接。

关于订阅链接的获取、导入、更新与泄露处理，可阅读订阅链接完整指南。本章关注故障判断，文章则解释订阅在客户端中的完整生命周期。首次在 macOS 上配置时，还可参考macOS 安装与权限教程。

什么时候需要工单核对

当不同接入网络下都无法更新、面板显示订阅可用、重新复制后仍出现相同错误，并且客户端原生导入入口也失败时，应提交工单。请提供平台、客户端名称、错误文字、发生时段、更新动作和已经测试的网络环境。链接只需说明“已从面板重新复制”，不要附完整值。若重置订阅后才开始失败，也要明确写出重置与故障的先后关系。

某个 App 不走代理或只有单一服务异常

浏览器正常而某个 App 无法访问，通常说明基础连接已经建立，故障集中在应用是否读取系统代理、客户端分流规则、域名解析方式或应用缓存。此时重装整个客户端往往收效有限。应先确认该 App 的请求是否进入通道，再判断目标域名是否被分到正确出口。

系统代理与虚拟接口的差异

有些桌面应用会读取系统代理，有些应用直接建立网络连接，不使用系统代理设置。仅开启系统代理时，前者可以正常访问，后者可能仍走原网络。客户端若支持虚拟接口模式，可以接管更多不读取系统代理的流量，但需要相应系统权限。排查时应先查看当前模式，不要假设所有应用行为与浏览器一致。

切换模式前应记录原设置，并完全退出目标 App。应用启动时可能读取一次网络配置，运行过程中切换系统代理未必会让它重新选择路径。修改客户端模式后重新打开 App，再执行同一个操作复测。若恢复，说明问题与流量接管方式有关；若仍失败，再检查分流规则和目标站点。

用全局模式做短暂对照

如果客户端提供规则模式和全局模式，可以短暂切到全局模式进行诊断。全局模式下目标 App 恢复，通常说明原规则没有覆盖相关域名或进程；全局模式下仍失败，则更可能是应用缓存、账户地区、线路出口或应用自身故障。对照结束后应恢复日常使用模式，避免把不需要跨境线路的流量长期送入通道。

不要只添加主域名。一个 App 可能使用独立的登录、接口、静态资源和媒体域名。可以从应用日志或浏览器开发者工具中识别失败域名，但不要使用来源不明的抓取工具。若无法确定域名，提交应用名称、失败功能和全局模式对照结果，客服可以根据现象提供更安全的检查方向。

进程分流与域名分流不要混用判断

进程分流按照应用程序识别流量，域名分流按照访问目标识别流量。应用自更新、辅助进程或内嵌网页可能由另一个进程发起，因此只添加主程序名称并不一定覆盖全部请求。相反，域名规则可能被应用的独立 DNS 或直连行为影响。排查时一次只使用一种清晰的对照方式，避免进程规则与域名规则互相覆盖。

若目标 App 有多个组件，应观察是登录失败、内容加载失败还是实时功能失败。登录正常而内容失败，可能是资源域名未进入通道；内容正常而实时功能断开，可能是长连接或协议兼容问题；整个 App 均无法联网，则优先检查流量接管与本地安全策略。将“这个 App 不行”拆成具体功能，才能选择正确的分流对象。

检查应用自己的代理与 DNS 设置

开发工具、终端程序和部分桌面软件可能拥有独立代理设置。若其中保留了旧地址，即使系统代理正常，应用仍会向无效端口发送请求。应检查应用网络设置是否选择自动跟随系统，或是否存在历史代理值。环境变量也可能覆盖图形界面设置，特别是在终端启动的工具中。

可以在终端查看常见代理环境变量是否存在。以下命令只读取当前环境，不会修改配置：

env | grep -i proxy

如果输出包含不再使用的本地地址，应回到设置这些变量的配置文件中处理，而不是在每次启动后临时覆盖。修改前保存原内容，修改后重新打开终端和目标程序。不要把远端线路地址或订阅链接写进代理环境变量；应用应连接客户端提供的本地代理入口。

地区出口与应用账户状态

某些服务会根据线路出口地区、账户地区和已有会话共同决定可用内容。频繁切换地区可能触发重新登录或使旧会话失效。排查时选择一个符合使用场景的地区并保持不变，退出目标 App 后重新进入。如果浏览器访问该服务正常，而 App 仍失败，可清理该 App 的网络缓存或重新登录，但不要同时更换线路与账户设置。

流媒体应用尤其依赖多个资源域名和地区出口。线路是否支持目标内容，应以当前实际访问结果为准。若某地区线路不能播放而其他地区可以，记录目标服务、线路地区和失败环节，并查看线路说明。不要把一次内容下架、账户权限或目标服务维护误判为线路故障。

何时需要提供应用级信息

如果全局模式可以恢复，应在工单中说明规则模式失败、全局模式正常，并写明具体功能。若所有模式都失败，但浏览器访问同一服务正常，应提供 App 名称、平台、线路地区、失败步骤和错误文字。无需提供应用账户密码、会话 Cookie 或完整网络抓取文件。涉及命令行工具时，可以提交已脱敏的错误输出和代理环境变量名称，但应移除令牌与内部项目地址。

设备数超限提示、账户核对与工单信息

VPNRH 的事实规则是同时在线不限台数。因此，若界面出现“设备数超限”或类似提示，不应先购买更多设备名额，也不应把它解释为套餐自带的设备上限。更可能需要核对的是客户端本地配置、账户登录状态、旧会话、订阅是否属于当前账户，以及提示究竟来自 VPNRH 面板、客户端还是目标应用。来源不同，处理方式完全不同。

先确认提示来自哪里

记录提示出现的页面和操作。若提示出现在目标 App 内，它可能描述的是该 App 自己的账户设备政策，与 VPNRH 无关；若出现在第三方客户端界面，可能是客户端配置或本地策略；若出现在 VPNRH 用户面板或本站客户端，则应保留完整截图并提交工单核对。截图应包含页面标题和提示上下文，不能只截取“超限”两个字。

同时确认当前登录的是预期账户。VPNRH 注册无需邮箱地址，使用用户名和密码即可注册，因此在不同设备上输入相近用户名时，可能误进另一个账户。应核对用户名和套餐状态，不要在工单中发送密码。若忘记当前账户来源，应从已正常使用的设备查看账户页面，再与异常设备对照。

清理重复配置而不是删除全部设备

同一设备中重复导入订阅，可能产生多个名称相似的配置组。客户端切换到旧配置后，可能显示过期状态、更新失败或旧线路，并被误认为设备限制。先确认当前启用的订阅，只保留一个经过验证的配置组。删除前记录自定义规则，避免误删仍在使用的配置。

如果订阅曾重置，所有设备都需要换用新订阅。仍使用旧链接的设备会更新失败，这也不属于设备数超限。应从面板重新复制订阅，逐个更新。VPNRH 支持 Windows / macOS / iOS / Android / Linux，各平台界面不同，但判断逻辑一致：确认账户、确认当前订阅、确认更新成功，再测试线路。

账户与计费问题不要通过网络设置解决

面板显示套餐状态、流量或订单异常时，不要修改 DNS、系统代理和线路配置。这些设置不会改变账户记录。月订阅为 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按开通日每月重置，中途升级差价折算成剩余天数。流量包为 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止，永久不过期。支付方式为支付宝 / 微信 / USDT。

若支付完成后页面状态未按预期更新，应保留订单页面状态、支付方式和发生时段，通过工单核对。不要重复付款来验证页面是否会变化，也不要把完整支付凭据发到公开渠道。套餐选择与流量规则可在套餐页面查看。正文中的退款承诺为 14 天无理由退款，具体申请应按条款与工单流程处理。

工单应包含可复现信息

一份有效工单应让处理人员在不了解现场的情况下重建判断路径。标题直接写症状，例如“Windows 全部线路连接超时”或“Android 切到后台后连接中断”，不要只写“不能用”。正文先写平台和客户端，再写发生时段、接入网络、线路名称与类型、完整错误文字、复现步骤、已经完成的排查和对照结果。

复现步骤应按实际顺序描述：打开客户端、更新订阅、选择线路、点击连接、打开目标应用、出现何种错误。若问题只在特定条件出现，要明确条件，例如仅在晚高峰、仅在某个接入网络、仅在休眠恢复后或仅在规则模式。对照结果同样重要，例如更换网络后恢复、同地区其他线路正常、全局模式正常而规则模式失败。

工单中不应提交的内容

不要提交账户密码、真实订阅链接、完整认证字段、支付密码、应用会话 Cookie 或未脱敏的配置文件。这些内容不是定位普通连接故障所必需。若日志中包含 URL 查询参数，应先遮盖；若无法判断日志是否安全，可以只发送错误文字和发生位置。客服需要的是故障上下文，不是可以直接使用的账户凭据。

也不要只发送大型录屏而不写文字。录屏可以作为补充，但处理人员仍需要可搜索的错误文本和清晰步骤。截图中若同时出现多个客户端窗口，应标注当前实际使用的一个，避免把旧配置与新配置混淆。问题恢复后，也可以在工单中补充是哪项修改生效，这有助于确认根因并避免重复建议。

什么时候应立即提交工单

账户状态或订单记录与页面显示不一致、面板出现设备数超限提示、多个接入网络下所有线路均无法连接、订阅原生导入持续解析失败、特定线路在可复现条件下持续异常，或已完成对应章节全部检查仍无法缩小范围时，应提交工单。进入用户面板工单入口后，按本章清单整理信息。

若问题已经通过切换单条线路解决，可以继续使用可用线路，同时提交失败线路和对照结果，不必等待原线路恢复。若问题来自本地网络、浏览器扩展或目标 App，自行处理后应保留简要记录。下一次出现相同症状时，先复用已验证的判断步骤，而不是重新安装全部组件。