VPN 故障排查大全

§ METHOD

故障排查的顺序与基线

先确定故障位于哪一层

网络连接不是一个单独开关，而是一条连续链路：设备先接入本地网络，客户端再读取订阅和线路参数，系统随后建立隧道并应用路由规则，DNS 负责把域名转换为地址，最后才由目标网站或 App 返回内容。任何一层异常，都可能在界面上表现为“打不开”。如果一开始同时更换线路、重装客户端、修改 DNS 和调整系统权限，故障即使暂时消失，也无法知道真正原因，之后往往还会重复出现。

正确方法是先建立基线。断开加速连接，确认普通网络能否打开常用网页；再连接一条此前可用的线路，只测试一个浏览器页面；随后检查其他网站、其他 App 和其他线路。这样可以把问题分成全局故障、单个线路故障、单个应用故障或单个目标服务故障。全局都失败时优先检查网络入口和客户端；只有某条线路失败时转向线路选择；只有某个 App 失败时检查分应用与系统路由；只有某个域名失败时检查 DNS、缓存和目标服务自身状态。

测试期间应固定设备、网络和客户端，不要在无线网络与有线网络之间来回切换，也不要让系统同时运行多个会修改网络路径的软件。浏览器扩展、系统代理、虚拟网卡、企业网络配置和安全软件都可能改变结果。排查的目标不是把所有组件一次清空，而是让链路尽量简单：一个设备、一种本地网络、一个客户端、一条线路、一个测试目标。基线成立后，再逐项恢复原来的使用环境。

记录现象，而不是只记录结论

“不能用”不足以定位问题。有效记录应包含故障发生在连接前还是连接后、客户端显示的状态、全部网站还是部分网站受影响、浏览器与其他 App 是否一致、切换线路后现象是否改变、断开连接后普通网络是否恢复。若出现错误提示，应保留完整原文，不要只截取最后一句。系统时间、当前网络类型、客户端平台、所选地区和复现路径也有诊断价值。

观察故障的边界比反复点击连接更重要。例如，域名打不开但直接访问已知地址可达，通常指向 DNS；浏览器正常而某个 App 无法访问，通常指向分应用规则或该 App 自带的网络栈；连接建立后所有流量都停止，可能是默认路由或虚拟网卡冲突；下载正常而交互操作延迟明显，则需要区分吞吐、往返响应和丢包，不应简单归类为“带宽不足”。

重启与重装应放在什么位置

重启适合清除短期状态，例如休眠后残留的虚拟网卡、未释放的网络接口或卡住的系统服务，但它不是诊断结论。重启后恢复，只能说明问题与临时状态有关，仍应记录此前是否发生网络切换、休眠或客户端异常退出。重装则应放在更靠后的位置，因为卸载可能清除日志和原始配置。只有确认安装文件损坏、核心组件缺失，或同一订阅在其他设备正常而当前设备持续无法建立基础连接时，才适合重装。

在进行任何清理之前，先保存订阅入口来源、当前线路名称、规则模式和错误文本。订阅不应复制到公开页面或提交到公开讨论区。若需要向客服说明，可提供订阅更新时间与报错现象，但不要在截图中展示完整凭据。完成这一章后，应能回答三个问题：普通网络是否正常、故障影响范围是什么、哪一个改变会稳定触发现象。后续章节均以这三个答案为起点。

§ CONNECTION

完全连不上时的判断流程

区分“按钮无反应”与“握手未完成”

完全连不上包含多种不同状态。点击连接后没有任何状态变化，通常应先检查客户端权限、后台服务和安装完整性；状态短暂变化后立即回到未连接，说明客户端已经尝试启动，但核心组件或配置校验失败；长时间停留在连接中，则更可能是当前网络无法到达所选线路、系统时间异常，或握手阶段被中断。三种现象的处理顺序不同，不能统一归结为线路问题。

先关闭客户端，再确认任务管理器或系统活动监视器中没有重复进程。重新打开后，不要立刻导入新订阅，先观察原配置是否能被正常读取。若客户端要求系统网络权限、创建虚拟接口或安装网络扩展，应在系统设置中确认该权限处于允许状态。权限被拒绝时，界面可能仍能显示线路，但无法真正接管流量。企业管理设备还可能限制网络扩展，此时普通用户权限无法自行解除，应联系设备管理方确认政策。

随后检查系统日期与时区。连接过程依赖证书与加密握手，系统时间明显偏离时可能直接失败。这里不需要手工猜时间，只需启用系统自动校时并确认时区正确。完成后切换到另一条网络再测试。若家庭网络失败而其他可靠网络成功，故障边界位于原网络入口；若所有网络都失败，而同一订阅在其他设备正常，则重点转向当前设备的权限、虚拟网卡和客户端状态。

排除重复接管网络的组件

