全平台安装
与订阅配置

准备工作与配置边界

先把客户端、内核、订阅和系统接管分开理解。客户端负责显示界面、保存分组和生成配置；内核负责实际连接与路由；订阅地址用于取得服务器参数；系统代理或虚拟网卡负责把应用流量交给内核。这四层可以分别出错。窗口能够打开，不代表内核已经启动；订阅更新成功，也不代表浏览器已经使用代理。

确认系统、架构与安装入口

打开系统的设备信息，记录操作系统、处理器架构和剩余空间。桌面设备不要只凭外观判断架构，同一种机型可能使用不同芯片。进入客户端下载页后，先选平台，再选对应包。Windows 的桌面版与 WPF 版属于不同界面入口；macOS 区分 Apple Silicon 与 Intel；Linux 还要区分软件包格式。

Android 优先选择适配设备的 arm64 包，无法确认架构时再查看通用版说明。包能下载并不等于系统一定能够运行，最低系统要求以下载页和安装器提示为准。遇到架构不符，应回到下载页换包，不要反复调整代理设置。安装错误与网络连接错误需要分开处理。

准备订阅地址与访问条件

从已有服务的管理页面复制完整订阅链接，确认账户仍有效、套餐允许使用、设备数量没有超限。本站提供配置说明，不生成订阅内容。链接通常携带账户访问凭据，复制后不要发到公开讨论区；分享截图前，也要遮住地址、二维码和个人备注中的敏感内容。

区分订阅地址和单条分享链接。订阅一般通过网络请求取得一组配置，单条分享链接则直接包含一个服务器的参数。把单条分享内容贴进订阅地址字段，可能得到格式错误；把账户管理网页当订阅地址，也可能下载到网页而不是节点数据。应使用服务页面明确标注的客户端订阅入口。

检查链接前后是否混入空格、换行或中文标点。带查询参数的地址必须完整保留，不能只复制问号前面的部分。不要为了让地址看起来简短而删除参数，也不要把订阅凭据贴到在线转换工具。需要转换格式时，先确认来源、用途以及是否会把完整地址提交给第三方。

建立一次只改一项的验证流程

启用系统自动校时，再检查设备日期和时区。证书验证与部分协议认证依赖正确时间，手动把时间拨快并不是解决连接错误的方法。确认当前网络已经完成登录；酒店、校园或访客网络的认证页面没有通过时，客户端可能只表现为超时，看起来像订阅或服务器故障。

暂时退出其他代理和占用虚拟网卡的连接工具，保留原设置记录。首次验证只启用一个客户端、一个服务器和一种接管方式。先导入订阅，确认内核启动，再开启系统代理，最后才尝试 TUN。这样出现问题时，可以明确指出是哪一步改变了结果，而不是同时面对多层规则。

选两个用途明确的测试目标：一个应直连的日常站点，一个按现有规则应走代理的服务。浏览器能显示缓存页面不能证明连接正常，测试时主动刷新，并结合客户端日志观察请求。也不要只依据节点旁的测试结果判断全部应用，它通常只反映某种探测请求的执行情况。

最后确认工作网络或组织设备的使用要求。受管理设备可能限制本地代理、网络扩展或管理员权限，遇到明确的策略阻止应联系设备管理人员。不要通过关闭系统防护绕过限制。后续各平台章节都按下载、安装、导入、接管、验证的顺序展开，可在完成一环后再进入下一环。

Windows：安装 v2rayN

Windows 先从对应平台下载区选择 v2rayN。桌面版采用跨平台界面，WPF 版保留经典桌面操作方式。按照个人使用习惯选择即可，不必为了订阅导入同时安装两套。以下以“订阅分组”“系统代理”等功能名称描述操作，具体菜单位置可能随界面调整。

完成安装并确认内核能启动

运行安装器时，检查目标目录是否可写；使用需要解压的分发形式时，先完整解压，再从目标文件夹启动。不要直接在压缩包预览窗口中运行程序，也不要只拖出主程序文件。相关组件和配置文件可能依赖相对目录，文件缺失会导致窗口出现但内核启动失败。

首次打开先查看日志区域，确认没有组件缺失、配置解析失败或端口占用。若程序提示缺少运行环境，按提示补齐适合该构建的组件，再重启客户端。不要从不明页面复制同名动态链接文件塞进目录，这既不能保证依赖匹配，也会让后续排错失去清晰的安装基线。

