VPNRZ 故障排查手册

先建立可复现的排查基线

先描述症状，不急着描述原因

有效排查从现象开始。把“服务坏了”改写成可以验证的句子，例如：客户端无法完成连接；客户端显示已连接，但浏览器打不开任何网站；只有某个应用访问失败；普通时段可用，晚高峰明显卡顿；切到移动网络后恢复，而当前无线网络仍失败。这样的描述能直接决定下一步检查哪一层。相反，“节点不行”“协议有问题”已经带入结论，容易让后续操作围绕错误方向打转。

记录现象时要保留四类上下文：使用的平台、当前网络入口、选择的地区或线路类型、失败发生在哪个动作。平台写 Windows、macOS、iOS、Android 或 Linux；网络入口只需区分家庭宽带、办公网络、公共无线网络或移动网络；线路写客户端显示的完整名称；动作写连接、打开网页、播放内容、更新订阅或恢复后台。错误弹窗不要凭记忆转述，直接复制原文或截图，因为“认证失败”“解析失败”“连接超时”对应的检查层完全不同。

做一个最小对照组

最小对照组的目标不是立即恢复，而是判断问题跟着什么变化。先保持同一台设备和同一个客户端不动，只把当前网络切换为另一个可用入口。如果症状随网络改变，优先检查本地网络、路由器或网络提供方；如果两种入口都失败，再把线路换成另一个地区。如果只有单条线路异常，问题范围已经缩小到线路；如果所有线路都失败，再看账户状态、订阅内容和客户端配置。

接着用同一网络、同一订阅，在另一个受支持平台做对照。另一台设备能连接，说明账户与线路大概率仍可用，应回到原设备检查客户端权限、系统代理、DNS、后台限制和旧配置残留。另一台设备也失败，则不要继续反复安装，先登录用户面板确认订阅状态，并重新获取当前订阅。VPNRZ 支持 Windows / macOS / iOS / Android / Linux，同时在线不限台数，因此正常的多设备对照不会因为本服务的设备数量限制而失去意义。

一次只改变一个变量

排查中最常见的误区，是为了节省时间同时改动多个项目。比如先清理配置，又切换协议，再重启路由器；即使最后恢复，也无法知道真正的故障点，下次还会从头重来。更稳妥的方式是建立一张简短记录：当前线路、当前协议、当前网络入口、当前结果。每次只改其中一项，等待连接状态稳定后再测试同一个目标。如果变化无效，就恢复原值再进入下一项。

测试目标也要固定。先选一个平时稳定、无需登录的普通网页，再选实际出问题的服务。普通网页和目标服务都失败，检查连接、路由或 DNS；普通网页正常而目标服务失败，检查出口地区、应用分流、目标服务自身状态或账户区域。不要一开始就用复杂应用作为唯一判断标准，因为应用可能有独立缓存、私有 DNS、内置代理或区域策略，容易把线路问题和应用问题混在一起。

完成这一章后，应当能把问题归入一个明确入口：完全无法连接、显示连接但没有网页、速度或晚高峰异常、频繁断线、订阅更新失败、特定应用不走代理、移动端后台掉线、DNS 异常，或账户状态不一致。后续章节都沿用同一原则：先判断层级，再执行动作，最后用原始测试目标复验。

客户端完全连不上时怎么判断

先区分“没有配置”和“配置后失败”

客户端里没有任何线路，或者线路列表为空，通常不是连接协议本身的问题，而是订阅尚未导入、导入内容失效，或客户端没有读取到配置。此时不要连续点击连接按钮，应先进入用户面板重新取得订阅，再按客户端支持的方式导入。订阅内容属于账户交付信息，不要把完整地址贴进公开讨论区，也不要用搜索引擎打开。若只是首次配置不熟悉，回到快速上手教程按平台完成导入，比在空配置状态下排查连接更直接。