系统同时启用多个代理、隧道或企业网络组件时，路由表可能由不同程序轮流修改。常见表现是点击连接后立刻断开、状态显示已连接但网络接口没有生成，或系统提示已有网络服务正在运行。排查时应完整退出其他同类工具，而不是只关闭窗口。浏览器代理扩展虽然通常只影响浏览器，但也应暂时停用，以免测试结果混入另一条路径。

安全软件和系统防火墙也可能阻止客户端核心进程建立出站连接。不要直接长期关闭防护功能。较稳妥的做法是查看拦截记录，确认被阻止的进程是否属于当前安装目录，再为可信程序添加允许规则。若安装目录已变化，旧规则可能继续指向不存在的路径，需要删除旧项后让系统重新识别。修改后仅测试基础连接，确认问题是否消失，再恢复其他应用。

线路切换应怎样做

切换线路不是随机连续点击。应先断开当前连接，等待系统撤销原来的虚拟接口，再选择另一地区或另一线路类型。连接成功后保持规则模式不变，先验证基础网页。FvVPN 覆盖 90+ 国家 / 200+ 线路，线路页用于理解地区和类型差异，可前往线路列表查看选择原则。排查阶段优先选物理距离较近、路径较简单的地区，目标是验证链路能否建立，而不是立即寻找最终使用线路。

如果一组线路全部失败，而另一组可以连接，应记录失败线路的地区与类型，不要继续改动系统设置。这类现象已经把范围收窄到线路路径或当前网络对该路径的可达性。若所有线路均在同一阶段失败，检查订阅是否已正确更新、套餐是否处于可用状态、客户端是否读取到完整节点信息。界面只有线路名称但连接参数缺失时，也可能显示列表却无法建立连接。

Linux 环境还应确认启动方式拥有创建网络接口和修改路由所需的权限。图形界面由普通用户启动、核心服务由系统管理时，两者状态不同步会造成按钮看似有效但后台未执行。Windows 与 macOS 则应关注虚拟网卡或网络扩展是否被系统禁用。不要手工删除不认识的系统接口；先退出客户端，记录接口名称，再通过客户端自身的修复或重新授权流程恢复。

何时停止本地尝试

当故障可在不同设备、不同可靠网络和多条线路上稳定复现，并且客户端都停在相同阶段时，继续反复安装的价值已经很低。此时应保留错误文本、线路名称、平台、发生时段和尝试结果，转到本页最后的工单章节。若只有受管理设备失败，则先联系设备管理方；若普通网络本身也不可用，则先修复本地网络。边界明确之后再交给对应支持方，能避免工单在网络、客户端与账户之间来回转交。

§ ROUTING

已连接但打不开网页与 DNS 异常

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

客户端显示已连接，只能证明基础隧道已经建立，不代表每个应用的流量都进入该隧道，也不代表域名解析和目标服务一定正常。排查时先测试多个性质不同的网页，再比较浏览器与其他 App。若全部目标都失败，应检查默认路由和 DNS；若只有域名失败而客户端自身仍能更新线路，DNS 的可能性较高；若少数目标失败，则可能与线路地区、目标服务策略、浏览器缓存或分流规则有关。

先断开连接，确认普通网络能够打开同一网页。随后重新连接，但不要改变线路和模式。若连接前正常、连接后全部失败，说明问题由连接过程引入。此时检查客户端是否启用了仅代理指定应用、绕过局域网或自定义规则。规则模式中若没有覆盖当前域名，流量可能从与预期不同的路径离开；全局模式若可用而规则模式失败，则隧道本身通常正常，应把注意力放在规则匹配和 DNS 路径上。

不要把浏览器首页是否加载作为唯一标准。首页可能来自缓存，搜索框也可能使用浏览器自带的解析机制。更可靠的做法是访问此前未打开的页面，并在系统命令行分别检查域名解析和基础连通。不同系统命令略有差异，以下命令只查询示例域名，不包含订阅或凭据。

nslookup example.com

ping example.com

nslookup 返回解析结果，说明系统至少获得了域名地址；没有返回、持续超时或指向异常的本地解析服务，则应检查 DNS。ping 不应作为网站可用性的唯一依据，因为目标可能不回应此类探测，但它可辅助观察域名是否被成功转换。若域名能够解析而网页仍失败，继续检查路由、浏览器代理和目标服务，不要仅靠更换 DNS 结束诊断。

清理缓存与恢复自动设置

DNS 异常常见于网络切换之后。系统可能保留旧网络的解析记录，浏览器也可能维护自己的缓存。先完全退出浏览器，再断开并重新连接当前网络；若仍无改善，可通过系统提供的网络诊断或 DNS 缓存清理功能刷新状态。不同系统的命令和权限要求不同，不建议从不明来源复制批量重置脚本。错误的重置命令可能同时删除企业网络、固定路由或其他正常配置。