普通系统代理通常不需要管理员运行。先以普通权限完成导入与浏览器测试，只有启用需要提升权限的功能时再按提示操作。如果换到管理员身份后配置列表变空，先检查是否启动了另一份程序或使用了不同配置目录，不要立即再次导入并覆盖已有数据。

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

打开订阅分组设置，新建分组，在备注中写容易识别的用途，在地址栏粘贴完整订阅链接。启用该分组的更新选项，先保存，再执行更新订阅。自动更新间隔用于控制后续刷新，不会代替首次手动更新。首次先使用默认 User-Agent；只有服务方明确要求时再填写指定值。

更新结束后切回服务器列表，确认当前没有被其他分组或搜索条件过滤。选择一条服务器并设为活动项，再看日志是否生成了新配置。若订阅里包含不受当前内核支持的字段，服务器名称仍可能出现，但启动阶段会报错；此时应检查协议与内核支持情况，而不是重复复制地址。

更新订阅若提供直连和经过代理两种方式，首次可先尝试当前网络能够访问的方式。经过代理更新依赖一条已可用的连接，不能在全部服务器失效时凭空恢复订阅。保留原分组，查看更新返回信息，再决定更换获取方式，避免先删除全部服务器后丢失可用的恢复路径。

设置系统代理并核对端口

选择自动配置系统代理，让遵循 Windows 系统代理的应用使用本地监听地址。打开系统设置中的代理页面，核对手动代理地址与端口是否符合客户端当前设置。本地端口不是服务器的远端端口，也不是订阅地址中的端口；三个位置用途不同，不能相互照抄。

保持路由使用适合当前需求的预设，先用浏览器发起新请求。若浏览器仍失败，查看是否安装了单独控制代理的扩展，或者浏览器自身指定了另一地址。系统代理生效范围取决于应用，不能因一个程序直连就断定内核失效。需要接管这类程序时，再阅读系统代理与 TUN章节。

处理 Windows 特有的退出与权限问题

开启 TUN 前，保存正在进行的网络任务，再按客户端提示提升权限。虚拟网卡创建失败与服务器连不上是两种问题：前者重点看权限、驱动和网络工具冲突，后者才检查节点与路由。不要一看到错误就同时重装客户端、删除网卡和重置系统网络，应先保留具体报错。

退出客户端时，先清除系统代理，再结束程序。若意外关闭后浏览器不能访问网络，打开 Windows 代理设置，检查是否仍指向已停止监听的本地端口。关掉残留的手动代理后测试直连；能够恢复说明问题在接管状态，不必因此改动订阅或删除全部配置。

最后设置开机启动时，区分启动应用与自动开启接管。先验证一次重启后的行为，再决定是否自动连接。多用户电脑也要在实际使用的账户下检查代理设置。需要迁移配置时，先退出客户端并备份，不要在两个运行中的实例之间直接覆盖配置文件。

macOS：安装与网络授权

macOS 使用 v2rayN，先打开“关于本机”查看芯片。显示 Apple 芯片的设备选择 Apple Silicon 构建，显示 Intel 处理器的设备选择 Intel 构建。进入macOS 下载区按芯片取包。架构选择影响程序能否运行，不会改变订阅内容，因此不要用修改协议的方式处理启动错误。

把应用放入稳定的安装位置

打开磁盘映像后，按安装界面将应用放入“应用程序”目录，再从该目录启动。不要长期从已挂载的映像或临时下载目录运行。稳定的安装位置有利于系统识别权限与启动项，也能减少更新后出现两个同名应用、误开旧副本或找不到配置位置的问题。

首次启动若出现系统安全提示，先确认安装包来源与应用名称，再到系统设置的隐私与安全区域查看可执行的授权操作。不同系统版本的入口可能不同，应以系统实际提示为准。不要批量关闭系统安全机制，也不要为了消除提示而运行来源不明的终端命令。

启动后查看日志，确认内核正常加载。若提示应用不能运行，先检查系统要求、芯片架构和安装是否完成；若窗口正常而内核报错，再按具体错误查组件或配置。将这两个阶段分开，能避免把系统兼容问题误认为订阅服务不可用。

导入订阅并建立第一条连接