线路已经显示，但点击后很快返回未连接，需要读取客户端日志或错误弹窗。认证类错误优先检查订阅是否为当前账户生成、复制时是否缺失字符、旧配置是否仍被选中；超时类错误优先换网络入口和线路；系统权限类错误则检查客户端是否获得建立网络连接所需的系统授权。不要看到“超时”就认定账户失效，也不要看到“认证”就反复重启路由器，错误类别本身已经指出了更接近的层级。

按账户、线路、网络、系统顺序检查

先登录面板确认账户可以正常进入，并检查当前订阅是否仍处于可使用状态。月订阅流量按开通日每月重置；如果流量已经用完，连接行为可能与正常状态不同。流量包则是用完为止、永久不过期。核对状态后重新获取订阅，并让客户端更新配置。无需邮箱地址，用户名加密码即可注册，但排障时必须确认当前登录的是原账户，而不是误用了另一个用户名保存的空账户。

账户正常后，切换到另一条地区线路。VPNRZ 覆盖 100+ 国家 / 220+ 线路，不同线路会经过不同入口与中继，单条线路失败不能直接推导为全部线路不可用。先选与当前位置距离较近的地区，再尝试另一种线路类型。线路列表和类型说明可在全球节点页面查看。切换时等待前一次连接完全断开，再发起新连接，避免旧会话尚未释放造成状态显示混乱。

多条线路都超时，再切换网络入口。家庭宽带失败而移动网络正常，说明客户端和订阅本身具备连接能力，重点转向路由器、局域网 DNS、办公网络策略或当前接入环境。办公和公共网络可能限制部分连接方式，这类环境下不应修改不属于自己的网络设备；可以保留日志，换到可管理的网络继续确认。若所有网络入口都失败，再检查系统时间是否自动同步、系统网络权限是否被关闭，以及安全软件是否刚刚调整了网络规则。

清理旧会话，而不是盲目重装

客户端偶尔会保留未正常结束的虚拟网络会话。先在客户端内主动断开，完全退出程序，再重新打开。如果系统仍显示代理或虚拟网络处于启用状态，可在系统网络设置中关闭对应项目，然后重新启动客户端。只有在确认配置已经备份、订阅可以重新获取时，才考虑删除旧配置或重新安装。直接卸载可能同时删除日志和现场信息，让原本清楚的错误变成无法复现的偶发问题。

重装之后仍然完全连不上，应避免继续循环重装。此时更有价值的是交叉验证：同一账户换另一台设备、同一设备换另一种网络、同一网络换另一条线路。三组结果可以把范围压缩到设备、网络或服务端线路。若所有受支持平台、多个网络入口和多条线路均在同一时间失败，把这些对照结果提交工单，比只写“连不上”更容易得到准确处理。

如果错误只在特定网络出现，记录网络类型和可复现时间；如果只在特定线路出现，记录线路完整名称；如果只在某个平台出现，记录系统和客户端名称。不要自行猜测服务端原因。排查的目标是把“完全连不上”拆成可被验证的分支，确认失败发生在配置生成、客户端读取、线路握手、本地网络还是系统权限。

显示已连接却打不开网页与 DNS异常

“已连接”只代表隧道已经建立

客户端显示已连接，说明本地客户端与所选线路完成了连接过程，但不代表域名解析、系统路由和目标服务一定正常。此时不要继续把注意力放在连接按钮上，而要分别测试域名、网络出口和应用。先打开一个无需登录的普通网站；如果所有网站都失败，再测试能否通过命令行获取响应头。普通网站全部失败时，常见范围是 DNS 没有返回结果、系统流量没有进入隧道、旧代理设置仍在接管，或本地网络在连接后没有正确更新路由。

若只有域名打不开，而直接访问已知网络地址可以响应，问题更接近 DNS；若域名可以解析，但请求一直等待，则更接近路由、线路或目标端响应。普通用户不必凭感觉区分，可以用系统自带工具查看。示例域名只用于测试，不含任何真实订阅信息：

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