如果此前手工设置过 DNS，排查时先恢复系统自动获取，让客户端和当前网络按默认路径协作。自动设置正常而自定义设置失败，说明问题位于自定义解析路径；两者都失败时，再检查客户端是否有独立 DNS 模式。部分浏览器可启用自己的安全解析，结果可能与系统不同。为避免混淆，应暂时保持浏览器跟随系统，确认基础链路后再恢复个人偏好。

DNS 泄漏检查与“网页打不开”不是同一个问题。前者关注解析请求从哪里发出，后者关注是否能获得有效结果。排查阶段先解决可用性，再验证出口与 DNS 是否符合预期。可结合IP 检测确认连接后的出口变化，并参考出口 IP 与 DNS 完整验证教程逐项核对。不要只看客户端状态图标就判断连接已经生效。

网页可开但登录、图片或视频失败

一个网页通常会访问多个域名。主页面加载成功，不代表图片、脚本、登录接口和媒体资源走了同一条规则。若页面文字出现但图片为空，或登录按钮一直等待，应打开浏览器开发者工具观察失败请求的域名和错误类型。无需把整份网络记录公开上传，只要先判断失败是否集中在某个附属域名。若集中出现，规则未覆盖或 DNS 对该域名返回异常的可能性更高。

隐私保护扩展、内容过滤规则和浏览器的严格防跟踪模式也可能阻止页面依赖资源。应在可信页面上暂时停用相关扩展做对照，而不是直接清空全部浏览器数据。无痕窗口只能减少部分缓存和扩展影响，不能绕过系统代理或 DNS，因此它适合做浏览器层对照，却不能替代系统层检查。

若某目标服务只在特定地区线路失败，应考虑服务自身的地区内容与会话状态。先退出该服务账户，清除对应站点的缓存与 Cookie，再连接目标地区后重新访问。不要同时登录多个地区会话，否则旧 Cookie 可能让结果看起来像线路失效。若多个浏览器、多个设备在同一地区线路上都出现相同现象，而其他地区正常，记录目标域名和线路地区后提交工单，信息会比一句“网页打不开”更可诊断。

系统代理与隧道模式的差异

有些客户端通过系统代理接管支持代理设置的程序，另一些模式通过虚拟接口处理更广泛的流量。浏览器通常会读取系统代理，但部分游戏、命令行工具或自带网络栈的 App 可能忽略它。因此，浏览器可用而其他程序不可用，不一定是线路故障。反过来，虚拟接口工作正常但系统代理残留错误地址，也可能只让浏览器失败。

检查系统网络设置中是否留有手工代理。若客户端负责自动管理，应避免再手工填写同一项。退出客户端后系统代理仍保持启用，是典型的残留状态；将其恢复为正常网络设置，再重新启动客户端。完成修复后分别测试浏览器、系统更新和目标 App，确认影响范围确实缩小。任何时候都不要把订阅链接直接粘贴到浏览器地址栏测试，因为浏览器访问行为与客户端订阅请求并不等价，还可能让敏感参数进入历史记录。

§ PERFORMANCE

速度慢与晚高峰卡顿

先区分吞吐、响应与丢包

用户感受到的“慢”至少包含几种不同现象。大文件下载速度低，主要反映持续吞吐；网页点击后长时间无反应，可能与往返响应、DNS 或目标服务器有关；视频频繁停顿可能是持续吞吐不足，也可能是短时抖动；实时通话断续则更敏感于丢包和路径变化。不同问题不能只靠一次网页测速判断，更不能用某个瞬时峰值代表整条链路。

建立性能基线时，先断开连接测试本地网络，再连接同一线路测试相同目标。测试设备、网络和时间条件应保持一致。若本地网络本身波动，连接后的结果没有可比性。无线环境中距离、干扰和省电策略都会影响表现；能够使用有线连接时，可用它排除无线因素。移动网络则可能随位置和网络切换发生明显变化，应在位置相对固定时比较。

其次区分目标服务限制与线路限制。单个下载源慢，而多个网页和其他下载正常，问题可能在目标源；所有目标都慢，再检查线路和本地网络。浏览器下载、视频播放、云同步和游戏更新使用的连接方式不同，不能直接互相替代。应选择与真实用途相同的测试：看视频就观察播放与拖动进度，使用 AI 工具就观察页面连接和回复是否稳定，下载文件则观察持续传输，而不是只追求短时峰值。

线路距离与路由复杂度

物理距离会影响响应，但距离最近不必然代表路径最好。运营商互联、跨境出口和目标服务所在地区都会改变实际路由。选线时应先根据目标服务地区缩小范围，再比较同地区不同线路的稳定性。若用途没有明确地区要求，优先选择路径较近且长期稳定的线路。详细规则可参考地区、线路类型与用途选线指南。

