VPN 故障
排查手册

先确认连接失败发生在哪里

“连不上”不是一个足够明确的判断。客户端无法登录、订阅列表为空、线路连接超时，以及连接后网页报错，处在不同环节。先记录界面停在哪一步，保留错误原文，再关闭代理，用浏览器打开平时能够直接访问的网站。如果此时也打不开，应先处理无线网络、网线、路由器或网络认证；更换国际线路无法修复设备本身没有联网的问题。

公共无线网络可能要求在浏览器完成入口认证。系统显示已接入无线网络，只能说明设备与接入点建立了连接，不能证明外部访问已获放行。先断开代理，再打开浏览器查看是否出现网络使用提示。完成合法的网络接入流程后重新连接。若是单位或学校管理的网络，应遵守其使用规定，不要擅自修改受管理的网络配置。

用交叉检查缩小范围

基础访问正常后，检查客户端是否已取得系统要求的网络权限，账户页面是否显示有效套餐和剩余流量。随后在同一设备、同一网络下换一条线路，保留其它设置。如果只有原线路失败，问题更接近线路或到该线路的路径；如果所有线路都失败，再用同一设备切换到另一个获准使用的网络。这样得到的差异，比连续重启客户端更有定位价值。

再观察另一台设备在原网络下能否连接。另一台设备正常而当前设备失败，优先检查当前设备的系统代理、虚拟网络接口和安全软件提示；所有设备在原网络失败，换网络后恢复，则更接近接入网络问题。交叉检查不要求把所有设备改成相同配置，只需注明各自使用的客户端和线路，避免把配置差异误当成网络差异。

检查客户端接管与冲突

同时运行的代理工具、企业接入软件或带网络过滤功能的应用，可能争用系统代理或路由。先退出其它网络接管工具，再启动准备使用的客户端，确认系统没有残留指向已退出程序的代理设置。不要直接删除虚拟网卡、系统证书或全部网络配置；这些操作可能影响工作软件。需要调整安全软件时，只依据明确拦截记录处理，并在测试后恢复原有保护。

系统时间明显不准也可能影响加密连接和证书校验。检查日期、时区与自动校时状态，再观察报错是否改变。如果出现证书不受信任，不要通过忽略证书错误来强行继续，更不要安装来源不明的证书。先确认客户端来自用户面板的客户端入口，并保留证书提示的文字，交由支持人员判断。

连接恢复后，不要立刻导入更多配置或切回全部旧设置。先用当前可用组合打开目标应用，再逐项恢复原来的网络工具。若某个工具恢复后问题重现，就保留这一对照结果。后续章节中的网页、速度和分流检查，都应以基础连接已经成立为前提；否则容易在错误的层级反复调整。

先看报错，不先改 DNS 地址

客户端显示已连接，通常表示某个连接环节成立，不代表所有应用都已走正确路径。网页提示找不到服务器、连接超时、证书错误或访问被拒绝，含义并不相同。先记下地址栏中的完整域名与浏览器错误文字，再比较另一个网站、另一个浏览器是否正常。如果只有目标站点异常，应继续检查站点状态、应用规则或账户限制，而不是立刻重置整个网络。

DNS 的作用是把域名转换为可连接的地址。解析失败时，后续连接可能根本没有开始；但解析成功也不保证地址对应的服务能够到达。浏览器缓存、浏览器自身的安全 DNS、系统解析器以及客户端的解析设置，可能形成不同路径。因此，系统命令得到地址、浏览器仍打不开，并不矛盾。检查时要同时记录使用了哪个解析入口，而不是只抄下一个地址。

用系统工具观察解析结果

Windows 可以在命令提示符使用下面的查询命令；macOS 与 Linux 也可在终端尝试，具体取决于系统是否提供该工具。示例使用公开的教学域名，不需要账户信息。观察是否返回解析结果、是否超时，以及输出中的服务器名称。不要把结果中的某个地址永久写入配置，因为网站地址可能调整，固定地址也可能破坏证书或区域判断。

nslookup example.com

如果系统有 curl，可以继续检查请求是否到达响应阶段。下面命令只读取响应头；返回重定向或拒绝响应，仍说明某些连接环节已经完成。命令行工具不一定继承客户端的所有代理方式，因此结果必须结合客户端模式解释。命令行正常不能单独证明浏览器正常，命令行失败也不能单独证明线路失效。

curl --head https://example.com

按解析路径逐项恢复

先记录浏览器安全 DNS 与系统私人解析设置，再临时恢复为系统或客户端建议的默认方式，只改当前正在验证的一处。重新打开浏览器后测试同一域名。如果恢复正常，说明原来的解析路径值得进一步检查，而不是证明某个公共解析服务一定有问题。受管理设备上的 DNS 设置应交由管理员处理，不要强行覆盖组织下发的策略。