在订阅分组设置中新增分组，填备注和完整地址，保存后手动更新。粘贴地址时注意剪贴板是否来自密码管理器或富文本页面，末尾不要留下空格。完成更新后选择活动服务器，先保留默认的连接参数，不要擅自修改订阅内的传输方式、服务名称或证书相关字段。

若更新后出现多个类似名称的服务器，先根据服务说明选择用途，不要把名称相同理解为配置完全相同。订阅更新可能替换服务器参数，手动修改的内容也可能在下次更新时被覆盖。长期需要自定义的配置，应使用独立分组或客户端支持的持久化规则，并记录改动原因。

检查当前网络服务的代理状态

开启客户端的系统代理功能后，进入当前网络连接的详情查看代理设置。macOS 的代理配置与具体网络服务有关，Wi-Fi 和有线网络可能保留不同状态。插入扩展坞或切换网络后，如果浏览器突然不再经过代理，应先确认正在使用的网络服务，而不是立即换服务器。

分别理解网页代理、安全网页代理和 SOCKS 代理字段。客户端若自动配置了其中几项，应保持与其监听方式一致；不要为了“全选”而给所有协议填同一个端口。使用手动代理的应用，需要明确选择 HTTP 或 SOCKS 类型，类型与监听端口不匹配时通常会立即连接失败。

浏览器测试成功后，再检查实际需要使用的应用。有些应用读取系统代理，有些使用自己的网络设置，还有些仅在启动时读取一次。修改代理后，可以先退出并重新打开目标应用，再看日志是否出现请求。不要把旧连接仍在复用的结果当作新设置没有生效。

按需使用 TUN 并验证恢复路径

如果所选构建提供 TUN 功能，按客户端提示完成所需授权，再观察日志中的虚拟接口与路由初始化结果。系统没有提供的选项不要通过复制其他平台命令强行补齐。只有系统代理无法覆盖目标应用时，才需要进一步评估 TUN，日常浏览器使用不必先增加接管层。

睡眠唤醒后若出现连接停滞，先暂停并重新开启接管，再测试当前网络是否已经恢复。唤醒可能伴随地址、网关或 DNS 改变，旧连接失效不代表订阅需要更新。如果每次唤醒都失败，记录是否只发生在 TUN、某个网络服务或特定应用，以便缩小范围。

退出或卸载前，关闭 TUN 和系统代理，并在当前网络服务中核对残留状态。随后测试直连，确认恢复正常再移除应用。需要保留配置时单独备份，但不要将整个配置目录公开分享。遇到网络切换后反复掉线，可结合疑难解答继续检查权限与接管冲突。

Linux：软件包与桌面代理

Linux 先确认发行版的软件包体系和设备架构，再进入Linux 下载区选择 v2rayN。常见 Debian 系使用 deb，常见 RPM 系使用 rpm；同一种格式还可能分为 x64 与 arm64。桌面图形客户端需要可用的桌面环境，不能把“安装包能够解包”当作图形程序已经具备运行条件。

通过系统包管理器完成安装

优先使用发行版的软件安装器打开下载包，让包管理器处理依赖。若安装器提示依赖缺失，先查看具体依赖和系统版本支持情况，再通过发行版正常的软件源处理。不要混用其他发行版的软件源，也不要强制忽略依赖安装，否则后续可能变成窗口无法启动或系统组件冲突。

确认架构可使用下面的命令。它只显示本机机器类型，不会修改系统设置。常见输出中的 x86_64 对应常见 x64 包，aarch64 对应常见 arm64 包。若运行在容器、远程桌面或兼容层内，还要区分宿主系统与实际运行环境，不应仅凭宿主硬件名称选包。

uname -m

安装完成后从桌面菜单启动，先以普通用户运行。若窗口打不开，可在终端启动已安装的程序以读取错误，但不要为了绕开错误直接使用管理员账户运行整套图形客户端。普通账户与管理员账户的配置目录不同，混用会造成订阅、权限和文件归属交叉，之后更难维护。

导入订阅并检查本地监听

打开订阅分组，新增备注与地址，保存并更新，随后选择活动服务器。确认内核启动后再处理桌面代理。若日志提示端口占用，先退出其他代理程序和重复实例。对于常见默认示例端口，可以用下面的命令查看监听情况；若本机设置不同，应把端口改成实际值。

ss -ltnp 'sport = :10808'
ss -ltnp 'sport = :10809'