切换线路后应给系统足够时间完成旧连接释放与新路由建立。连续快速切换会留下未完成请求，浏览器连接池也可能继续复用旧会话，造成结果混杂。切换后关闭相关页面并重新打开，再观察相同操作。若新线路只在刚连接时正常，随后逐渐变慢，应记录持续使用中的变化；若从连接开始就慢，则比较同地区其他线路和断开后的本地基线。

晚高峰卡顿需要跨时段对照，但不需要虚构可用率或保证值。应记录同一设备、同一网络、同一线路在常用时段的表现，再换同地区备选线路复测。若只有某条路径在特定时段变差，保留稳定的备选线路即可；若所有线路与普通网络同时变差，问题更可能位于本地运营商或无线环境。若普通网络稳定而多个地区线路同时出现一致波动，可向客服提交时段和线路信息。

客户端与系统资源的影响

设备处于省电、过热或高负载状态时，网络处理可能被系统限制。排查时关闭大规模同步、系统更新和其他持续占用网络的任务，保持客户端在前台或允许后台运行。不要通过结束不认识的系统进程来“释放速度”，这可能破坏网络服务。更有效的是查看任务管理器或活动监视器，确认是否有明确的下载、备份或更新任务占用链路。

客户端规则越复杂，排查越需要先回到简单模式。自定义规则、脚本和多层转发可能增加判断难度。先使用客户端提供的基础规则验证线路，再逐项恢复自定义内容。若基础模式稳定而自定义配置变慢，应检查是否存在重复转发、错误的远程规则或大量失败重试。配置文件应保持来源明确，不要混合不同客户端格式后强行导入。

流量额度也应在用户面板中核对。月订阅包含对应流量，流量按开通日每月重置；流量包则用完为止，永久不过期。若套餐状态或剩余流量不足，客户端侧的表现未必等同于普通线路拥堵。需要调整方案时，可查看套餐价格，其中月订阅为 ¥9.9/月含 60GB、¥18/月含 250GB、¥28/月含 500GB；中途升级差价折算成剩余天数。排查时只核对当前状态，不要通过反复下单测试连接。

形成可复用的线路选择记录

速度问题通常不是找到一条“永远最快”的线路，而是建立适合不同用途的稳定选择。可以分别记录日常浏览、视频、AI 工具和实时交互中表现可靠的线路地区，并保留同地区备选。记录应关注现象和适用场景，不必依赖单次数字排名。线路状态会随网络路径和目标服务改变，旧结论应在出现明显变化时重新验证。

如果更换设备后问题消失，检查原设备的无线驱动、后台任务和客户端规则；更换本地网络后消失，检查原网络环境；更换线路后消失，则保留失败线路和时段；只有目标服务慢时，则先排除目标自身状态。这样的分支结论可以直接进入工单，也能避免把所有性能波动都归为节点故障。

§ STABILITY

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

先判断是谁主动结束连接

断线可能来自客户端主动重连、操作系统回收后台进程、本地网络切换、线路连接中断或设备休眠。应先观察断线发生前后的事件：是否刚锁屏、是否从无线网络切换到移动网络、是否进入省电状态、是否同时切换位置、客户端是否显示重连提示。若每次锁屏后发生，重点检查后台权限；若网络切换时发生，重点检查重连能力；若前台静置也周期性断开，则检查线路和本地网络稳定性。

不要把“网页停顿”直接认定为隧道断开。网页请求超时可能发生在目标服务或 DNS，而客户端连接仍然存在。断线时先查看客户端状态，再检查出口是否变化。若状态保持连接但出口恢复为普通网络，可能是系统路由丢失；若状态本身转为断开，查看客户端日志中的结束原因；若客户端仍连接且出口不变，问题更可能在目标应用或线路短时抖动。

在桌面系统上，睡眠与唤醒会使网络接口重新初始化。唤醒后旧隧道可能看似存在，实际路由已失效。此时先正常断开，再重新连接，不要连续强制结束进程。若问题只在睡眠后出现，可在唤醒后固定执行重新连接，并确认客户端是否有随网络恢复的选项。系统更新后首次出现时，应重新检查虚拟网卡或网络扩展权限。

移动端后台管理

移动系统会根据电量、内存和后台策略暂停应用。客户端退到后台后立即断线，通常应检查系统是否允许持续运行、是否开启了严格省电、是否限制了后台数据，以及系统是否在锁屏时自动清理应用。不同品牌界面名称不同，但判断逻辑一致：让客户端保持前台测试；前台稳定而后台断开，线路通常不是首要原因。

