跨境连接排查手册

先记录现象，不要连续切换所有设置

完全连不上时，最容易出现的误区是同时更换线路、协议模式、系统权限和客户端配置。改动一多，即使偶然恢复，也无法知道真正起作用的是哪一项。应先保留当前页面，记下客户端显示的状态文字：是一直等待、主动超时、权限被拒绝，还是建立后马上结束。随后确认普通网页在未开启连接时能否访问。如果本地网络本身已经断开，继续调整线路不会带来有效结果。

接着判断问题是“所有线路都失败”还是“只有当前线路失败”。从服务器页面选择另一个邻近地区，不要连续遍历整张列表。若更换线路后恢复，说明客户端、订阅和系统权限大体可用，问题应收敛到原线路或当前网络到该线路的路径；若所有线路表现一致，则优先检查订阅是否过期、客户端是否读取到节点、系统是否允许创建网络连接，以及本地网络是否对相关流量作了限制。

检查订阅是否真正加载

客户端能打开并不等于订阅已加载。线路列表为空、只剩旧线路、线路名称与用户面板不一致，都说明应先处理订阅而不是连接本身。进入客户端的订阅或配置页面，确认当前选中的配置来自 VPNTea 用户面板，并执行一次更新。不要删除所有配置后再尝试，因为原始错误信息往往会随删除操作一起消失。若更新失败，保留提示文字，转到本手册“订阅更新失败”章节继续判断。

如果线路存在但点击后立刻结束，检查操作系统是否弹出过网络配置授权。首次导入或系统更新后，授权可能需要重新确认。Windows、macOS、iOS、Android 与 Linux 的入口名称不同，但判断标准一致：客户端必须能够创建系统网络接口或写入系统代理设置。权限被拒绝时，客户端内部的线路再正常也无法接管流量。企业管理设备还可能由管理策略控制网络配置，这类限制应由设备管理方确认，而不是反复安装客户端。

用最小环境排除本地冲突

同一时间只保留一个负责系统网络接管的客户端。其他网络过滤工具、旧的加速客户端、手工代理、浏览器独立代理扩展与安全软件中的网络检查功能，都可能争用系统代理或路由。退出这些程序后，应重新打开 VPNTea 客户端再测试，而不是只把窗口最小化。某些程序关闭窗口后仍留在后台，需从任务区域或系统活动列表确认其进程已经结束。

然后在当前网络与另一种可信网络之间做对照。如果同一设备、同一订阅、同一线路只在某个网络下失败，问题边界已经落到接入网络；如果换网络仍失败，但另一台设备可以正常连接，则问题位于原设备的权限、网络栈或客户端状态；如果不同设备和不同网络均失败，再考虑账号状态、订阅状态或线路侧问题。这个矩阵比单纯“重启再试”更有信息量。

何时停止本地尝试

已经确认普通网络可用、订阅能更新、系统权限有效，并在不同网络和不同线路上得到同样失败结果时，不建议继续重复卸载。此时应提交工单，并附上客户端状态、错误原文、系统平台、所选线路、问题开始前的最后一次正常使用场景，以及是否所有线路都受影响。若只有单条线路失败，则直接说明可用线路与失败线路的名称，客服可以更快区分线路问题与账户问题。

先判断是单个网站还是所有网站

已连接但网页打不开时，先访问几个性质不同的常用网站。若只有一个网站失败，问题可能是目标服务自身状态、地区策略、浏览器缓存或该域名的规则匹配；若所有域名都失败，则应优先检查 DNS、系统代理和默认路由。不要把单一网站的错误直接归因于整条线路，也不要用同一网站的多个页面作对照，因为它们通常共享相同域名和网络入口。

再比较浏览器与其他联网应用。如果浏览器失败而其他应用正常，检查浏览器是否启用了独立的安全 DNS、代理扩展或自定义网络设置；如果所有应用都失败，问题更可能位于系统级网络配置。浏览器扩展会绕开客户端设定的规则，尤其是在扩展中保存过旧代理地址时。排查时可暂时使用没有额外扩展的浏览器窗口，但不要清空全部浏览数据，先保留可观察的错误页面和域名。

