V2Ray 全平台安装配置

准备工作：平台、订阅与配置层级

先区分客户端、内核和服务端参数

v2rayN、v2rayNG 和 v2flyNG 是配置与运行入口。客户端负责保存服务器资料、生成内核配置、展示日志，并按平台提供系统代理或 VPN 接入。Xray、V2Fly 属于执行连接和路由的内核家族。安装客户端并不等于已经有可用服务器；服务器地址、端口、认证信息、传输方式和 TLS 参数仍需由实际服务提供方提供。不能仅凭协议名称推导这些字段，也不能把网上另一份配置中的认证信息拼接到现有地址上。

一次连接至少经过应用、本地入口、内核路由和远端服务器几个环节。应用没有把请求交给本地入口时，修改远端协议没有帮助；内核根本没有启动时，反复更换浏览器也无法解决。准备阶段先建立这个层级概念，后续每次验证只改变一个环节。建议记录原有系统代理、是否存在其他 VPN、当前网络类型及客户端保存目录，避免测试后无法恢复原来的网络设置。

确认处理器与安装包类型

打开客户端下载页后，先选操作系统，再选处理器和包格式。Windows 的 Desktop 与 WPF 是界面分支，不是两种代理协议；macOS 要区分 Apple Silicon 与 Intel；Linux 同时涉及处理器架构和发行版包管理格式；Android 通常先考虑 arm64，无法确认兼容性时再查看通用版。文件后缀相同不代表架构相同，设备能够下载文件也不代表能够执行文件。

准备可识别的订阅和恢复材料

订阅通常是返回一组服务器配置的地址，不是管理后台网址，也不是套餐购买页面。只有提供方明确说明用于客户端导入的链接才应填入订阅分组。教程统一使用 https://example.com/sub?token=xxxx 表示结构，该地址不提供实际服务。真实订阅地址可能包含访问凭据，截图、分享日志或请人协助时，应遮住完整查询参数、用户标识和服务器认证字段。

准备一份仅自己可访问的配置备份，并确认设备日期、时间及时区正确。TLS 证书验证依赖系统时间，时间明显偏移可能让多条本来可用的配置同时失败。初次测试不要同时启用系统代理、TUN 和另一套 VPN；先选单一接入方式，验证成功后再按应用需要扩展。公司或校园设备还应先确认设备管理策略是否允许修改网络设置，不要用重复授权代替对权限来源的判断。

最后准备两类验证对象：一个原本就能访问的页面，用来观察直连是否受到影响；另一个明确需要通过当前代理配置访问的目标，用来确认代理链路。验证结果要写清对象、时间和接入方式，而不是只记“网络不行”。若只想完成第一条连接，可先阅读快速上手步骤；本手册保留安装、权限和恢复分支，适合按问题查阅。

Windows：v2rayN 安装与代理接入

选择 Desktop 或 WPF 并完成安装

进入Windows 下载入口，v2rayN 提供 Desktop 桌面版与经典 WPF 版。Desktop 使用跨平台界面，WPF 保留经典 Windows 操作布局；服务器参数不会因为界面不同而自动变成另一套协议。首次安装选一个分支即可，不要让两个分支同时运行并争用本地端口。如果需要对照界面，应先退出正在运行的实例，再打开另一份程序，并分别保留配置备份。

按安装程序提示完成后，从正常的应用入口启动。若使用可直接运行的目录形式，应先完整解压到自己有写入权限的位置，不要在压缩包预览窗口内执行，也不要只复制主程序而遗漏随附文件。程序目录、用户配置目录和日志目录的具体位置可能随安装方式变化，优先通过客户端的打开目录功能确认。启动提示缺少运行环境时，按提示核对所需 .NET 桌面运行库、架构及界面分支，不能用任意名称相似的运行库替代。

导入订阅并选定当前服务器

打开“订阅分组”，新增分组并填写便于识别的名称，将订阅地址放入地址字段，保存后执行该分组的订阅更新。完成更新只表示配置获取成功，还需要在主界面选择要使用的服务器并设为活动项。若已有多组订阅，先确认当前列表属于哪个分组，避免在错误分组里反复更新。导入分享链接时应使用对应的剪贴板导入入口，不要把完整的协议分享链接填到服务器地址栏。