排查时暂时取消对客户端的电量优化，并允许其后台运行。不要给所有应用统一取消省电，只调整当前客户端即可。随后锁屏并等待正常使用场景出现，再检查连接状态。若仍掉线，观察是否恰好发生网络类型切换。移动网络与无线网络之间切换时，设备地址和默认路由都会改变，原连接可能需要重新握手；客户端若未及时恢复，可返回前台手动重连进行对照。

部分系统会在存储空间紧张或内存压力较高时更积极地清理后台。此时即使权限正确，进程也可能被终止。关闭不必要的大型应用后复测，并确认系统没有启用自动清理名单。若前台和后台都会断线，则不要继续只调整省电设置，应回到线路、本地网络和 DNS 层检查。

网络切换与弱信号环境

在移动中使用时，信号变化、接入点切换和网络重选都会影响持续连接。若断线集中发生在移动过程，应先在固定位置测试同一线路。固定位置稳定，说明问题与网络变化有关；固定位置也不稳定，再换另一可靠网络。对于实时通话、长下载或远程连接，网络切换比普通网页浏览更容易暴露中断，因为这些任务依赖持续会话。

家庭无线网络中，设备可能在不同接入点或频段之间切换。表面上仍显示同一个网络名称，底层路径却已变化。可以靠近主要接入点测试，或暂时减少自动漫游因素。若有线连接稳定而无线断线，优先处理无线覆盖和干扰，不应反复更换远端线路。若无线与有线都在相同时段中断，再检查路由器上游连接和线路表现。

自动重连与网络锁定的边界

自动重连能缩短中断，但也可能掩盖根因。若客户端频繁重连，表面上仍可使用，却说明基础链路不稳定。排查时应查看重连发生的触发条件，而不是只确认最终恢复。网络锁定类设置在隧道断开时可能阻止普通流量，这是保护行为，但用户看到的现象会是“断线后所有网络都没了”。应先理解该开关的作用，再决定测试期间是否暂时关闭。

修改自动重连或网络锁定后，应明确记录原设置，以便测试结束后恢复。若关闭锁定后普通网络立即恢复，说明本地网络本身可用，下一步仍是找出隧道为何中断。若断开客户端后网络也不恢复，检查系统代理、默认路由和虚拟接口是否残留。正常退出客户端通常比强制终止更能完成清理。

当断线在多个网络、多个设备和多个地区线路上都能复现时，应提交客户端日志与时间范围。若只在某一设备后台出现，则提供系统后台设置截图；只在特定网络切换时出现，则说明切换前后的网络类型；只在单条线路出现，则提供线路名称。准确边界能帮助支持人员判断是客户端生命周期、路由恢复还是线路连接问题。

§ CONFIGURATION

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

订阅更新与线路连接是两条请求

订阅更新失败不等于所有现有线路立即失效。客户端通常先从订阅入口取得配置，再使用配置中的线路建立连接。若更新失败但旧配置仍在，部分线路可能继续可用；若首次导入就失败，则客户端没有可用配置。排查时应先确认订阅来自用户面板，并通过客户端的订阅导入功能添加，不要把地址当作普通网页打开，也不要手工修改其中参数。

登录后可从用户面板获取客户端与订阅。订阅属于账户配置，不应公开粘贴到论坛、截图或共享文档。若怀疑复制不完整，应回到面板重新复制并覆盖原条目，而不是在旧地址末尾手工补字符。客户端提示格式错误时，先确认导入位置是否确实接受订阅地址；有些输入框接收单个节点配置，有些接收订阅，两者格式不同。

更新时还应确认普通网络可用。客户端在一条失效线路上尝试更新，而更新请求又被错误路由到该线路，可能形成循环失败。可先断开连接，再使用正常网络更新；更新完成后重新选择线路。若断开后可更新、连接后不能更新，应检查客户端是否把订阅域名错误地纳入了不可用路径。

缓存、重复订阅与配置冲突

客户端中同时存在重复订阅时，可能出现同名线路来自不同来源、旧条目覆盖新条目或更新了错误的配置组。先查看订阅列表，而不是线路列表，确认只保留当前需要的来源。删除前记录条目名称和更新时间，避免误删仍在使用的配置。清理重复项后重新更新，再检查线路数量与名称是否发生合理变化。

若客户端支持规则、脚本或配置合并，排查时暂时关闭额外处理。合并模板中的语法错误可能让订阅下载成功，却在解析阶段失败。错误提示若包含解析、字段或配置结构，应优先检查本地模板；若提示网络超时，则优先检查网络路径；若提示授权或订阅状态，则前往用户面板核对账户和套餐。不同错误阶段应分别记录，不要只写“更新不了”。

流量按开通日每月重置，中途升级差价折算成剩余天数。若需要额外流量，流量包为 ¥158/300GB、¥358/1000GB、¥658/3000GB，用完为止，永久不过期。套餐或流量状态应在面板中确认，不能依据客户端缓存自行推断。支付方式为支付宝 / 微信 / USDT。涉及订单和状态的问题应通过面板工单处理，不要尝试通过反复删除账户配置来恢复。