用域名解析测试定位 DNS

DNS 的作用是把域名转换为可连接的网络地址。客户端已连接，但域名解析仍交给不可用或返回异常结果的解析器时，网页会表现为长时间等待、找不到服务器，或者同一网站时好时坏。可以在系统终端执行以下中性测试，示例域名不会包含任何真实订阅信息：

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

若域名查询没有返回结果，而客户端日志显示连接仍在，重点检查客户端的 DNS 接管选项、系统中残留的手工 DNS、浏览器独立 DNS 与其他网络过滤程序。若查询可以返回，但网页请求失败，则更像是路由、规则或目标服务问题。命令结果不需要逐字理解，保留输出即可；提交工单时，解析是否成功比粘贴大量无关日志更有价值。

检查规则模式是否把流量送错方向

规则模式会根据域名、网络地址或应用决定直连还是通过线路。规则未更新、域名被错误归类，或目标服务改用了新的域名，都可能造成“连接正常但页面打不开”。排查时可临时切换到全局模式做一次对照：如果全局模式可用而规则模式失败，线路本身通常没有问题，应更新订阅与规则，并检查是否存在自定义覆盖；如果两种模式都失败，则继续检查 DNS、线路和本地网络。

全局模式只用于定位，不必把它当成长期解决办法。长期使用时仍应按照实际场景选择合适模式，避免不需要加速的本地流量也改变路径。若只有某个应用失败，转到“某个 App 走不了代理”章节，重点检查应用是否使用独立网络栈、是否命中分应用排除项，以及客户端是否有该应用的单独规则。

处理缓存与系统残留时保持可回退

切换 DNS 或规则后，旧解析结果可能仍被系统、浏览器或应用保留。最稳妥的顺序是先完全退出受影响应用，再断开连接，重新建立连接后打开应用复测。必要时再重启设备，让系统网络状态回到一致起点。不要一开始就执行来源不明的网络重置脚本，因为它可能同时清除无线网络、企业配置和其他必要设置，增加新的变量。

如果手工设置过系统代理，应记录原值后再改为自动管理。排查结束后确认没有遗留无效代理地址。Linux 环境还要注意终端中的代理环境变量与桌面系统代理可能彼此独立：图形应用正常而命令行失败，或反过来，都可能由两套设置不一致造成。此时应检查当前终端会话是否继承了旧变量，而不是直接判断线路不可用。

DNS 异常需要提交哪些信息

若不同线路下均出现相同解析失败，但切换网络后恢复，应说明接入网络类型与解析命令结果；若只有某条线路发生，应附线路名称、失败域名和全局模式对照结果；若浏览器与其他应用表现不同，应写明受影响应用以及是否启用了独立 DNS。不要提交账号密码、订阅完整内容或包含认证参数的截图。客服需要的是可复现条件，不是账户凭据。

先定义“慢”发生在哪个阶段

网页慢可能表现为域名解析等待、页面首个内容迟迟不出现，或页面打开后图片加载缓慢；视频慢可能是起播等待、清晰度下降或播放中缓冲；AI 工具慢则可能是页面能开但响应中断。不同现象依赖的网络环节不同，不能只用一次测速结果替代真实场景。排查时先写下受影响应用、具体操作和发生时段，再比较同一线路下其他应用是否正常。

如果只有单个服务慢，先考虑目标服务入口、地区选择与规则匹配。若所有服务都慢，再检查接入网络质量、无线信号、后台下载与线路选择。家庭网络中的其他设备同步文件、更新应用或播放高码率内容，也会与当前设备竞争带宽。由于 VPNTea 支持不限台数，同时在线设备本身不是限制项，但多个设备同时传输仍会共享用户当前接入网络的实际能力。

建立可重复的线路对照

比较线路时，应保持设备、接入网络、目标服务和测试动作不变，只替换线路。优先选择地理位置较近或与目标服务所在地区相符的节点，不要只根据名称猜测快慢。专线、中转与直连的路径结构不同：专线更重视跨境段的稳定组织，中转会先进入优化入口再到目标地区，直连则更依赖本地运营网络与公网路径。三者没有脱离场景的绝对优劣。