首次运行先保留默认本地监听地址，查看客户端显示的实际入站端口。本文以 10808 作为说明用的本地端口；实际应用要以设置和日志为准，并确认它提供的入口协议。HTTP、SOCKS 或混合入口不能只根据端口数字猜测。除非确实需要给局域网其他设备使用，不要把监听地址改为全部网卡；扩大监听范围会引入本机防火墙和访问权限的问题。

先用系统代理验证，再按需要启用 TUN

在“系统代理”中选择“自动配置系统代理”，随后使用会读取 Windows 系统代理的浏览器访问测试目标。“清除系统代理”用于撤销客户端设置的系统代理；“不改变系统代理”表示启动或切换时不主动改写现有设置，并不等于清除历史代理。若浏览器装有独立代理扩展，先暂停扩展的规则接管，避免系统设置与扩展设置互相覆盖。企业策略管理的浏览器还要查看是否存在被组织锁定的代理项。

确实需要接管不读取系统代理的应用时，再考虑 TUN。启用前先关闭其他虚拟网卡接管工具，记录当前网络状态，并按客户端提示授予必要权限。TUN 涉及虚拟接口、路由和 DNS，连接失败时应先退回已验证的系统代理模式，而不是不断切换服务器。是否需要提升权限取决于当前实现与运行方式，不应为了普通订阅更新而长期以管理员身份运行整个客户端。

常见的平台问题包括目录不可写、端口已占用、启动后只剩托盘图标以及运行库不匹配。先看任务栏通知区域是否已有实例，再查日志中的监听失败或权限错误。安全软件出现拦截记录时应核对具体文件和来源，不要直接关闭整套保护。更完整的启动分支见v2rayN 打不开或启动闪退排查；恢复网络与处理闪退是两件事，应分别确认。

macOS：芯片选择、安装授权与网络设置

按芯片类型选择 v2rayN 安装包

在系统菜单中打开“关于本机”，查看芯片或处理器字段。显示 Apple 芯片的设备选择 Apple Silicon 对应包，显示 Intel 处理器的设备选择 Intel 对应包，再从macOS 下载入口获取 v2rayN。不要按电脑外观或购买年份推断架构，也不要把另一种架构能否经兼容层运行当作默认安装方案。正确匹配本机架构能够减少运行环境和权限判断中的额外变量。

打开磁盘映像后，按其中的安装引导将应用放入“应用程序”，随后从已安装位置启动。不要长期直接在挂载映像内运行，更新或移除映像时路径可能改变。系统提示应用来源或启动受限时，先确认下载来源和文件类型，再到“系统设置 → 隐私与安全性”查看是否有针对该应用的处理入口。只处理这一次明确识别的应用，不要为了启动客户端而整体关闭系统的安全检查机制。

导入配置并核对活动连接

进入 v2rayN 的“订阅分组”，添加名称与订阅地址，保存后更新该分组。若订阅能够读取但连接仍失败，先确认主界面已选定一条配置，并核对其协议和传输参数是否由当前内核支持。不要把“订阅更新成功”理解成“每条服务器均已测试成功”。当界面展示多个名称相似的项目时，可查看所属分组和服务器地址来区分，避免把已经失效的手动导入项误当作刚更新的项目。

首次测试建议关闭 TUN，只使用系统代理。客户端设置系统代理后，可在“系统设置 → 网络”中选当前连接，进入详情查看代理项目；有线网络、无线网络和其他服务可能各有独立设置。切换网络后出现行为差异，应确认当前生效的是哪一个网络服务，而不是只看客户端按钮是否仍显示开启。自动代理配置、手动 HTTP 代理和 SOCKS 代理也不应在不清楚来源时叠加保留。

区分图形应用、终端与 TUN 的权限

部分图形应用读取系统代理，部分应用使用自己的网络栈或代理设置。终端程序也不一定继承图形界面的系统代理，因此浏览器可用而终端不可用并不罕见。需要给某个命令使用本地代理时，应按该命令支持的入口协议单独设置，先确认监听端口确实存在。不要把终端变量永久写入启动文件作为第一步，否则退出客户端后，新开的终端仍可能继续访问一个已经关闭的本地入口。

TUN 是否需要额外授权、辅助组件或提权，取决于当前客户端实现。按界面提示完成必要授权后，重新查看日志中虚拟接口与路由是否建立；应用有启动权限，不等于它已经具有改写网络路径的权限。启用 TUN 后若原本正常的直连页面失效，先停用 TUN，再检查 DNS 与网络服务顺序。不要同时运行另一套 VPN 作为补救，两套接管机制可能让路由绕回本机，掩盖最初的问题。