nslookup 能返回解析结果，而 curl 无法建立请求，说明解析环节至少有响应，应继续检查系统代理、路由与线路。解析命令本身就失败，则先清理系统 DNS 缓存，再断开并重新连接客户端。执行命令时保留完整输出，不要只截最后一行，因为前面的服务器来源、超时描述和错误类型都可能有用。

清理缓存前先确认影响范围

浏览器打不开网页，但其他应用正常，优先使用浏览器的隐私窗口测试，并暂时停用浏览器内单独配置的代理扩展。浏览器可能缓存旧的 DNS、证书状态或代理规则，这种情况不应立刻修改整个系统。相反，如果浏览器、命令行和其他应用都失败，才需要检查系统级 DNS 与代理。先断开客户端，确认本地网络在不连接时能正常访问普通网站；本地网络本身就异常，应先恢复基础网络，再继续排查加速连接。

不同系统清理 DNS 缓存的方式不同。下面命令均为系统常用操作，执行后需要重新连接并再次测试同一个域名。Linux 的具体服务取决于当前发行版和网络管理方式；命令不可用时，应查看系统实际启用的解析服务，而不是从网上复制不匹配的配置文件。

检查系统代理与应用自己的解析路径

系统代理和虚拟网络模式可能同时存在。若曾经手工填写代理地址，后来改用客户端的全局连接模式，旧地址仍可能截获浏览器请求。进入系统网络设置，确认当前代理状态与客户端工作方式一致。不要随意删除企业管理配置或不认识的系统配置；如果设备受组织管理，应先询问管理员。个人设备则可以记录原值后暂时关闭手工代理，重新连接客户端验证。

部分浏览器和应用会启用自己的安全 DNS 或私有解析功能，因此系统命令正常并不代表应用一定使用同一条解析路径。若只有某个浏览器失败，在该浏览器设置中检查是否指定了独立 DNS；若只有某个应用失败，进入后文的应用分流章节。排查时不要把多个 DNS 地址逐个乱试。频繁更换会让缓存、系统设置和客户端设置同时变化，最后很难判断是哪一项产生作用。

还有一种常见现象：普通网站能打开，但需要特定地区出口的服务提示区域不符。这个结果不属于 DNS 故障，应确认当前所选线路地区，并重新启动目标应用以清理旧会话。目标服务可能根据账户区域、缓存、出口地区或自身策略判断内容范围，不能只凭一个提示推断线路完全不可用。先用同一线路测试普通网页，再换另一条符合场景的地区线路做对照。

如果清理缓存、关闭旧代理、切换线路和网络入口后，所有域名仍无法解析，应把解析命令的完整输出、当前平台、线路名称和网络类型提交工单。若只有目标服务异常，则附上普通网页正常的对照结果。这样的信息可以明确告诉支持人员：隧道已经建立，问题位于解析、路由或目标服务层，而不是再次从账户登录开始重复询问。

速度慢与晚高峰卡顿的分层判断

先区分吞吐、响应和应用缓冲

用户口中的“慢”可能指三种不同现象：网页第一次打开等待很久、文件传输持续速度低、视频或会议间歇缓冲。网页首开更受解析和响应路径影响；持续传输更受本地带宽、线路拥塞和目标端限制影响；视频会议则还会受抖动、丢包与应用自适应策略影响。排查前先说清楚是哪一种，不要只提交一张速度截图。截图只能反映某个测试目标在某次会话中的结果，不能单独解释实际应用为什么卡顿。

先断开客户端，确认本地网络本身没有明显异常。基础网络已经拥堵时，任何跨境线路都只能在现有条件上工作。接着保持设备、网络和测试目标不变，连接距离较近的线路，重复实际场景。不要同时开启云盘同步、系统更新和大文件传输；这些后台任务会争用本地上行与下行。排查会议问题时尤其要检查上传方向，因为画面发送受阻时，对端看到的卡顿可能比本机更明显。

线路选择要匹配目标，而不是只看地区名称