命令没有结果可能表示该端口没有监听，也可能是客户端使用了其他端口；部分进程详情还受权限限制。先核对客户端设置，不要只凭示例端口推断故障。正常本机使用应优先绑定回环地址，只有明确需要供局域网设备使用时，才评估开放监听与防火墙规则。

区分桌面代理和终端环境变量

不同桌面环境对系统代理的保存方式不同，客户端的自动配置未必覆盖所有应用。开启系统代理后，进入桌面网络设置核对模式和端口，再使用浏览器验证。托盘图标是否出现，与内核是否工作也不是同一件事；缺少托盘支持时，应从窗口和日志判断运行状态。

终端程序通常有自己的代理读取规则，不一定遵循桌面设置。需要测试时，可以只为单条命令指定代理，避免先修改整个登录环境。下面示例假定 HTTP 监听在 10809，SOCKS 监听在 10808；实际使用必须先核对端口。测试目标只是返回网页，不代表所有业务协议均可用。

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

第二条中的 socks5h 表示由代理侧处理目标域名解析，区别于某些本地解析方式。终端测试成功而浏览器失败时，重点查桌面代理或浏览器设置；两者都失败时，再查监听、活动服务器和日志。已经设置环境变量的终端，即使桌面代理关闭，也可能继续指向本地端口。

谨慎处理 TUN、权限与默认路由

启用 TUN 取决于客户端构建、系统能力和授权方式，应按实际界面提示操作。若创建虚拟接口失败，先查看日志是否指向权限或设备支持，不要把整个程序永久改成高权限启动。远程连接的设备尤其要保留恢复途径，修改默认路由可能中断正在使用的远程会话。

如果安装了其他 VPN、容器网络或额外防火墙管理工具，应逐一核对路由和规则归属。不要直接清空系统防火墙来尝试恢复连接，那可能破坏其他服务。退出客户端后再测试直连，并检查桌面代理与终端变量是否残留；必要时重新打开终端，用干净会话重新验证。

升级前备份订阅分组和自定义规则，通过同一种包管理方式更新。若更新后仅界面异常，先记录桌面环境与错误输出，不要立刻删除配置；若内核解析失败，则检查自定义参数是否与当前支持范围一致。图形问题、软件包问题和网络问题分开记录，才能确定应该回退哪一层。

Android：订阅与 VPN 授权

Android 优先使用 v2rayNG，它采用 Xray 内核；需要 V2Fly 内核且配置适配时，可选择 v2flyNG 作为备选。进入Android 下载区后，先取适合设备的 arm64 包，无法确认或设备情况特殊时再查看通用版。不要为了比较界面而同时启动两个客户端的连接服务。

安装应用并处理系统许可

从下载文件打开安装器时，系统可能要求允许当前文件来源安装应用。确认来源后，仅为这次使用的浏览器或文件管理器按需授权。安装失败先查看系统提示：存储不足、架构不符、系统要求和已有应用签名冲突，分别对应不同处理方法，不能用重新导入订阅解决。

已有同名应用时，不要在没有备份的情况下直接卸载。先确认能否正常覆盖安装，以及现有订阅和规则是否已保存。若系统明确提示签名不一致，应核对安装来源，停止混装。应用数据可能随卸载删除，无法仅依靠服务器名称重新还原完整的订阅地址与本地设置。

建立订阅分组并选择活动项

打开订阅设置，新增条目，填写备注和地址，启用更新后保存，再执行更新订阅。某些界面把服务器列表与订阅管理分开放置，应确认更新的是目标分组。若剪贴板里是单条分享链接，应使用相应导入功能，而不是放入需要网络获取数据的订阅地址栏。

更新成功后返回列表，选择一个活动服务器，再启动连接。备注只影响显示，不参与认证；地址、端口、用户标识、传输与安全参数则必须匹配服务端。不要因为名称写着某种用途，就推断它支持所有协议或应用。服务方更新订阅后，也应重新检查活动项是否仍存在。

设置中的“允许不安全连接”不是修复网络错误的通用开关。遇到证书错误，应先检查系统时间、目标域名和服务说明，保留证书验证。随意关闭验证会改变连接的安全边界，而且无法解决地址失效、端口不通或账户停用等问题。

理解本地 VPN 接管与应用范围