服务器页面用于查看覆盖地区与线路类型，线路选择完整指南则按视频、游戏与 AI 工具等场景解释选择方法。排查性能问题时，建议从同地区的不同线路类型开始比较。若同地区线路表现接近，问题更可能来自本地接入或目标服务；若只有某种线路类型异常，可在工单中直接指出这一差异。

晚高峰卡顿要比较时间与网络

如果白天正常、晚间明显变慢，应在相同设备与相同应用下记录两个时段的表现，并比较另一种接入网络。晚高峰可能同时影响用户本地宽带、跨境入口和目标服务，单次测试无法确定瓶颈位置。若换到另一接入网络后恢复，问题更接近本地运营网络；若不同网络都只在固定线路上变慢，应改用同地区其他线路，并向客服提供线路名和发生时段。

不要只写“晚上很卡”。更有效的描述是：网页首开慢但后续正常、视频起播正常但中途缓冲、下载持续慢，或交互请求偶发超时。客服可以据此判断更像延迟波动、持续吞吐不足还是连接重传。若问题发生在体育直播等实时场景，可参考体育直播线路对比中的选择维度，但排查时仍以当前网络的对照结果为准。

排除设备侧性能与无线干扰

设备省电模式、温度过高、后台同步和安全软件实时扫描，都可能让加密连接处理能力下降。先关闭大文件同步与系统更新，保持设备供电状态稳定，再重复相同操作。使用无线网络时，信号图标满格也不代表链路没有干扰；在条件允许时靠近接入设备，或使用稳定的有线连接作对照。若只有一台较旧设备慢而其他设备正常，优先检查该设备资源占用与客户端运行状态。

分流规则也会影响观感。目标服务的页面资源可能来自多个域名，其中一部分走线路、另一部分直连，路径不一致会造成页面主体出现而图片或视频迟迟不加载。临时使用全局模式对照可以帮助确认这一点。如果全局模式明显改善，应更新订阅规则并撤销冲突的自定义规则，而不是长期依靠不断切换线路。

性能工单的停止条件

当不同设备在同一网络下都慢，而切换网络后恢复，可先联系接入网络服务方；当不同网络下只有特定 VPNTea 线路持续异常，应提交线路工单；当所有线路只对单一目标服务异常，应提供目标服务名称、所选地区与规则模式。若流量已经用完，也会影响继续使用，应登录用户面板查看当前套餐状态。月订阅流量按开通日每月重置，流量包则用完为止、永久不过期，排查前应先确认当前可用流量来源。

区分主动断开与会话失效

频繁断线首先要看客户端状态。如果客户端明确回到未连接，说明系统或客户端结束了会话；如果客户端仍显示已连接，但应用不再联网，则更像是路由、DNS 或连接会话已经失效。两者需要不同处理。前者检查省电、后台权限和网络切换，后者可先断开再连接，并比较是否只发生在特定线路。

记录断线前发生的动作很重要：设备是否从无线网络切到移动网络、是否锁屏、是否进入省电模式、是否打开另一个网络工具、是否从一个地区移动到另一个地区。网络切换会改变本地地址与路由，原有会话可能无法继续；锁屏后系统可能暂停后台任务；安全软件或系统清理功能则可能直接结束客户端进程。只写“随机断线”会丢失这些触发线索。

移动端先检查后台运行条件

在 iOS 与 Android 上，系统会根据电量、内存与后台策略管理应用。应确认 VPNTea 客户端具备维持网络配置所需的系统权限，并避免把它放入会主动休眠的应用类别。Android 厂商对省电入口的命名不同，通常可在应用信息、电池或后台活动设置中找到；iOS 则应确认系统网络配置仍存在，且没有其他网络配置同时争用。相关首次配置流程可查看iOS 订阅导入教程。

不要为了保活而关闭整台设备的所有省电功能。更稳妥的做法是只调整当前客户端，并观察锁屏、切换应用和网络变化时的表现。若前台持续正常、锁屏后才掉线，边界已经明确落到后台管理；若前台也会断线，则继续比较线路和接入网络。Android 用户还可参考安卓后台保活与分应用代理说明，逐项检查应用后台状态。