若系统查询仍返回明显陈旧的结果，可在确认设置正确后刷新本地缓存。Windows 的 ipconfig /flushdns 只处理本地解析缓存，并不会修复远端线路，也不会清除浏览器内的所有缓存。其它平台的处理方式随系统而异，优先重新连接网络或重启目标应用，不照抄不明来源的管理员命令。每次处理后都重新查询，保留变化前后的结果。

如果只有某个域名持续失败，工单应包含域名、报错类型、发生时段和解析检查结论。公开交流时遮盖个人信息，不必提交完整浏览记录。更完整的出口与分应用验证方法，可参阅连接后如何确认生效。验证的重点是把每个应用的实际结果对应到当前配置，而不是仅凭连接图标作结论。

把“慢”描述成具体任务

网页首屏迟迟不出现、视频播放中反复缓冲、下载传输不连续，以及远程会议声音中断，是不同的性能现象。先固定一个能够重复的任务，记录什么时候开始变慢、是否持续、是否影响所有应用。不要同时打开多个测速页面和下载任务；测试本身会争用网络，使结果失去可比性。线路名称相同也不等于每次访问都经过完全一致的外部路径。

先暂停当前设备的云同步、系统更新与大文件传输，再查看家庭网络是否有其它设备占用连接。无线信号质量和接入点距离会影响体验，切换国际线路并不能改善设备到路由器的无线干扰。条件允许时，在同一位置比较有线与无线，或在另一张获准使用的网络下重复任务。对照时保留应用、文件或播放内容，避免同时改变太多条件。

比较线路类型，而不是只看地区

同一地区可能存在不同路径。优先在当前访问场景下比较可用的线路类型，再考虑更换地区。IEPL 专线、中转和直连描述的是路径组织方式，不是对每个应用速度的统一排序。地理位置更近的出口，也可能因为本地接入、外部互联或目标站点调度而表现不同。线路选择以实际任务的完成情况为准，不能仅凭名称判断。

晚高峰检查要留下时段对照

晚高峰才出现的问题，需要与其它时段比较，但比较对象应保持一致。记录同一设备、网络、线路和应用在不同时间的表现，再检查是否所有线路同步变慢。如果只在原接入网络出现，更应关注本地运营网络与共享带宽；如果某条线路在不同网络都重复出现异常，则把该线路和发生时间提交支持人员。不要把“晚上慢”直接等同于套餐不足。

套餐流量表示可用的数据用量，不应被解释成未经说明的固定速度等级。先在账户中核对剩余流量与套餐状态，再判断是否需要调整用量。VPNSweet 月订阅流量按开通日每月重置，中途升级差价折算成剩余天数；具体价格与流量见套餐页。为了修复偶发缓冲而直接升级，可能没有触及真正的故障原因。

视频应用还可能根据内容来源、出口地区和历史缓存选择不同的分发路径。比较时保持同一内容与画质设置，先等待应用完成当前加载，再观察是否持续缓冲。AI 工具则可能在请求开始后长时间等待服务端处理，这与线路传输慢不是同一个概念。若普通网页正常而某项任务迟迟无响应，应记录该应用的具体阶段，而不是笼统描述为网络慢。

只有在本地争用排除、任务可复现、换线路确有差异之后，线路比较才有意义。提交性能工单时，写清影响的是页面打开、持续传输还是应用等待，并附对照条件。若问题没有复现，也应记录恢复时使用的网络和路径，为再次发生时保留基线。

先找断线触发条件

断线若总发生在锁屏、切换无线网络、离开接入点或设备唤醒之后，优先检查系统行为，而不是立即判断线路不稳定。记录断线前的操作、客户端是否仍在运行、系统网络图标是否变化，以及重新打开应用后是否自行恢复。前台持续使用也会断线，与只有后台才断线，属于不同问题，应分开描述和验证。

网络从一种接入方式切换到另一种时，设备的地址与路由可能改变，原连接未必能够原样延续。此时短暂中断不能单独证明账户或订阅有问题。先等待系统完成网络切换，再让客户端重新建立连接；不要在网络尚未稳定时连续点击连接开关。如果切换完成后仍无法恢复，回到基础网络检查，确认新网络本身已经能够访问。

检查平台对后台网络的管理

Android 的电池管理、后台运行与应用休眠策略可能影响持续连接。进入系统设置中该客户端的应用信息，查看是否允许必要的后台活动，再根据设备提供的选项调整。不同设备的菜单名称并不一致，不需要寻找某个固定标签。只调整目标客户端，避免把所有应用都设为无限制；测试完成后记录哪项设置改变了结果。