更新前先退出应用并保存配置备份，避免新旧应用副本同时存在于不同目录。若更新后设置看似消失，先核对启动的是“应用程序”内的副本还是下载目录中的旧副本，再确认当前用户配置位置。卸载或停止使用前，先在客户端清除系统代理、停用 TUN，然后检查当前网络服务的代理项。仅把应用移到废纸篓不会可靠地撤销所有既有网络设置，恢复步骤应在删除程序之前完成。

Linux：包格式、桌面代理与 TUN 权限

确认发行版、架构与图形会话

Linux 安装先分清包管理体系和处理器架构。Debian、Ubuntu 等通常使用 deb 包，Fedora 等通常使用 rpm 包；具体仍以发行版的包管理文档为准。打开Linux 下载入口后，分别选择 x64 或 arm64。不要仅凭系统能够识别某个压缩文件就判断安装包可用。v2rayN 是图形客户端，纯终端服务器和缺少桌面会话的环境不属于本页图形安装流程的直接适用范围。

安装前可用下面的只读命令查看架构和系统标识。x86_64 通常对应下载页的 x64，aarch64 通常对应 arm64；若看到其他架构，不应强行套用这两种包。系统标识用于判断发行版家族，不能据此保证所有桌面依赖都已安装。通过发行版的软件安装器或包管理器打开实际下载的包，并认真处理依赖提示，不要使用强制忽略依赖作为通用安装方法。

uname -m
cat /etc/os-release

普通用户启动并导入订阅

安装完成后，从桌面应用列表启动 v2rayN。先以普通用户运行，确认界面、设置保存与日志输出正常，再处理需要权限的网络功能。不要为了避免一个目录权限错误就用 root 运行整个图形应用，这可能生成归属错误的配置文件，导致下次普通启动无法写入。若曾误用提权启动，先定位实际配置目录并检查归属，不要对整个主目录执行递归权限放宽。

在“订阅分组”填写地址并更新，选择活动服务器后查看内核日志，确认本地入口监听成功。Linux 的桌面环境与网络管理器组合较多，客户端的“自动配置系统代理”不一定影响所有应用。应到桌面环境的网络代理设置中核对地址与端口，再以明确读取该设置的应用测试。浏览器若有独立代理配置，应先统一入口，避免桌面设置已经改动而浏览器仍固定使用另一条路径。

按入口协议验证，而不是猜测端口

终端程序通常更适合显式指定代理。下面的命令仅用于验证已经确认是 SOCKS 入口的本地端口，示例中的 10808 必须替换为界面显示的实际端口。socks5h 表示由代理端处理目标域名解析；若使用普通 socks5，解析位置可能不同。命令有响应只能说明这次请求经过了该入口，不能证明整个桌面或所有协议流量都已被接管。

curl --proxy socks5h://127.0.0.1:10808 --head https://example.com

TUN 还涉及虚拟设备、系统路由和权限。启用后先看日志是否能创建接口，再看默认路由和 DNS 是否按预期调整；错误发生在创建设备之前时，换订阅没有意义。不同发行版可能通过系统服务、授权机制或客户端提供的方式获得权限，应遵循当前软件说明。不要给不明文件随意添加系统能力，也不要把所有网络问题都归因于防火墙后直接关闭规则。

若休眠、切网或异常退出后失去网络，先停用 TUN，恢复桌面代理设置，再检查网络管理器所管理的连接与 DNS。安装更新时保留配置备份并退出旧进程，避免两个内核争用端口。自启动应在手动运行稳定后再启用，同时区分“启动图形客户端”和“建立系统级网络接管”。需要进一步判断终端与浏览器差异时，可参照系统代理不生效的分线排查。

Android：客户端安装与 VPN 接管

首选 v2rayNG，按需要使用 v2flyNG

进入Android 下载入口，先查看 v2rayNG，使用 Xray 内核；需要 V2Fly 内核生态时再考虑 v2flyNG。两款应用都应根据设备选择 arm64 或通用版。较新的主流设备通常使用 arm64，但最终要以设备架构和应用兼容情况为准。通用版是架构选择上的备选，不表示它会让同一条服务器配置获得另一种协议能力，也不表示安装失败都能靠更换通用版解决。