首次连接时，系统通常会显示 VPN 连接请求，确认由刚安装的客户端发起后再授权。这项授权用于在设备上建立流量接管通道，并不表示已经验证远端服务器可用。系统出现连接标识后，仍要发起实际请求，并查看应用日志，确认内核完成了连接过程。

Android 的本地 VPN 机制与桌面的系统代理操作不同，不需要再照抄 Windows 代理页面的字段。系统一般只允许一个此类 VPN 服务处于活动状态，其他使用同一机制的网络工具可能抢占连接。发生自动断开时，先查看是否启动了其他服务，而不是先删除订阅。

如果启用了分应用代理，确认当前模式是“仅选中应用经过代理”还是“选中应用绕过代理”。这两种列表含义相反，误解后会出现浏览器能用、其他程序不能用的现象。修改范围后重新建立连接，再打开目标应用；必要时先用不筛选应用的基线配置验证一次。

检查网络切换、休眠与域名解析

从 Wi-Fi 切到移动网络后，原连接可能需要重建。先确认移动数据本身可用，再重新连接客户端；某个 Wi-Fi 正常而移动网络失败时，记录网络差异，检查是否涉及 IPv6、目标端口或 DNS 路径。不要把自动重连当作无限重试，持续失败时应暂停并查看首条相关错误。

系统的专用 DNS、应用自身的加密 DNS 和客户端 DNS 可以同时存在，但职责未必相同。遇到域名失败而其他请求正常时，先记录这些设置，再逐项验证。不要同时更改全部解析入口，否则即使恢复连接，也无法确定是哪一个设置产生影响。

最后测试停止连接后的状态。若启用了始终开启 VPN 或阻止未经过 VPN 的连接，客户端停止后仍可能无法直连，这是系统策略的结果。根据实际需要保留或调整该策略，不要把它误判为网络损坏。更换客户端前，先停止旧服务，再导入新应用，分别验证协议支持与后台稳定性。

系统代理、TUN 与流量接管

先判断应用如何发送流量，再选接管方式。系统代理通常只是告诉应用“代理入口在哪里”，应用是否使用由自身决定；TUN 则通过虚拟网络接口和路由把匹配流量交给处理程序。两者都不是远端服务器，也不直接决定某个域名最终直连还是代理，后者主要由路由规则控制。

分清接管范围与出站规则

“开启系统代理”与“使用全局路由”不是同一个操作。前者解决应用请求是否进入客户端，后者解决进入之后选择哪种出站。只改全局路由，不会强迫一个忽略系统代理的应用改变网络路径；只开启 TUN，也不表示所有请求必然经过远端代理，直连规则仍可能生效。

常见的清除系统代理、自动配置系统代理和不改变系统代理，可理解为不同管理动作。清除通常移除当前受管理的系统代理设置；自动配置写入客户端监听入口；不改变则保留当前系统状态。具体行为以客户端提示为准，尤其已有组织策略或手动设置时，操作前先记录原值。

按最小范围逐步启用

先让系统代理下的浏览器正常访问，再测试目标应用是否遵循设置。若目标应用能手动填代理，可以先使用本地 HTTP 或 SOCKS 入口，验证内核与服务器没问题。这样即使随后 TUN 失败，也能把问题限定在系统接管层，而不是重新怀疑整条订阅链路。

开启 TUN 前关闭其他同类接管工具，保存工作，再按提示授予需要的权限。启动后观察是否成功创建接口、安装路由与初始化 DNS。某些构建可能采用不同的辅助组件，因此不要跨平台照抄驱动处理步骤。日志若停在接口初始化阶段，应先处理本机问题。

TUN 与系统代理是否需要同时开启，取决于客户端实现和使用场景，不宜一概而论。基线测试尽量只保留一种主要接管路径；如需并用，要确认本地代理连接不会被再次错误接管。反复连接、资源占用异常或出口来回变化时，应先退回单一路径检查。

检查 UDP、局域网与虚拟网络

浏览网页成功不能证明 UDP 应用可用。目标应用是否使用 UDP、所选协议和服务端是否支持、客户端入站是否接管，都需要分别满足。不要看到 UDP 失败就改成全局路由；规则只能选择出站，无法补上服务器没有提供的能力。应先核对服务说明，再检查日志中的连接类型。