只有某个 App 不走预期路径

浏览器正常而某个 App 无法访问时，先确认该 App 是否读取系统代理。部分应用使用系统设置，部分应用自带代理选项，另一些应用直接通过系统网络接口通信。客户端采用系统代理模式时，不读取系统代理的应用可能直接连接；采用虚拟接口模式时，覆盖范围通常更广，但仍可能受分应用排除规则影响。

最有效的验证是暂时使用覆盖范围更广的基础模式，保持线路不变，再打开目标 App。若此时恢复，说明线路与目标服务基本可用，问题位于分流规则。接下来不要长期保持全局规则，而应检查目标 App 的进程名、关联域名和是否被排除。一个桌面应用可能由启动器、更新器和主进程共同组成，只加入其中一个进程，可能导致登录可用而内容加载失败。

移动端的分应用设置通常按应用选择。确认目标 App 没有被加入绕过列表，也没有在系统中被限制后台数据。修改后应完全结束 App 再重新打开，因为已有连接可能继续沿用旧路径。若目标 App 内还有自己的代理设置，应避免与系统客户端重复配置。重复代理可能造成循环、认证失败或连接被转发到错误接口。

命令行工具与开发环境

命令行工具不一定继承桌面系统代理。有些工具读取环境变量，有些使用自身配置，还有些完全依赖系统路由。排查时先确认客户端当前模式是否覆盖命令行进程，再检查终端会话中是否残留旧代理变量。新开终端窗口可以排除部分会话缓存，但不会改变系统路由。不要把真实订阅或账户凭据写入 shell 历史。

需要演示配置格式时，应使用明显的假值。例如下面仅表示环境变量的结构，地址与端口均为占位内容，不能用于连接：

export HTTPS_PROXY="http://proxy.example.invalid:PORT"
export HTTP_PROXY="http://proxy.example.invalid:PORT"

若系统隧道模式下命令行可用，而只设置环境变量时失败，检查变量格式和工具支持；若两种方式都失败，回到 DNS 与目标域名检查。开发工具还可能读取项目级配置、用户级配置和环境变量，优先级不同。应逐层确认当前生效值，而不是同时修改全部文件。

当单个 App 问题无法定位时，工单中应提供 App 名称、平台、客户端模式、其他 App 是否正常、切换到基础覆盖模式后的结果，以及失败发生在登录、内容加载还是下载阶段。不要提交完整订阅。若问题与某个公开域名有关，可以提供域名；若涉及个人项目或内部服务，只需描述错误类型和网络层现象。

§ SYSTEM STATE

DNS 检查与设备状态冲突

把 DNS 问题从路由问题中分离

DNS 负责把域名转换为可连接的地址，路由则决定请求从哪条路径发送。两者经常同时被客户端管理，因此现象容易混淆。判断时先记录域名是否能解析，再检查解析后的请求是否可达。若解析失败，换线路不一定有用；若解析正常但连接失败，则应检查路由、目标服务或线路。不要把任何“域名打不开”都直接称为 DNS 泄漏。

系统、浏览器和客户端可能各自维护解析策略。排查时应暂时减少层级：浏览器跟随系统，系统使用自动配置，客户端使用默认 DNS 模式。基础访问恢复后，再逐项启用自定义设置。若一启用某项就复现，问题边界已经明确。修改 DNS 后应关闭已有页面和连接，避免旧连接池继续使用此前结果。

企业网络、校园网络和公共网络有时要求先完成网页认证。未认证时，域名可能被重定向到登录页面，连接客户端后反而看不到认证入口。此时先断开客户端，用普通浏览器完成网络自身的登录，再建立连接。若认证页面仍不出现，可忘记该网络后重新加入，或联系网络管理方。不要在不可信页面输入账户订阅信息，网络认证与 FvVPN 登录是两套独立流程。

本地解析文件与缓存污染

开发环境可能修改本地 hosts 文件，把特定域名固定到某个地址。此类规则优先于普通 DNS，换线路和换解析服务都不会改变结果。若只有少数开发相关域名异常，应检查本地解析文件中是否存在旧记录。修改前先备份原文件，并只移除能够确认来源的条目。不要下载所谓“一键优化 hosts”覆盖系统文件。

浏览器缓存也可能保存失败结果。可以通过关闭浏览器、清理对应站点数据或新建干净配置做对照，但不必先清空全部历史。若所有浏览器都出现相同结果，问题更可能位于系统或客户端；只有一个浏览器异常，则优先检查其扩展、缓存和独立 DNS 设置。移动端可通过切换飞行状态或重新加入网络刷新部分状态，但应在固定网络下重新测试，避免把网络变化误当作修复。