访问目标位于亚洲时，先从邻近地区开始；访问欧美服务时，应结合目标服务所在区域与实际表现选择。更近的地理距离通常意味着更短路径，但跨境链路还受到入口、运营商互联和中继方式影响，因此不能把地图距离当成唯一结论。VPNRZ 提供 IEPL 专线、中转与直连等线路类型，适用场景和路径结构不同。可以在全球节点查看线路说明，再用固定目标做单变量对照。

IEPL 专线适合更看重跨境路径稳定性的场景；中转线路通过额外入口组织跨境路径；直连线路路径更直接，但实际表现仍取决于本地网络和目标端。这里的名称描述的是线路组织方式，不等于对任何地点、任何时段都作出相同结果承诺。最可靠的选择方法仍是：保留同一设备、同一网络、同一目标，依次测试可选类型，并记录实际应用表现。

晚高峰问题要用时间对照确认

如果普通时段正常，晚高峰重复变慢，先判断拥塞发生在本地接入还是跨境路径。保持同一设备和同一线路，在另一个网络入口复验；若另一个入口明显正常，优先检查原网络接入。若不同入口都在相近时段出现相似现象，再换线路类型或地区。不要用相隔很久、目标不同的测试结果直接比较，因为目标服务负载和本地后台任务也会变化。

晚高峰卡顿时，连续切换大量线路通常会让判断更乱。先选当前线路作为基线，再选一条邻近地区线路和一条不同类型线路，分别完成完整的实际任务。视频场景至少观察开始播放、拖动进度和持续播放；会议场景观察语音连续性、画面恢复和重连情况；AI 工具场景观察页面加载、请求提交和响应持续输出。只要明确哪一阶段异常，就能进一步区分解析、首包等待、持续传输和会话保持。

协议切换放在线路与网络之后

协议会影响握手方式、传输特征和对网络环境的适应性，但它不是所有速度问题的第一答案。先证明账户、基础网络和线路可用，再尝试客户端提供的其他兼容协议。切换协议前记录原值，切换后只测试同一个目标。如果协议变化只改善连接成功、没有改善持续传输，就应继续看线路和本地带宽；如果只有某种网络入口对协议敏感，则把网络类型与错误日志一并记录。

不要为了追求单次峰值而忽略稳定性。跨境访问更需要连续完成任务：网页能否稳定加载、会议是否频繁重连、流媒体是否反复降画质、AI 响应是否中途中断。可参考博客中的连接成功率与断线率排查方法，用重复任务而不是单次峰值判断线路。若需要比较年度选择维度，可查看速度、稳定性与售后横向对比。

当多条线路只对单一目标服务变慢，而普通网页和其他应用正常，应考虑目标端状态、账户区域与应用缓存；当所有目标都慢，则检查基础网络和线路；当只有晚高峰异常，则用不同网络入口和线路类型拆分拥塞位置。性能排查的核心不是找到一个最高数字，而是找出哪一段链路随条件变化，并选择在当前网络与任务下更稳定的组合。

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

先判断是谁主动结束了会话

频繁断线可能来自本地网络短暂切换、系统回收后台任务、客户端自身重连、线路会话超时，或设备从无线网络切到移动网络。观察断线前后的系统状态比立刻重装更有用。若每次锁屏后出现，重点检查后台运行与省电策略；若走动时从一个网络切到另一个网络后出现，重点检查网络切换后的重连；若设备静置、网络稳定时仍周期性中断，才进一步比较线路和协议。

先确认基础网络有没有同时掉线。断线发生时，观察无线网络标识是否消失、其他设备是否也短暂无法访问、路由器是否重新拨号。如果整个局域网同时异常，应先处理基础网络。只有客户端连接断开而普通网络仍然正常，才进入线路、协议和后台权限排查。把两类问题混在一起，会导致支持人员重复检查并不存在的线路故障。

移动端要检查后台策略和网络切换