桌面端检查休眠、网络切换与进程冲突

Windows、macOS 与 Linux 在休眠或唤醒后，也可能保留表面连接状态，但底层网络接口已经变化。遇到唤醒后无法联网，应先断开并重新连接，而不是立刻删除订阅。如果每次休眠都复现，可记录系统平台、休眠前所选线路以及唤醒后的客户端状态。客户端升级或系统更新后首次出现的问题，也应把“更新前正常、更新后异常”作为变化点写入工单。

同时检查是否运行了其他会修改路由、代理或 DNS 的程序。开发环境中的容器网络、虚拟网络接口、远程办公客户端和安全过滤软件，都可能在启动时重新写入路由。若 VPNTea 在这些程序启动前正常、启动后断线，就应按启动顺序逐个对照。不要删除不熟悉的系统接口；先退出相关程序并重启客户端，确认冲突关系后再决定长期配置。

线路断开与本地网络抖动的区别

如果断线时普通网页在关闭连接后也无法访问，说明本地网络本身发生了中断。若本地网络始终正常，而某条线路持续断开，换同地区另一线路后恢复，则应报告原线路。如果所有线路在同一个接入网络下断开，但换网络正常，问题更接近当前接入环境。这个三方对照——本地网络、替代线路、替代接入网络——能避免把不同层的问题混在一起。

频繁断线期间不建议开启持续的大文件传输作为唯一测试，因为传输任务本身可能自动重试，掩盖准确断线时间。可以同时观察客户端状态和一个轻量网页请求，记下出现异常时哪个状态先变化。若日志中包含账户凭据或完整订阅内容，提交前应移除敏感部分；普通错误代码、时间与线路名称应保留。

提交断线问题时写清触发条件

工单中应说明前台还是后台发生、锁屏是否相关、网络切换是否相关、所有线路还是单条线路受影响、断线后客户端显示什么，以及重新连接能否恢复。移动端附系统平台和省电设置页面截图，桌面端附冲突程序是否退出的对照结果。若只有某个应用断流而其他应用正常，应转到分应用章节，不要按整条连接断线处理。

先确认订阅来自当前用户面板

订阅应从 VPNTea 用户面板获取，营销页面不会提供静态安装包或公开订阅地址。进入客户端的订阅管理页，核对配置名称和来源是否为当前账户。如果曾手工复制过多份配置，可能出现客户端正在更新旧配置、实际连接却使用另一份配置的情况。排查时保留当前配置，先确认哪一份处于启用状态，再处理重复项。

无需把完整订阅地址发送给客服，也不要在截图中展示其中的认证参数。只需说明从用户面板复制后，客户端返回的错误文字、更新发生的网络环境以及配置是否曾成功使用。若怀疑复制不完整，应回到面板重新获取，再通过客户端的标准导入入口添加，而不是手工修改地址结构。

分辨获取失败与解析失败

“无法下载订阅”和“订阅格式无法解析”是两个阶段。获取失败通常表现为网络错误、超时或访问被拒绝，说明客户端尚未拿到配置内容；解析失败则说明内容已经到达，但客户端无法识别、内容被截断或导入方式不匹配。保留错误原文可以直接区分这两个方向。不要把解析错误当成线路故障，因为此时连接过程尚未开始。

若是获取失败，先在关闭连接和开启连接两种状态下分别更新，并比较另一接入网络。某些网络环境对订阅请求与普通网页的处理不同。若只有当前网络失败，记录网络类型即可；若不同网络均失败，再检查账户套餐状态与订阅来源。若是解析失败，确认使用的是客户端支持的导入方式，并从面板重新获取，不要把网页内容复制进要求填写订阅链接的位置。

处理客户端缓存与重复配置

客户端可能保留上次成功更新的线路，因此“还能连接”与“更新成功”并不矛盾。查看线路名称是否与面板当前显示一致，如果长期停留在旧状态，应先执行刷新或重新选择订阅。只有确认当前配置可重新获取后，才考虑删除重复旧配置。直接全部删除会让原本可用的缓存也消失，增加恢复难度。