iOS 应先查看系统中的 VPN 状态与客户端内的连接状态是否一致，再检查是否存在其它正在接管网络的配置。不要认为把应用留在最近使用列表就一定能维持连接，也不要套用其它平台的电池设置说明。如果问题只发生在锁屏后，记录锁屏前后的网络类型、再次打开客户端时的状态，以及是否需要手动重连，这些信息比反复清理应用更有帮助。

持续断线时再比较线路

如果设备保持前台、基础网络没有切换，仍出现反复断线，可在保留其它条件的情况下改用另一条线路。原线路失败而替代线路稳定，说明值得进一步检查原路径；所有线路都在同样操作后中断，则继续关注本地系统与网络。不要同时修改后台权限和更换线路，否则即使恢复，也无法判断究竟是哪项调整起作用。

桌面端应特别留意休眠唤醒后的系统代理残留。客户端已经退出但系统仍把请求发送给本地代理时，浏览器可能表现为完全离线。先用客户端正常停止代理并退出，再检查系统代理状态，确认没有保留失效入口。Linux 用户还应区分桌面环境代理与终端进程继承的代理变量；它们未必会在客户端退出时同步更新。

需要支持介入时，提供触发动作和恢复方式，例如“锁屏后失败，回到前台仍需手动重连”，而不是只写“经常掉”。日志只截取对应故障时段并先脱敏。恢复后用相同的锁屏、唤醒或切网动作复验，确认不是刚好避开了原来的触发条件。

更新失败不等于原配置立刻失效

订阅更新是客户端获取配置的过程，线路连接是使用已有配置建立网络连接的过程，两者可以分别成功或失败。若旧配置仍能使用，先保留它，不要因为更新提示报错就删除全部配置。记录更新时显示的是超时、下载失败、解析失败还是账户状态提示，再检查用户面板是否能够正常打开。这些不同阶段决定了下一步应查网络还是配置内容。

先进入账户概览核对套餐状态与剩余流量。月订阅流量按开通日每月重置，不应把自然月开始当成统一重置时间。流量包用完为止、永久不过期，仍需核对实际余量。付款记录存在、页面状态尚未确认时，先查看账户中的订单与套餐结果，不要为了排查反复创建订单，也不要把支付页面截图直接当成配置已生效的证明。

核对来源与导入过程

订阅信息应从用户面板获取，通过面板提供的客户端流程使用。复制过程中若多出空格、换行或其它文字，可能导致客户端读取失败。不要在公开聊天、在线格式校验网站或陌生转换工具里粘贴订阅内容。订阅地址可能包含访问凭据，其敏感程度不低于账户信息；排查截图时也要遮盖二维码和完整链接。

如果客户端提示配置格式无法识别，先确认当前使用的导入方式是否与该客户端匹配。浏览器能打开某个地址，不代表返回内容适合当前客户端。不要凭文件后缀改格式，也不要把网页错误内容当成订阅配置保存。返回页面若是登录提示、网络认证提示或服务错误，应先解决获取过程，而不是逐行修改配置内容来掩盖问题。

把更新路径与代理路径分开测试

某些客户端的更新请求可能跟随当前代理路径，也可能使用独立的获取方式，具体以客户端设置为准。若正在使用的线路已失效，更新过程可能因此一并失败。确认基础网络正常后，尝试按客户端提供的正常方式停止当前代理，再执行更新；如果旧配置还有其它可用线路，也可先切换到可用路径后重新获取。不要连续快速刷新，以免把暂时错误和重复请求混在一起。

更新成功后，先查看配置是否实际切换到新获取的内容。部分客户端允许保存多个配置，列表出现新条目不代表它已成为当前使用项。核对当前配置名称、线路列表与选择状态，再连接目标线路验证。如果新配置异常而旧配置仍可用，可以保留旧配置作为临时对照，同时向支持人员说明新旧配置的表现，不必反复覆盖。

若怀疑订阅信息曾被公开，应在面板提供相关管理功能时进行更新，并重新导入自己使用的设备；没有明确入口时，通过工单咨询处理方式。不要为了方便多人共用而把访问凭据放到公共文档。账户无需邮箱地址，使用用户名和密码即可创建，因此也应妥善保管用户名与密码，不依赖未确认的找回方式。

适合提交更新工单的情况，是面板状态正常、来源正确、基础网络可用，但同一更新步骤持续失败。附客户端名称、系统平台、错误原文和已尝试的获取方式；若连接仍可用，也要明确说明。需要回顾标准导入流程时，返回新手指引逐步核对，而不是从陌生页面寻找替代订阅入口。