打开下载的安装文件后，系统可能要求允许当前文件管理器或浏览器安装应用。只对确实用于本次安装的来源授予权限，安装完成后可按设备设置撤回。若系统提示解析失败、签名不一致或无法覆盖安装，先确认文件已经下载完成、应用架构及现有应用来源。不要立即卸载旧应用；应先导出可恢复的配置，再判断是安装包兼容问题还是不同来源的签名冲突。

添加订阅、更新分组并选择服务器

打开应用，在“订阅分组设置”或对应的订阅管理入口新增分组，填写名称与地址，保存后返回主界面执行更新订阅。若界面提供多个更新方式，应先使用正常更新路径；需要经现有连接获取订阅时，再确认活动连接能够访问订阅地址。不要在列表尚未更新完成时连续重复点击，否则很难区分最新一次操作的结果。服务器条目出现后，仍需手动选择当前使用项。

扫码和剪贴板导入适合单条分享链接，订阅地址适合持续更新的配置集合。两者可以同时存在，但要知道每条配置的来源，避免把一次性导入项当作订阅自动维护项。若发现传输方式、TLS 或服务器名称字段缺失，先查看原始提供材料，不要根据另一条看起来相似的配置随意补齐。Android 应用之间的剪贴板与文件访问权限也可能受系统限制，导入失败时要核对实际读到的内容。

理解系统 VPN 提示和分应用范围

点启动后，Android 会显示 VPN 连接授权。该授权允许应用通过系统 VPN 接口接管选定范围的流量，不表示远端服务器已经连通。v2rayNG 常见的 VPN 模式通过虚拟网络接口处理流量，不能直接套用桌面“系统代理开关”的判断方式。若应用还提供仅代理模式，应明确当前模式是否建立 VPN；仅开启本地监听并不会自动让其他应用改用该入口。

一般设备同一时间只能有一个活动 VPN 接管者。另一款 VPN、工作资料中的网络组件或某些本地过滤工具可能与当前连接冲突。先关闭其他接管来源，再重新授权。使用分应用代理时，认真区分“选中的应用走代理”和“选中的应用绕过代理”这两种相反逻辑，保存后按界面要求重建连接。测试时应指定一个应用，不要仅根据状态栏图标判断每个应用都已经纳入范围。

若前台正常、锁屏后反复断开，可在系统电池设置中检查该应用的后台运行限制，并按设备厂商提供的设置允许必要的后台活动。配置“始终开启的 VPN”或“阻止不使用 VPN 的连接”前，应先确认断线时的行为符合预期；后者可能在客户端停止时直接阻断网络。停止使用前先关闭应用内连接，再检查系统 VPN 设置是否仍保留持续接管要求。移动数据与无线网络的 DNS、IPv6 和认证条件可能不同，应分别验证，而不是用一次测试概括全部网络。

订阅管理、内核选择与配置迁移

把订阅更新与手工修改分开管理

订阅是配置集合的来源，不是已经建立的网络连接。更新时客户端获取内容并解析为服务器条目，连接时内核才根据活动条目的参数访问远端。因此，订阅地址无法访问、订阅内容无法解析、某条服务器连接超时应分成三类问题处理。先看更新日志中的网络与解析结果，再看条目是否出现，最后测试活动连接。不要在订阅解析失败时修改路由规则，也不要用更新成功替代连接验证。

建议按来源或用途建立分组，而不是把全部地址塞进一个名称含糊的集合。自动更新可能替换订阅生成的服务器条目，手工调整这些条目之前，先确认客户端是否会保留修改。需要长期固定的配置可另作手工条目，并记录它不再自动跟随原订阅变化。提供方更换地址或认证信息后，应更新来源地址，不要仅反复使用旧条目重连。删除分组前也应确认其中是否混有尚未备份的手工项目。

安全地使用示例与敏感字段

下列地址只展示常见订阅结构。真实地址的路径与查询参数由服务提供方决定，不能照着示例猜测。订阅可能返回编码后的多条分享链接，也可能返回客户端可识别的其他格式；文件能在浏览器显示文字，不代表格式适用于当前导入入口。收到一整份内核 JSON 时，应查找客户端的自定义配置导入功能，而不是把 JSON 粘贴到订阅地址字段。

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