若客户端支持自动更新，排查阶段可暂时执行手动更新，以便看到即时错误。自动更新在后台失败时，提示可能被系统折叠，难以判断准确时间。手动更新成功后再恢复原计划。移动端还需确保客户端在更新期间没有被系统暂停；桌面端则检查系统代理或其他网络工具是否影响订阅请求。

套餐状态与流量来源的核对

登录用户面板查看当前套餐状态，不要只看客户端中的旧到期信息。月订阅有三个档位：¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按开通日每月重置，中途升级差价折算成剩余天数。流量包为¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止、永久不过期。排查时只需确认当前权益是否有效，不需要自行换算剩余周期。

若需要调整套餐，可前往定价页面查看完整说明。支付方式为支付宝、微信与 USDT。订阅更新异常与支付页面问题应分开描述：前者关注客户端获取配置，后者关注用户面板中的订单和套餐状态。把两者混在同一段“账号不能用”里，会增加判断成本。

何时重新导入，何时提交工单

如果同一订阅在另一台设备可以更新，原设备更可能存在客户端缓存、导入方式或网络设置问题，可在保留旧配置的前提下重新导入作对照。如果所有设备和不同网络都返回相同获取错误，应提交工单，并说明错误发生阶段。若只有某个客户端解析失败，而其他平台正常，则附客户端名称与错误原文，客服可判断是否属于格式兼容问题。

更新恢复后，应确认线路列表确实变化，并选择一条线路完成连接验证。只看到“更新成功”提示还不够，因为客户端可能更新了非当前配置。最后删除确认无用的重复项，让后续排查只面对单一订阅来源。保持配置结构简单，往往比频繁重装更能减少长期故障。

先证明问题只影响单个应用

保持当前线路不变，分别测试浏览器和另一个常用应用。若其他应用正常，说明订阅、线路和系统权限至少具备基本可用性，不应从完全重装开始。记录受影响应用在什么操作上失败：启动时无法登录、内容列表打不开、图片不加载，还是进入特定功能后超时。应用内部可能调用多个域名，某一功能失败不等于整个应用都没有经过连接。

再比较应用的网页版本。如果网页版本正常而客户端应用失败，重点检查分应用规则、应用缓存和独立网络设置；如果网页与应用都失败，则考虑目标服务地区、域名规则或线路。AI 工具场景还可参考ChatGPT 加速专题与AI API 固定出口与并发要求说明，但故障定位仍应先完成本地对照。

检查包含与排除逻辑

分应用代理通常有两种相反逻辑：只让选中的应用经过线路，或让选中的应用保持直连。界面文案相近时很容易选反。进入客户端的分应用设置，确认当前模式含义，再检查目标应用是否位于正确列表。应用更新后，系统中的应用标识可能变化，旧规则未必继续命中，因此问题若恰好从应用更新后开始，应重新选择一次目标应用。

排查时可暂时关闭分应用功能，让系统流量统一经过当前模式。如果应用随即恢复，线路本身通常正常，问题位于分应用选择或规则；如果仍失败，则继续比较全局模式和规则模式。完成对照后恢复原设置，不要让临时全局配置长期留在设备上。

规则模式下检查多域名资源

现代应用往往把登录、接口、图片、视频和更新分布在不同域名。主域名命中线路，但静态资源域名被判定为直连时，可能出现“能登录但页面空白”或“文字出现但图片加载失败”。临时切换到全局模式，若所有资源恢复，说明应更新订阅规则或检查自定义覆盖。不要只添加当前看到的一个域名，因为应用后续功能仍可能调用其他域名。

若应用提供内置代理设置，应避免与系统连接重复配置。应用内手工代理可能指向已经失效的本地端口，即使系统线路正常，该应用仍会独立失败。先记录原设置，再改为跟随系统网络作对照。开发工具、命令行和容器环境也可能读取单独的环境变量，它们不一定继承桌面客户端的系统代理。

目标地区与账户状态要分开判断