系统代理并不覆盖所有程序

浏览器访问正常而目标 App 失败，首先说明基础连接可能已经成立，不应立刻删除订阅。系统代理是系统向应用提供的一种网络设置，应用是否采用它取决于自身实现；有些程序使用独立代理设置，有些后台进程在启动时读取配置，还有些连接需要客户端提供其它接管方式。因此，同一设备上不同应用出现不同结果，并不罕见。

先关闭目标应用及其相关后台进程，确认客户端已经连接，再重新启动应用。仅关闭窗口可能不会结束后台网络连接，原来的失败状态也可能被保留。如果应用本身有代理设置，检查它是否指向旧工具留下的本地入口。不要直接套用网上的端口值；应以当前客户端显示的本地代理信息为准，并在变更前记录原设置。

用临时对照定位规则问题

客户端若提供规则模式与其它接管模式，可以临时比较目标应用的访问结果，但应明确这是诊断步骤，不是要求长期改变所有流量路径。在其它条件不变时，某种模式恢复而规则模式失败，值得检查该应用涉及的域名与规则归类。若各种模式均失败，则继续检查应用自身的认证、网络协议、账户地区或服务状态。

一个应用可能同时访问登录、接口、静态资源和文件传输等不同服务。只调整界面上看到的主域名，未必能覆盖失败环节。通过客户端提供的连接信息观察目标应用实际请求了哪些域名，只保留与报错有关的条目。不要把全部连接都强行归到同一路径，也不要为方便而大范围禁用规则；这样容易让原本正常的本地服务受到影响。

区分终端、编辑器与浏览器

命令行、编辑器扩展和浏览器可能读取不同的代理来源。终端环境变量通常由启动环境传给进程，修改系统代理后，已有终端不一定同步更新；编辑器中的扩展也可能运行在独立进程。先确认出现问题的是编辑器界面、扩展请求还是终端命令，再分别重启对应进程。远程开发场景中的请求还可能发生在远端机器，不能用本地浏览器正常作为远端网络正常的证据。

对 ChatGPT、Cursor 等 AI 工具，应区分页面打不开、登录失败、请求等待和服务端拒绝。线路能连通并不代表第三方账户权限、地区政策或服务额度满足要求。记录错误类型和发生阶段，再查看AI 专题中的访问说明。流媒体也应把网页访问与内容播放分开，第三方内容目录和访问政策不能由连接状态单独保证。

若应用使用的连接方式无法被当前模式接管，优先查看客户端的说明，不随意启用未知驱动或执行管理员脚本。受管理的工作应用应先咨询管理员。每项临时调整都应能撤回；确认规则问题后，把应用名称、失败环节、模式对照结果交给支持人员，避免只提交“这个软件不支持”的结论。

修复后的验证应覆盖登录、主要功能与后台请求，而不仅是启动页面。若原本正常的应用受到影响，恢复临时接管方式后重新检查。最终保留满足实际任务的最小调整，让规则、系统代理和应用设置各自承担清楚的职责，而不是依赖所有流量长期走同一出口。

“设备数超限”先看提示来源

VPNSweet 同时在线不限台数。如果看到设备数超限，先记录提示来自客户端、用户面板还是正在访问的第三方应用，不要直接把它解释为 VPNSweet 的设备限制。第三方网站自身的登录设备限制，与网络订阅服务是不同的规则；客户端也可能同时保存其它服务的配置。核对当前账户与当前配置，确认没有把旧订阅的提示带入本次判断。

若提示确实来自 VPNSweet 面板或当前服务配置，先截图保留原文并提交工单核查，不需要为了消除提示删除其它设备。不限台数也不意味着各设备拥有独立的套餐流量，使用量仍按所选套餐计算。设备增加后，如果多个应用同时进行大量传输，剩余流量变化与本地网络争用都可能更明显，应分别检查，不能把它们称为设备超限。

核对套餐、余量与重置方式

账户概览应与当前使用的订阅对应。月订阅为 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB，流量按开通日每月重置。先查看账户页面的实际状态，再决定是否需要调整套餐；不要凭记忆推算流量已经恢复，也不要把当前连接失败自动归因于用量。中途升级差价折算成剩余天数，具体操作应在面板中完成。

流量包为 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止、永久不过期。永久不过期描述的是流量包的使用方式，不表示用量不会减少。若无法确认当前账户使用的是月订阅还是流量包，先对照完整套餐说明和账户状态，再向支持人员说明疑问。不要在缺少账户信息时猜测计费或重置故障。

把登录问题与网络问题分开