分享问题截图时至少遮住订阅查询参数、认证标识、密码及私人服务器信息。导出完整客户端配置可能同时包含订阅、手工条目、本地监听设置和路由，不应当作普通诊断材料公开发送。请求协助通常只需要错误片段、协议与传输类型、平台、接入模式和复现步骤。若怀疑订阅地址已经泄露，应到提供方管理入口更换访问凭据；只删除本地历史记录不会让已复制出去的地址失效。

内核切换以功能兼容为依据

v2rayN 的内核设置用于选择由哪个内核执行配置，不是性能高低的简单开关。Xray 与 V2Fly 有共同生态背景，但扩展功能、传输实现和参数支持可能不同。应先看当前服务器要求，再看客户端能否为目标内核生成相应配置。一个内核不认识某字段时，切换路由模式不能补足兼容性；同样，换成另一个内核后能启动，也不代表所有原有自定义规则都被完整保留。

切换前记录活动服务器、路由和 DNS 设置，切换后先检查配置生成与内核启动日志，再做单条请求验证。Android 上从 v2rayNG 改用 v2flyNG 应视为更换应用，而不是原应用内部的无缝切换：订阅需要重新添加，VPN 授权和后台策略需要重新确认，应用私有数据不会因为服务器名称相同而自动同步。每次只运行一个接管应用，避免把权限冲突误判为内核差异。

跨平台迁移分三层进行

迁移时先迁移订阅或服务器参数，再迁移路由与 DNS，最后重建本机设置。Windows 的系统代理、Linux 的桌面会话和 Android 的分应用范围不能直接互换。本地端口、配置路径、自动启动项和 TUN 权限属于设备环境，不应盲目随备份覆盖。使用服务器列表中的“导出”或“分享”功能前，确认导出对象是单条配置还是整个分组；目标设备应使用与导出类型对应的导入入口。

完整备份适合在兼容的客户端环境中恢复，跨平台则优先采用客户端明确支持的交换格式。先在目标设备验证一条连接，再批量导入；确认订阅更新、路由和停止连接后的网络恢复都正常后，才停用旧设备。迁移成功的标准不是列表数量相近，而是关键参数正确、活动连接可用、流量范围符合预期，同时保留一条能够撤销改动的恢复路径。

系统代理、TUN 与路由分流

入口接管和内核出站是两个问题

系统代理回答“应用是否把请求发给本地代理”，路由规则回答“内核收到请求后选择哪个出站”。开启全局路由并不会让一个完全忽略系统代理的应用突然经过客户端；开启 TUN 也不表示所有接管流量都必须发往代理服务器。先确认请求进入内核，再讨论它匹配直连、代理或拦截。理解这一区别，可以避免在应用入口错误时反复改动域名规则，造成问题范围不断扩大。

v2rayN 常见的“绕过大陆”“全局”“直连”属于预置路由策略，实际行为取决于当前规则内容、出站标签和数据库。全局策略适合短时确认代理链路，日常分流应根据需要恢复对应策略。“直连”也不等于退出客户端，流量仍可能经过本地入口后由内核直接连接目标。测试时要同时记录系统代理或 TUN 状态，以及路由模式，只有一个“已开启”截图不足以说明请求路径。

读懂规则字段和顺序

下面展示可嵌入兼容内核配置的 routing 片段，不是一份完整启动配置。第一条按域名集合匹配，第二条按私有 IP 集合匹配，均指向名为 direct 的出站。主配置必须存在这个标签，并准备好规则所引用的数据文件。缺少出站定义或数据库时，单独复制片段不能建立可用连接。客户端路由编辑器可能采用另一种存储结构，应使用它提供的字段，而不是直接覆盖整个配置文件。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      }
    ]
  }
}

路由通常按规则顺序匹配，前面的宽泛条件可能覆盖后面的精细例外。特定域名、局域网服务等例外一般应放在会吞掉它们的通配规则之前，但最终顺序仍取决于你的设计目的。同一条规则中写域名和 IP 条件也不能简单理解为任意一个匹配就成立，应核对内核对不同条件组合的语义。未命中规则的默认出站行为要根据完整配置确认，不应由片段中的最后一条规则推断。

DNS 与规则数据库要一起检查

geosite:cn 表示数据库中的域名分类，geoip:private 表示私有地址集合。它们不是自动从互联网实时查询的标签，也不意味着所有域名分类都永久不变。更新路由数据后应确认内核实际加载的是新文件，而不是另一个目录中的旧副本。具体更新入口与引用方法见GeoIP 与 GeoSite 规则文件更新方法；需要理解字段顺序时可继续阅读分流规则实战。