打印机、文件共享和局域网管理页面通常需要保留本地可达路径。启用 TUN 后这些资源不可用时，先检查局域网地址是否被错误送往远端，再看客户端的排除规则。组织内网可能使用多个私有网段，不能只处理家用路由器所在的一个网段就认为覆盖完整。

虚拟机、容器和其他 VPN 也可能添加网卡、DNS 与路由。发生冲突时，记录当前开启的网络工具，并逐个暂停验证，不要清空所有路由。远程办公或远程管理场景应尤其谨慎：修改接管规则前，确认有本地恢复方式，避免把维持当前会话的路径一起改掉。

用请求路径判断结果

验证时分别看应用、监听入口、路由命中和远端连接。应用没有请求进入日志，重点查接管；请求进入但命中直连，重点查规则；命中代理后连接超时，才继续查服务器和网络。详细的开启边界可参照v2rayN TUN 模式说明，不要把 TUN 当作所有连接故障的统一答案。

关闭连接后再次验证同一应用，确认结果符合预期。浏览器可能复用长连接，部分应用也保留自己的连接池，需要重新建立请求才能观察新路径。记录一次成功基线，再逐项加入自动启动、分应用范围或复杂排除规则，比一次堆入全部功能更容易保持可维护性。

路由分流与 DNS 配合

路由的任务是为已经进入内核的请求选择出站，DNS 的任务是把域名解析为地址，两者会互相影响但不能混为一项。先明确使用目标：哪些服务直连，哪些经过代理，哪些需要阻断；再选择接近目标的预设。首次不要把未知来源的大型规则集整份覆盖进当前配置。

先用预设建立稳定基线

常见的全局、绕过大陆和黑名单等名称属于客户端预设，实际内容可能随规则资源与设置变化。全局一般倾向把普通目标送往代理，但仍可能保留必要的本地例外；绕过大陆依赖域名与地址分类；黑名单的具体含义则要查看实际规则，不能只凭名称推断所有目标的去向。

切换预设后，用准备好的直连与代理目标分别发起请求，查看路由命中。不要只测试出口地址，因为它只能反映该次请求的路径。一个应用可能同时访问认证、内容、更新等多个域名，主页正常而某个功能失败时，应查具体失败请求，而不是立刻把整套配置改为全局。

理解规则顺序与域名匹配

多数规则按顺序判断，先命中的规则会决定处理方向。为单个目标添加例外时，应放在会覆盖它的宽泛规则之前。域名规则通常比随意固定某个解析 IP 更便于维护，因为服务地址可能变化；但如果应用直接访问 IP，域名规则又可能没有匹配条件，需要另行检查。

下面是 Xray 风格的路由片段，演示私有地址与指定域名直连。它不是可单独运行的完整配置，出站标签必须与现有配置一致。图形客户端通常会生成配置，优先通过其路由编辑界面表达同样含义；不要直接覆盖运行时文件，避免下次启动时被重新生成。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      }
    ]
  }
}

其中 domain 匹配可覆盖指定域及其子域，精确主机可考虑 full 匹配。geosite 和 geoip 则依赖相应资源文件，分类名称也必须实际存在。AsIs 并非“永远不解析域名”，它描述的是路由阶段的策略，其他连接和 DNS 环节仍可能发生解析，不能仅靠一个字段判断完整请求路径。

分别检查目标解析与服务器解析

客户端既可能需要解析用户访问的目标域名，也可能需要先解析代理服务器自身的域名。后者若依赖尚未建立的代理通道，就可能形成启动循环。看到初始化时持续解析失败，应先区分是哪一个域名；不要把所有 DNS 请求不加区分地强制送入尚不可用的代理。

系统、浏览器和客户端都可能提供 DNS 设置。浏览器启用独立的加密解析后，客户端日志中未必出现预期的系统 DNS 请求；启用 TUN 后，客户端又可能接管部分解析流量。排错时先画清谁发起解析、谁返回结果、请求走哪条路，再决定调整哪一层。

修改规则或 DNS 后，旧缓存和已有连接可能继续生效。先建立新的请求，必要时重启目标应用，再观察结果。不要因为刷新一次页面没有变化就继续叠加规则；叠加过多临时修改，会把真正的解析问题隐藏在复杂路由之下，恢复时也难以判断哪些设置需要保留。

处理 IPv6 与分流边界