移动系统会根据省电状态、后台活动权限和网络质量管理应用。若锁屏后连接消失，检查客户端是否允许后台运行，系统是否对其启用了严格省电限制，以及虚拟网络连接是否仍被授权。调整后不要马上下结论，应重新连接，锁屏，再恢复前台，用同一网站或应用复验。若只有长时间静置后断开，可记录进入后台前后的客户端状态和系统提示。

从无线网络切换到移动网络时，原有连接路径已经改变，客户端通常需要重新建立会话。若切换后一直停在“连接中”，先主动断开，再重新连接；不要连续点击开关。反过来，从移动网络回到无线网络也要做同样检查。某些公共无线网络需要先完成网页认证，如果基础网络尚未真正联网，客户端无法在其上建立稳定连接。先断开客户端完成网络认证，再重新连接。

若移动端只有某个应用恢复前台后无法访问，而浏览器正常，问题更可能在应用会话缓存或分流规则。完全关闭目标应用后重开，观察是否恢复；如果恢复，说明线路没有整体断开。若所有应用都失败，再看客户端是否仍显示连接、系统是否保留虚拟网络标识，以及 DNS 是否重新分配。不要把应用自身登录过期误判为线路掉线。

桌面端要排除休眠、网卡与旧代理

Windows、macOS 与 Linux 在睡眠和唤醒后，网卡状态、路由表和 DNS 可能发生变化。若问题只在唤醒后出现，先断开客户端，等待基础网络恢复，再重新连接。不要在基础网络尚未取得地址时连续发起连接。外接网卡、扩展坞或无线网络切换也可能让原有会话失效，排查时应记录是否刚发生了休眠、网卡切换或网络入口变化。

桌面端若在设备持续运行时反复断线，打开客户端日志，查看每次中断前是否有相同错误。错误一致且只发生在某条线路，换同地区的另一条线路对照；不同线路都在同一网络下断开，再换网络入口；只有某台设备断开，则检查本机安全软件、网络驱动和系统代理。不要一开始升级所有组件或修改驱动，高影响操作应放在对照完成之后。

用稳定任务验证，而不是只看状态灯

客户端状态灯保持连接，不代表应用会话没有中断；状态灯短暂重连，也不一定会影响已具备恢复能力的应用。验证应以任务为中心。浏览场景持续打开相同站点，会议场景观察语音和画面是否恢复，终端场景查看长连接是否断开。需要长期保持的任务，尽量避免在过程中主动切换网络入口或线路。

如果只有流媒体在播放一段时间后缓冲，不能直接归入连接断线，应回到性能章节检查持续吞吐和目标端策略。如果页面提示域名解析错误，则回到 DNS 章节。如果客户端明确从已连接变成未连接，并且日志记录了会话结束，才把重点放在线路、协议和系统后台。分类准确可以避免在错误章节重复操作。

持续断线且无法通过网络、线路、设备对照定位时，提交工单应附上断线前后的日志片段、平台、线路名称、网络入口、是否发生锁屏或网络切换，以及普通网络是否同时中断。日志可以隐藏个人订阅内容，但不要裁掉错误时间附近的上下文。支持人员需要看到会话由哪一层结束，而不仅是断线后的最终界面。

订阅更新失败与某个 App 不走代理

订阅更新失败先看获取链路

订阅更新包含几个连续环节：登录正确账户、取得当前订阅、客户端发起读取、解析配置、替换本地线路列表。任何一环失败都会表现为“更新失败”，因此需要查看失败发生在哪里。面板无法登录，应先处理账户凭据；面板可以登录但客户端提示地址无效，重新复制当前订阅；客户端能够读取却提示解析错误，检查所用客户端是否支持订阅内容；更新成功但线路没有变化，则检查是否仍在查看旧配置分组。