部分服务会根据出口地区展示不同内容。应用能联网但提示地区不可用时，不属于普通连接失败，应选择与目标内容相符的地区线路，并完全退出应用后重新打开。应用可能缓存先前地区，单纯在后台切换线路不一定刷新状态。若更换地区后仍只影响该服务，而其他网站正常，应记录服务名称、线路地区和提示原文。

目标服务自身的账户限制、登录状态或风控提示，也不能通过反复切换线路解决。先确认错误是否明确指向账号、支付或内容权限。如果是目标服务账户问题，应按该服务的官方流程处理；如果是网络超时、资源无法加载或地区识别不一致，再继续从线路和规则入手。把账户错误与网络错误分开，可以避免无意义地更改本地配置。

恢复后整理规则

问题解决后，应撤销排查期间添加的重复规则和临时全局设置，只保留能解释其用途的规则。长期叠加例外项会让后续流量路径难以预测。若需要多个应用采用不同路径，逐个加入并测试，不要一次批量选择全部应用。规则越清晰，下次应用更新或订阅变化时越容易判断差异。

先确认事实边界：服务不限台数

VPNTea 的同时在线设备数为不限台数，支持 Windows、macOS、iOS、Android 与 Linux。因此，某台设备无法连接时，不应先假设是套餐限制。更常见的情况是该设备使用了旧订阅、客户端缓存了过期账户状态、系统网络权限失效，或不同设备连接到不同配置。先登录用户面板确认当前套餐状态，再逐台核对订阅来源。

不限台数并不意味着所有设备会得到完全相同的网络表现。它们可能处于不同接入网络、使用不同客户端模式、选择不同地区线路，还可能运行不同的分流规则。排查跨设备差异时，要把“账户允许连接”与“设备本地是否配置正确”分开。只要另一台设备正常，就说明账户和至少一条线路可用，问题应优先落到异常设备。

建立设备对照表

为每台设备记录平台、接入网络、客户端中启用的订阅名称、所选线路和故障现象。不要把设备型号、系统平台和网络环境混为一个变量。例如，桌面设备使用家庭网络正常，移动设备使用另一网络失败，并不能直接说明平台兼容问题；应让两台设备尽量接入同一网络，并选择同一线路后再比较。

若同网络同线路下只有一台失败，检查该设备的网络权限、其他代理工具、分应用设置与系统时间。若两台都失败，但换线路后恢复，问题指向原线路；若同一设备换网络后恢复，则指向接入网络。通过这种交叉对照，可以避免在每台设备上重复做无关重置。

处理旧会话与重复订阅

设备更换、系统恢复或客户端迁移后，旧配置可能继续存在。先确认当前启用的订阅来自同一账户，不要依据相似名称判断。若客户端同时保存多份订阅，更新其中一份并不会自动更新另一份。可以给当前配置一个清晰名称，完成连接验证后再删除确认无用的旧副本。

若客户端显示账户或设备相关错误，应保留原文并重新登录用户面板确认状态。不要频繁修改用户名或密码来试探，因为这样会让其他设备同时失去有效会话，扩大问题范围。VPNTea 注册无需邮箱地址，用户名加密码即可注册，因此用户应自行妥善保存凭据；客服排查不需要获取密码，也不会要求在工单中提交密码。

平台差异不是线路差异

Windows 与 macOS 可能通过系统代理或网络扩展接管流量，iOS 与 Android 依赖系统网络配置，Linux 还可能存在桌面设置与命令行环境分离。相同订阅在不同平台上的选项名称和路由实现不完全相同，因此应比较最终现象，而不是要求界面逐项一致。某个平台缺少另一平台中的同名开关，不代表服务能力缺失。

如果只有 Linux 命令行失败但图形应用正常，检查终端环境变量；如果只有 Android 的某个应用失败，检查分应用选择；如果 iOS 在锁屏后异常，检查后台与系统配置；如果桌面端唤醒后异常，重新建立会话并检查网络接口。把平台特有问题带回对应章节，比按“设备太多”处理更准确。

什么时候应提交账户类工单