如果解析结果在连接前后发生变化，这本身不一定异常，因为不同线路可能使用不同解析路径。关键是结果能否访问、是否符合目标地区，以及多个请求是否保持一致。使用 IP 检测页时，应同时观察出口和 DNS 判断，不要只根据一个字段下结论。若连接后出口符合预期而域名仍失败，提供域名、线路地区和解析错误类型即可，无需公开个人浏览记录。

“设备数超限”提示应怎样理解

FvVPN 支持不限台数，因此遇到客户端或第三方工具显示“设备数超限”时，不应把它直接理解为本服务套餐限制。先确认提示来自哪里：是 FvVPN 用户面板、所用客户端、系统账户，还是目标网站。不同来源的限制完全不同。目标服务可能限制自己的登录会话，客户端也可能维护本地配置数量，这些都不等于 FvVPN 限制设备台数。

若提示来自客户端，检查是否导入了重复配置、是否使用了不兼容的账户同步功能，以及客户端自身是否要求管理已登录实例。退出无用会话或清理重复本地配置时，不要删除用户面板中的有效订阅。若提示来自目标网站，应按照目标网站的账户规则处理；更换线路通常不能解决其账户会话限制。

若用户面板状态与客户端提示不一致，先退出面板并重新登录，再更新订阅。FvVPN 注册无需邮箱地址，用户名+密码即可注册，因此应妥善保存用户名与密码。不要为了排查设备提示重复创建多个账户，这会让订单、流量和订阅来源混在一起。若无法判断提示来源，应截取包含窗口标题和完整提示的画面，同时遮挡用户名、订阅和订单信息。

多设备之间如何做交叉验证

不限台数使多设备对照更方便，但对照时必须控制变量。选择同一网络、同一线路地区和相近的客户端模式，观察另一设备是否复现。如果一台设备正常、一台失败，重点检查失败设备；两台都失败，再换网络或线路。不同平台的系统代理实现不同，不能要求界面选项完全一致，应比较结果与网络路径。

Windows / macOS / iOS / Android / Linux 都受支持。桌面平台更便于查看日志、路由和解析结果，移动平台更容易受到后台策略和网络切换影响。若移动端异常而桌面端正常，先检查后台权限与移动网络变化；桌面端异常而移动端正常，检查虚拟网卡、系统代理和安全软件。两者都在同一网络失败，则本地网络或线路路径的优先级更高。

交叉验证不应使用公开分享订阅的方式。每台设备都应从用户面板取得正确配置，并确保订阅来源一致。若某台设备长期未更新，先更新后再比较；若更新本身失败，转到上一章。对照完成后记录“哪台设备、哪种网络、哪条线路、哪类应用”可用或不可用，结论应是可复现的边界，而不是笼统地写某个平台不稳定。

恢复网络设置时的安全边界

系统提供的网络重置会删除或重建多个网络组件，属于影响范围较大的操作，应放在诊断后段。执行前记录无线网络、企业网络、固定地址、代理和虚拟接口配置。若设备由组织管理，不应自行重置。普通用户也应先尝试退出其他网络工具、恢复自动 DNS、正常重启客户端和系统，再决定是否使用重置。

重置完成后不要立刻恢复全部自定义项。先确认普通网络，再安装或授权当前客户端，导入订阅并测试基础线路。基础链路稳定后，逐项恢复浏览器扩展、自定义规则和开发环境代理。若恢复某项后故障再次出现，该项就是重要线索。这样的恢复过程虽然比一次性导入旧配置慢，却能避免把原问题完整带回新环境。

§ SUPPORT

何时找客服与怎样提交有效工单

适合自行处理与适合提交工单的边界

普通网络本身不可用、设备受组织策略管理、目标网站账户被限制，通常应先联系对应网络或目标服务支持。只有单个浏览器扩展造成的问题，也适合先在本地处理。相反，当相同故障在多个可靠网络、多台设备或多条线路上稳定复现，或者用户面板状态、订单状态与客户端结果明显不一致时，应提交 FvVPN 工单。

线路问题适合提交的条件包括：同一线路在不同设备和网络上出现一致错误、某一地区的一组线路均无法建立连接、特定线路持续断开且其他线路稳定。客户端问题适合提交的条件包括：系统权限已允许但核心服务无法启动、更新订阅在普通网络下仍返回明确错误、基础模式也无法覆盖目标 App。账户与订单问题则应直接从用户面板进入工单，避免在公开页面讨论。

如果问题已经通过切换线路解决，仍可在频繁复现时提交，但应说明当前已有临时替代方案。这样支持人员可以优先判断是否需要处理线路，而不会误以为所有连接都已中断。30 天无理由退款属于服务承诺；退款相关事项应按退款政策和用户面板流程处理，不应与技术故障描述混写在同一段。