复制订阅时不要手工删除或改写字符，也不要把地址经过第三方短链接服务。订阅属于账户凭据，应只在自己的客户端和用户面板之间传递。若怀疑订阅已经泄露，进入面板重新处理账户交付信息，并避免在工单正文中粘贴完整地址。提交问题时可以写“订阅读取返回认证错误”或附遮盖敏感部分的截图，支持人员通常不需要公开看到完整凭据。

客户端中存在多个配置时，更新按钮可能只更新当前选中的分组。确认正在操作的配置名称，再执行更新；完成后查看线路列表是否改变。不要在多个客户端之间反复导入经过编辑的配置副本，否则很难确认哪一份是当前来源。需要理解订阅获取、导入与泄露处理，可查看订阅链接完整说明。

用明显的假地址检查客户端输入格式

排查输入框是否接受完整 URL 时，可以用文档示例确认格式结构，但不能把示例当成真实订阅。下面地址明确使用公共示例域名和假令牌，只用于辨认客户端需要的是完整链接，而不是一段被截断的文本：

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

如果客户端把地址识别成搜索词、自动补上空格或只保留部分字符，应改用系统剪贴板重新粘贴，并确认输入框类型是“从 URL 导入”而不是“本地文件”。二维码导入失败时，也应回到文本方式确认，避免把相机权限问题误判为订阅问题。更新完成后先选择一条线路连接，再检查应用；仅看到线路列表不代表连接已经建立。

某个应用不工作时先做浏览器对照

浏览器正常、某个 App 无法访问，说明账户、线路和基础解析至少具备部分可用性。此时重点看应用是否遵循系统代理、是否使用独立网络栈、是否被分流规则设为直连，以及应用启动时是否缓存了连接。先完全退出目标应用，确认客户端已经连接，再重新启动目标应用。若恢复，问题多半是旧会话；若仍失败，切换客户端的规则模式与全局模式做对照，但修改前必须记录原模式。

规则模式按域名、地址或应用匹配流量。规则缺失、规则过旧或目标服务新增域名时，主页面可能能打开，部分资源却加载失败。全局模式正常而规则模式失败，说明应检查规则集和应用涉及的域名；两种模式都失败，则检查线路地区、目标服务状态和应用账户区域。不要长期保留全局模式作为唯一修复结论，应理解它只是用于定位分流层的对照工具。

部分应用不读取传统系统代理，但会遵循系统建立的虚拟网络；另一些应用可能启用自己的 DNS 或连接优化。不同平台行为也有差异。Android 与 Linux 上还可能存在按应用选择的分流设置，macOS 与 Windows 则常见系统代理和虚拟网络模式并存。排查时先确认客户端当前使用哪种接管方式，再查看目标应用是否被排除。不要照搬其他平台的菜单名称和配置路径。

如果目标应用只在某个地区线路失败，而其他地区正常，记录线路和应用名称；如果所有线路都只对该应用失败，提交应用启动后的错误原文、规则模式与全局模式对照、浏览器是否正常。若订阅更新失败，则提供面板是否可登录、重新获取后是否仍失败、客户端解析提示和旧配置是否可连接。把订阅问题与应用分流问题分开描述，能避免支持人员把两个独立故障当成同一个现象。

设备数超限提示与账户状态核对

先确认提示来自哪里

VPNRZ 同时在线不限台数，因此看到“设备数超限”或相近提示时，不能直接认定是本服务限制。先确认提示来自用户面板、客户端、操作系统，还是目标应用。某些客户端会限制本地配置实例，某些应用会限制自身账户的登录设备，企业网络也可能限制并发会话。这些提示虽然文字相似，处理位置完全不同。截图时要保留窗口标题和提示来源，不要只截中间一句话。

如果提示来自目标流媒体、AI 工具或其他第三方账户，应查看该服务自己的账户规则，本服务无法改变目标服务的登录限制。若提示来自客户端，检查是否导入了重复配置、是否有旧进程仍在后台运行，以及客户端是否把同一配置识别为多个本地实例。若提示来自 VPNRZ 面板或线路连接过程，则记录完整原文并提交工单，因为这与同时在线不限台数的事实不一致，需要核对账户会话状态。