同时具备 IPv4 与 IPv6 的网络中，应用可能优先使用不同地址族。某个域名时好时坏时，记录日志中的目标地址，并检查对应路径是否都可用。临时限定一种地址族可以帮助定位，但不应未经分析就把长期禁用 IPv6 当作通用方案，尤其在依赖它的网络环境里。

对组织内部域名，通常需要使用组织提供的解析路径；公共解析器未必知道内部记录。遇到内网页面打不开，应同时检查域名解析和内网路由，不要只添加直连规则。反过来，解析正确也不能保证路由可达，这两个环节必须分别验证。

一次只新增一条有明确目标的规则，备注用途并保留修改前的配置。先阅读国内外分流设置建立预设基线，再按自定义规则语法处理例外。规则越具体，验证目标越清楚，也越容易在服务地址变化时找到需要维护的位置。

配置常见问题与排错顺序

排错先描述现象，再决定改哪里。记录平台、客户端、接管方式、活动服务器和错误发生的操作，例如“更新订阅失败”或“开启 TUN 后内网不可达”。不要只写“连不上”，因为订阅获取、内核启动、流量接管和远端访问属于不同阶段，需要的证据也不同。

订阅更新失败或没有服务器

先检查地址完整性和账户状态，再看更新返回的是网络错误、网页内容还是解析错误。网络错误重点查当前获取路径；网页内容可能来自登录页或错误页；解析错误则要检查订阅格式与客户端支持。返回了内容并不代表内容一定是有效订阅，不应只依据“下载成功”四个字判断。

更新后列表为空，先清除搜索条件并切换到目标分组，确认该分组允许更新。保留更新前的配置，不要连续删除重建。若只有部分服务器消失，可能是服务方调整了订阅，或者特定配置无法解析。记录被省略的类型与错误信息，再与服务说明对照，而不是手工补造节点参数。

内核启动失败或本地端口异常

找到本次启动后最早出现的相关错误。端口占用先查重复实例；配置字段错误先回退最近修改；文件缺失先检查安装是否完整。后续大量连接失败可能只是首个启动错误的连锁结果，逐条处理后面的超时并不能修好未启动的内核。

如果使用多个分发形式，核对当前运行路径，避免配置改在一份程序里，实际启动却是另一份。升级后不要立刻恢复整个旧目录覆盖新程序，应先验证基础启动，再按客户端支持的方法恢复配置。可执行文件、运行组件和用户设置应分开理解，不能把所有文件都当作配置。

浏览器可用但其他应用失败

先判断目标应用是否读取系统代理，以及是否有独立代理或分应用排除。日志没有对应请求，通常应从应用到客户端这一段查起；已有请求且明确命中代理，再检查协议、远端连接和应用业务。需要 TUN 时按前一章逐步启用，不要先改订阅里的认证字段。

网页可用而语音、游戏或实时功能失败时，继续检查 UDP 与服务支持，不要用网页测试结果替代其他协议。下载任务失败还可能涉及应用内独立网络栈或多个域名。记录具体失败功能和时间点，再查相邻日志，比不断切换服务器更有针对性。

握手错误、超时与局部失败

证书或握手错误先检查系统时间、服务器名称与订阅是否最新，再看当前内核是否支持对应参数。REALITY 配置中的公钥、服务名称及相关标识需要与服务端一致，不应凭经验随意替换。订阅管理的服务器参数发生变化时，优先更新并联系提供方确认，而不是关闭安全验证。

连接超时要区分服务器地址不可达、目标访问超时与 DNS 超时。只在某个网络失败时，记录 Wi-Fi、移动网络或有线连接的差异；只在某个服务器失败时，使用同一接管和路由设置比较其他服务器。固定其余条件才能让对照测试有意义，否则结果难以解释。

保存证据并恢复可用基线

准备反馈时保留错误时间、操作步骤与经过遮盖的日志。移除订阅链接、用户标识、二维码和账户信息；日志里的目标域名也可能反映个人使用内容，应按实际需要裁剪。不要为了求助直接打包整个配置目录，更不要把包含凭据的备份上传到公开位置。

恢复时先撤回最近一项改动，再回到单客户端、单服务器、单接管方式的基线。保留成功设置的简短记录，之后逐项恢复自定义规则和自动启动。日常问题可继续查疑难解答；需要重新走一遍操作顺序时，返回快速上手教程，不必先重装整套环境。