无法登录面板时，先核对用户名输入、键盘布局和密码管理器填充的账户。不要把密码复制到公开记事服务，也不要为了排查把密码发给支持人员。无需邮箱地址是账户创建的信任点，但也意味着不能默认存在基于邮箱的恢复流程。应以面板实际提供的入口为准，无法确认时通过正式支持渠道咨询。

如果面板能够登录，但客户端中的配置属于另一个账户，账户页面显示正常也不能证明当前配置正常。检查配置来源与导入时间，必要时从当前账户重新获取并保留旧配置作为对照。多人轮流操作同一设备时，更应记录当前配置名称，避免把“面板账户”和“客户端配置”视为始终自动同步。清除浏览器登录状态之前，先确认自己仍掌握正确的登录资料。

支付方式支持支付宝、微信、USDT。支付结果存在疑问时，保留面板内对应订单状态和必要的付款凭证，在工单中沟通，不公开展示完整付款信息。不要因网络报错反复付款，也不要依据外部聊天中的个人收款说明处理订单。连接故障与订单状态应分别记录，只有确认关联后再合并判断。

VPNSweet 提供 14 天无理由退款。需要了解处理方式时，可阅读退款政策并通过面板提交申请；排查与退款咨询可以清楚表达各自诉求，不必把所有设置尝试一遍才能说明问题。账户异常工单应写明看到的状态、预期状态与相关操作，避免只凭“设备太多”这样的推测给故障定性。

什么情况适合停止自行调整

基础网络正常、账户状态明确，换线路或换网络后仍能重复触发相同错误，就适合提交工单。如果出现证书异常、疑似凭据泄露、账户状态与套餐说明不一致，或者设备受到组织管理，也应停止尝试高风险修改。排查的目标是缩小范围，不是穷尽所有网络设置；当下一步需要删除系统组件或改变安全策略时，先请求确认更稳妥。

从用户面板提交工单，把问题放在同一条沟通记录里持续补充。标题写症状与影响对象，例如“客户端可连接，浏览器出现解析错误”，正文写发生时间及所用时区、设备平台、客户端名称、当前线路与网络类型。客户端版本可按设备实际显示填写，不需要猜测，也不要把网上教程的版本当成自己正在使用的版本。

提交能被复现的检查记录

描述顺序可以是：原来进行什么任务，在哪个环节失败，错误原文是什么，已经做过哪些单项对照，最后停在哪个配置。比如说明同一设备换网络是否恢复、同一网络换线路是否恢复，以及其它应用是否受影响。没有做过的检查写“未验证”，不要为了让记录完整而填猜测结果。明确的不确定信息同样有价值，可以避免支持人员把推测当作事实。

截图优先截取错误区域与必要的状态栏，不必提交整张桌面。日志优先选择故障发生前后的相关片段，不发送全部历史连接记录。遮盖订阅地址、二维码、密码、会话信息、私人文件路径与无关内容。线路名称和错误类别可以保留，账户定位资料仅通过正式面板提供；不要把登录凭据当成客服排查所必需的材料。

收到建议后仍保持单项变更

支持人员提出调整时，先确认它对应哪个判断，再按建议执行并记录结果。如果建议涉及清除配置，先确认备份与恢复方式；涉及账户操作，先核对当前登录账户；涉及系统权限，先了解它影响的范围。每次反馈说明“做了什么、错误是否变化、原任务是否完成”，比只回复“还是不行”更能推动下一步定位。

问题恢复后，先重复原来的失败动作，而不是换一个更容易成功的测试。网页问题检查原域名，后台问题检查锁屏与唤醒，订阅问题检查实际更新和配置选用，应用问题检查原来的功能环节。随后恢复为日常使用的分流方式，并确认本地服务没有受到临时设置影响。恢复连接与恢复原任务是两个层次，应分别验证。

留下可用基线，而不是堆积修复设置

整理最终保留的配置，撤回没有证明有效的临时调整，删除自己不再需要的诊断副本。保存一份简短基线，包含可用网络、客户端、线路类型和必要设置，不记录密码或订阅凭据。若以后再次出现问题，先对比基线中哪项发生变化，就不必从重装开始。无法稳定复现时，也可以把偶发时段和触发动作继续补充到原工单。

线路覆盖为 110+ 国家 / 250+ 线路，但排查不需要逐条尝试。选择能够形成清楚对照的可用路径，通常比漫无目的切换更有帮助。常规问题可继续查看FAQ；首次安装回到新手指引；需要检查访问是否真实生效，可阅读出口、DNS 与分应用验证文章。把记录留在正确的层级，后续处理才不会反复绕回起点。