多设备共用时保持账户来源一致

家庭或个人多设备使用时，最容易出现的问题不是设备数量，而是不同设备保存了不同时间获取的订阅。某台设备仍使用旧配置，另一台设备使用当前配置，出现故障时看起来像“新设备挤掉旧设备”。正确做法是登录同一个账户，从面板重新获取当前订阅，并在各设备上确认配置来源。无需邮箱地址，用户名加密码即可注册，因此尤其要保管好准确用户名，避免因为相似用户名进入另一个账户。

更换密码、重置账户信息或更新订阅后，旧客户端可能继续保留缓存。先在故障设备上更新订阅，再断开并重新连接。不要为了同步而把配置文件通过公开渠道发送给其他人，也不要把订阅地址放进共享文档。需要多人共同使用时，应明确谁负责更新账户信息，避免不同设备各自编辑配置，最终无法确认哪份仍有效。

如果只有新设备无法连接，而原设备正常，账户和线路通常仍有可用路径。比较两台设备的客户端类型、配置分组、线路名称和网络入口。先让新设备使用与原设备相同的网络，再选相同线路；若仍失败，问题更接近新设备配置或系统权限。若新设备换网络后恢复，则检查原网络，而不是继续怀疑设备数量。

账户可登录不等于订阅状态完全正常

登录成功只代表凭据有效，还需检查当前套餐、流量状态和订阅是否属于该账户。月订阅包含 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按开通日每月重置，中途升级差价折算成剩余天数。流量包为 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止、永久不过期。若套餐状态与预期不同，应先核对当前用户名和订单，而不是继续修改客户端。

中途升级后发现剩余时间变化，应按差价折算成剩余天数理解，不要把时间变化误判为账户异常。月订阅流量按开通日重置，也不是统一按自然月变化。排查流量时应以面板显示和开通日为准。如果只是需要重新选择套餐，进入价格页面核对规则，再从用户面板处理。支付宝 / 微信 / USDT 是支持的支付方式；支付完成后的账户状态问题应保留订单状态页面，不要重复创建多个相同操作。

区分账户、订阅和目标服务账户

一次跨境访问可能同时涉及 VPNRZ 账户、客户端本地配置和目标服务账户。VPNRZ 用户名用于取得订阅；客户端读取订阅并建立连接；目标应用则使用自己的登录体系。目标应用要求重新登录，不代表 VPNRZ 账户退出；客户端提示配置过期，也不代表目标应用账户失效。排查时把三者分开记录，可以避免重置错误的凭据。

若怀疑有人取得了订阅信息，应先保护 VPNRZ 账户并更新相关交付信息，再逐台设备重新导入。不要在仍不确定账户安全时继续把同一订阅复制到更多设备。若只是家庭共享的设备管理问题，可参考多设备账号与同时在线说明，重点区分登录数量、同时在线和客户端本地实例这几个不同概念。

工单中应提供当前用户名的部分可识别信息、提示来源、平台、客户端名称、是否只有新设备失败、原设备是否仍正常，以及重新获取订阅后的结果。不要提交密码或完整订阅地址。若涉及订单，只需说明面板显示的订单状态与预期不一致。支持人员需要核对的是账户归属和订阅状态，不需要获取你的私密凭据。

什么时候找客服，以及工单应附哪些信息

这些情况适合直接提交工单

完成基础对照后仍无法定位，或者问题明显涉及账户、订单、订阅生成和多条线路共同异常，就应提交工单。典型情况包括：面板显示的套餐或流量与实际订单不一致；重新获取订阅后仍出现认证错误；多个受支持平台、不同网络入口和多条线路同时失败；同一条线路持续出现可复现错误；客户端日志显示明确的服务端响应；VPNRZ 面板出现与同时在线不限台数不一致的限制提示。