DNS 决定域名如何解析，也会影响哪些 IP 条件能参与判断。示例中的 AsIs 不会为了路由匹配主动把所有域名解析成 IP；若应用只提供域名而规则依赖 IP，应明确选择相应策略并理解额外解析开销。浏览器的加密 DNS、自定义解析器和 TUN 的 DNS 接管还可能改变解析位置。先用域名规则验证目标，再逐步引入 IP 判断，不要一次同时改动所有解析路径。

每次修改先导出路由或保存可恢复副本，再只增加一组规则，重新加载后检查日志中的目标与出站。不要直接编辑客户端运行期间生成的临时配置，它可能在下次切换服务器时被覆盖。验证完成后清理仅用于测试的全局覆盖规则，保留规则用途说明。稳定分流依赖明确的入口、解析与出站关系，而不是堆积更多来源不明的规则。

配置常见问题与分层恢复

按失败位置建立检查顺序

排查时先写下最后一个正常动作：应用能否启动、订阅能否更新、内核能否监听、本地入口能否收到请求、远端能否握手、目标能否返回内容。这个顺序能够把问题限制在相邻两层之间。若日志已经显示本地端口绑定失败，就先处理占用；若没有任何请求记录，就先检查应用代理入口。不要把“连接失败”当作单一错误，也不要一次更换客户端、内核、DNS 和路由后再猜究竟是哪项起作用。

订阅为空、内核启动失败或只有部分应用可用

订阅更新后列表为空，先区分网络获取失败与返回内容无法解析。查看地址是否被复制成了管理页面、末尾是否带入空格，以及分组是否处于被筛选隐藏的状态。若返回的是网页提示或已过期说明，应联系实际提供方处理订阅，而不是对空列表执行连接。只有订阅经过当前代理才能获取时，先用已有可用配置建立连接，再选择对应的更新方式，避免形成“没有配置却依赖配置下载”的循环。

内核启动失败，重点找第一条具体错误，而不是最后一条“进程退出”。监听地址被占用、配置字段不受支持、规则数据缺失和目录无权限各有不同处理方向。更改端口前先确认是否有另一个客户端实例；更换内核前先确认服务器功能要求。配置包含自定义 JSON 时，应先恢复客户端能够正常生成的基本配置，再逐项加回修改。重复点击启动通常只会制造更多时间相近的日志，不会自动修正配置。

浏览器可用而终端不可用，先用显式代理参数验证终端入口；终端可用而浏览器不可用，则检查浏览器扩展、独立代理和受管理策略。只有某个应用失败，还需确认它是否在 Android 分应用范围内，或是否使用独立网络栈。TUN 模式下也应看该请求有没有进入内核，不能因为理论上能够接管就跳过证据。具体差异可查浏览器与终端分别排查的步骤。

握手、解析与间歇性断开分开处理

TLS 握手失败时，核对系统时间、服务器名称、传输方式及提供方要求的参数。不要把跳过证书验证作为常规修复，它会绕过原本用于确认服务端身份的保护。域名解析失败则先确认失败的是服务器域名还是最终目标域名，两者可能使用不同解析路径。若只有大请求或特定网络下失败，应记录网络类型和复现条件，再检查传输、路径 MTU 或 UDP 支持，不要把小页面能打开当作所有流量都正常的证明。

间歇性断开需要观察事件关联：锁屏、休眠、切网、订阅更新还是服务器切换。Android 先确认后台进程是否存活；桌面先看网络恢复后虚拟接口和 DNS 是否重建。能重启恢复不等于定位了原因，应保留中断前后的一小段脱敏日志。日志级别只在必要时间内提高，确认问题后恢复日常级别，避免持续产生大量文件，也减少私人访问目标长期保存在日志中的机会。

请求帮助时提供平台与架构、客户端名称、当前内核、接入方式、错误原文和已经验证的步骤即可。订阅链接、密码和认证标识不属于必要材料。若问题已经收敛到单一设置，可到帮助中心查找对应问答；需要重建最小可用配置时回到使用文档。最终确认应包含正常连接、分流符合预期，以及停用后网络能恢复这三个结果，而不仅是一次页面成功打开。