如果用户面板显示套餐有效，但不同平台、不同网络和不同线路都返回相同账户提示，应提交工单。附上用户名即可，不要附密码；同时说明提示发生在登录、订阅更新还是连接阶段。若只有一台设备出现，则先附该平台的客户端状态和对照设备结果。客服需要知道错误属于账户授权还是本地客户端状态，清晰的发生阶段比设备数量本身更关键。

若问题与套餐选择或升级有关，可先查看套餐价格与流量规则。月订阅升级差价折算成剩余天数，流量按开通日每月重置；流量包用完为止、永久不过期。不要自行把不同流量来源换算成设备额度，两者没有对应关系。

先用一段话描述故障

开头应直接写明平台、接入网络、线路、受影响应用和具体表现。例如：“Windows 上使用家庭网络，某地区线路可连接，但浏览器所有域名无法解析；更换另一网络后恢复。”这句话已经包含设备、环境、线路、症状与对照结果。相比“今天突然不能用了”，它能让客服直接进入 DNS 与接入网络方向。

若是性能问题，写清发生时段和应用动作；若是断线，写清触发条件与断线后客户端状态；若是订阅问题，写清获取失败还是解析失败；若是单个应用问题，写清全局模式与规则模式的差异。不要把多个不相关问题放进同一个长段落，可按症状分别列出，避免某个已解决问题掩盖另一个仍在发生的问题。

工单应附的诊断信息

• ✅ 系统平台与使用的客户端类型
• ✅ 接入网络类型，以及更换网络后的对照结果
• ✅ 线路名称、线路地区，以及是否所有线路都受影响
• ✅ 问题发生的具体操作与客户端状态文字
• ✅ 错误原文、必要截图与可复现的发生条件
• ✅ 最近是否更改订阅、系统网络设置、规则或应用配置
• ❌ 不提交密码、完整订阅地址、认证参数或配置全文

截图应包含足够上下文，但需遮住敏感内容。只截一个错误图标通常没有帮助，应尽量让截图同时显示页面标题、错误文字和当前线路。日志只截取故障发生前后相关片段，不要上传与问题无关的整份长期日志。若日志包含订阅内容，应先移除该部分。

怎样记录最近变化

许多故障都从某个变化点开始：系统更新、客户端重新导入、切换接入网络、修改分流规则、目标应用更新、设备进入新的管理策略，或套餐状态发生变化。变化点不等于故障原因，但它能显著缩小范围。写明“改动前正常、改动后异常”，并说明是否撤销改动后恢复。

如果想不起具体变化，不要猜。可以写“未主动修改配置”，再说明首次发现问题的场景。客服会根据线路状态、账户状态和错误信息继续判断。虚构一个看似合理的原因反而会让排查走偏。保持事实与推测分开：事实写观察到的现象，推测用“可能”标明，不要把推测当结论。

哪些情况应直接联系支持

不同设备、不同接入网络和不同线路都出现同样账户或订阅错误；用户面板状态与客户端状态明显不一致；单条线路持续无法连接而同地区其他线路正常；或已经完成本手册中的最小对照仍无法确定边界时，应提交工单。付款与套餐状态问题也应通过工单处理，并写明支付方式是支付宝、微信还是 USDT，但不要上传完整支付凭据。

若只是不会完成首次导入，应回到快速上手教程；若要比较地区与线路类型，应查看服务器页面；若要选择月订阅或流量包，应查看套餐页面。把使用问题送到对应资料页，能减少不必要的账户操作。VPNTea 覆盖 90+ 国家和 200+ 线路，排查时应先选择少量有代表性的线路对照，不需要遍历全部线路。

问题恢复后的收尾检查

恢复后不要立即结束排查。先重复原先会失败的动作，确认在相同条件下已经正常；再断开并重新连接，验证恢复不是一次性偶然结果；最后清理临时全局模式、重复订阅、自定义 DNS 和为排查关闭的必要安全设置。只保留确认有效的调整，并记录最终改动，方便以后复查。

如果问题自行消失，也应保留简短记录，特别是发生时段、线路与网络。偶发问题再次出现时，前后记录可以确认是否具有相同模式。对于晚高峰卡顿、网络切换后断线和特定应用资源加载失败，这种连续记录往往比单次截图更有判断价值。