若只有一个浏览器扩展失效、目标应用自己的账户提示受限、基础网络本身断开，通常应先在对应产品或网络环境处理。支持人员可以协助判断线路与订阅，但无法修改第三方应用账户或不属于本服务的网络设备。把问题边界说清楚，反而能更快确认应该由哪一方处理。

工单标题写症状与范围

标题不要只写“不能用”“很慢”或“急”。更有效的结构是“平台 + 症状 + 影响范围”，例如“Windows 客户端多条线路连接超时”“iOS 锁屏后连接中断”“订阅更新返回解析错误”“规则模式下某应用无法访问”。标题先让支持人员知道故障层级，正文再给复现过程。避免把多个无关问题塞进同一标题；账户状态与应用分流若同时存在，分开描述更容易跟踪。

正文先写预期结果，再写实际结果。预期结果是连接后普通网页与目标应用均可访问；实际结果则要精确到客户端状态、错误原文和影响对象。随后列出已执行的对照：换过哪些线路类型、换网络入口是否恢复、其他设备是否正常、普通网页与目标应用的结果是否一致。不要只写“什么都试过了”，因为支持人员无法知道“什么”具体包含哪些操作。

保留足够上下文，同时隐藏敏感内容

截图应包含客户端名称、线路名称、状态和完整错误，但要遮盖用户名、订阅令牌、订单识别信息以及其他私人内容。日志截取错误发生前后的一段，不要只保留最后一句，也不要上传与问题无关的完整系统资料。命令行输出可以直接复制文本，便于检索；若包含本地用户名或目录，可在不破坏错误上下文的前提下遮盖。

订阅地址和密码不应写进工单正文。支持人员若需要核对账户，通常可以通过已登录面板中的工单关联关系完成。账户无法登录时，也只需提供用户名和错误现象，不要主动提交密码。VPNRZ 注册无需邮箱地址，用户名加密码即可注册，因此用户名是找回排查上下文的重要线索，应准确填写但不应在公开页面展示。

如何描述一个可复现过程

复现过程应从一个已知状态开始，例如“基础网络正常，客户端处于断开状态”。随后写执行动作：“选择某条线路并连接”“打开普通网页”“启动目标应用”。最后写观察结果：“客户端显示已连接，普通网页正常，目标应用一直等待”。这样的顺序让支持人员能够在相似条件下复查。若问题不是每次发生，写明触发条件，例如锁屏后、网络切换后、更新订阅后或晚高峰出现。

不要用未经确认的原因替代现象。写“线路服务器坏了”不如写“该线路连接超时，另一条线路正常”；写“DNS 污染”不如写“域名解析命令超时，直接连接测试有响应”；写“被限速”不如写“普通时段正常，晚高峰持续传输下降，换网络入口后恢复”。克制的描述不是少写，而是把事实和推测分开。

收到回复后的复验方式

支持人员给出线路、配置或客户端建议后，先回到原始基线复验。只执行回复中要求的变更，不要同时叠加其他网上找到的设置。复验成功时，回复说明哪一步后恢复、原问题是否仍能复现；复验失败时，提供新日志与新错误，不要重复贴旧截图。这样工单会形成清晰的变化链，后续处理无需从头询问。

账户或付款争议应保留面板订单状态。VPNRZ 支持支付宝 / 微信 / USDT，并提供 60 天无理由退款；具体请求通过用户面板工单提交。工单中说明需要核对的订单和当前状态即可，不要在公开渠道展示支付凭据。需要了解套餐内容时先查看套餐价格，避免把月订阅重置规则、流量包永久不过期和中途升级折算混为一项。

系统排查的终点不是把所有设置改一遍，而是得到一个边界清楚的结论：问题跟随账户、设备、网络、线路、时间段、DNS、客户端配置或目标应用中的哪一项变化。能在本地解决的，就保留有效设置并记录原因；需要支持介入的，就把最小复现路径交给工单。下一次出现相似症状时，从已建立的基线开始，不必重复整套高影响操作。