工单应附哪些信息

有效工单应先用一句话描述边界，例如“Windows 在家庭网络和另一可靠网络上均无法连接，Android 使用相同线路正常”，或“iOS 前台稳定，锁屏后连接结束”。随后列出平台、客户端来源、故障发生时段、线路地区、连接模式、受影响应用和完整错误提示。若已尝试本手册步骤，应写明哪些操作改变了结果，避免支持人员要求重复测试。

截图应包含窗口标题、状态和错误原文，但需要遮挡用户名、订阅、订单详情与个人内容。日志可以附上故障发生附近的片段，不必把长期完整日志全部粘贴到正文。若客户端提供导出诊断信息的功能，应先检查内容，再通过工单上传。不要发送真实密码，也不要把订阅地址写进工单标题。

对于速度或晚高峰问题，应提供普通网络是否正常、同地区其他线路结果、具体使用场景和发生时段。对于网页问题，应提供公开域名、浏览器与其他 App 是否一致、切换线路后的变化。对于订阅问题，应提供更新阶段的错误文本和断开连接后是否可更新。对于后台掉线，应提供前台是否稳定、系统后台权限状态和是否发生网络切换。

问题现象：
影响范围：
使用平台：
当前网络：
线路地区：
连接模式：
错误原文：
已完成的自查：
能够稳定复现的步骤：
临时可用方案：

怎样获得可重复的日志

记录日志前先退出无关应用，保持网络与线路固定。清除旧日志并非必需，但应明确故障发生的大致位置。开始记录后，按最短路径复现一次：打开客户端、选择线路、发起连接、访问目标，再停止操作。不要在记录期间连续切换多条线路，否则日志会包含多个失败过程，难以判断哪一段对应工单描述。

若故障涉及断线，应记录断线前发生的系统事件，例如锁屏、休眠、网络切换或前后台变化。若故障随机出现，可以保留客户端运行，待现象发生后立即记下时段和当前线路。日志中出现错误并不代表每条都是根因，网络软件在切换过程中产生少量取消或重试记录很常见，支持人员会结合时间和现象判断。

命令行输出也应只包含诊断需要的部分。域名解析结果、路由接口状态和公开目标的连接错误可以提供，但环境变量、访问令牌、项目地址与本地用户名应先检查。任何从开发环境复制的日志都可能夹带凭据，提交前必须清理。示例订阅只能使用类似 https://example.com/sub?token=YOUR_TOKEN 的明显假值，真实地址不应进入文档或公开记录。

长期维护：减少重复故障

完成修复后，应保留一份简短结论：故障层级、触发条件、有效解决办法和可用备选线路。不要只写“重装后好了”，而应记录重装前是否存在权限错误、重复配置或旧虚拟网卡。这样下次出现相似现象时，可以先验证同一边界，而不是从头尝试所有步骤。

订阅应通过用户面板更新，客户端也应从面板获取。不要长期保留来源不明的旧配置，也不要把多个服务配置混入同一个无法辨认的分组。线路选择可以按使用场景保留主选与备选，并定期确认旧线路名称是否仍对应当前配置。FvVPN 覆盖 90+ 国家 / 200+ 线路，选择范围较大，但排查时仍应一次只比较一个变化。

系统更新、网络环境变化和客户端权限调整后，建议重新完成最小验证：普通网络、订阅更新、基础连接、出口 IP、DNS 和常用 App。完整验证方法可阅读VPN 连上后如何确认生效。若故障主要来自游戏延迟与丢包，可参考游戏加速器和 VPN 的差异，避免把通用代理与专用游戏路由混为同一类工具。

从现象回到依赖关系

系统排查的核心不是记住所有按钮位置，而是识别依赖关系。普通网络是入口，订阅提供配置，客户端建立隧道，系统路由决定流量路径，DNS 提供域名解析，线路连接目标地区，目标服务最终返回内容。每一层都可以单独验证，也都可能影响下一层。只要先确定最后一个正常环节，就能把范围缩小。

完全连不上时，从权限、冲突和网络入口开始；连接后无网络时，从路由与 DNS 开始；速度慢时，区分吞吐、响应与目标限制；频繁断线时，观察网络切换、休眠与后台策略；订阅失败时，分开下载、解析与状态；单个 App 异常时，检查系统代理、虚拟接口与分应用；所谓设备超限则先核对提示来源，因为本服务不限台数。

如果经过这些分支后仍无法定位，不必继续扩大改动范围。保留最小复现环境，进入用户面板的工单入口，按本章结构提交信息。清楚的边界、完整的错误原文和可重复步骤，比大量无关截图更有价值。故障解决后再恢复自定义规则与扩展，每恢复一项就验证一次，直到日常环境稳定。