V2Ray 进阶配置手册

01 · 订阅与条目

订阅分组与服务器过滤

订阅地址是用于取得服务器配置的入口，分组是客户端本地整理条目的方式，二者不能等同。一个分组通常关联一个来源，也可能保存手动添加的服务器。进阶设置之前，先把“来源、显示名称、使用目的”分开记录：来源用于更新，名称用于识别，用途用于筛选。客户端不会因为分组叫“办公”就自动让办公软件使用其中的服务器，实际流量仍由当前活动服务器、路由及代理接管方式共同决定。

先建立可追溯的分组

在 v2rayN 的订阅分组设置中新增分组，填写简短且稳定的备注，再粘贴完整订阅地址。若地址带有查询参数，必须整体保留；复制时混入换行、空格或网页标点，都会改变请求结果。保存后只更新这个分组，检查更新提示与条目数量变化，再确认服务器的协议、地址和端口是否完整。不要同时添加多个来源并立即批量更新，否则遇到空列表时很难区分是地址错误、请求失败，还是来源本身返回了空内容。

订阅链接可能包含账户访问凭据，截图、日志分享和配置导出前都应隐藏完整地址。正常整理不需要把订阅发送给陌生的转换工具。若来源提供客户端专用格式，优先使用与当前客户端匹配的入口；内容能够在浏览器显示，并不代表客户端可以解析。网页登录页、到期提示和错误页都有可能返回成功的网络状态，却不是有效的服务器列表，应结合客户端更新日志判断，而不是只看页面是否打开。

显示过滤与更新过滤的区别

列表搜索通常只是临时隐藏不匹配的条目，取消搜索后仍可看到全部服务器；某些订阅分组中的过滤设置则会影响导入结果，更新后被排除的服务器可能根本不会进入本地列表。操作前先看字段说明，确认过滤作用于显示还是更新。建议先用普通关键词验证，例如按备注中的地区标记查找；只有界面明确支持正则表达式时才使用正则，不能把所有输入框都当成同一种匹配器。

以支持正则的备注过滤为例，办公|备用表示匹配任一词，^办公表示从备注开头匹配。大小写规则、空备注处理和排除语法要以该字段实现为准，不宜照搬其他工具的写法。保存复杂过滤前，先在现有列表确认至少有一条符合条件，再单独更新一次。若结果突然为空，先撤销过滤并重新更新；不要立即删除整个分组，以免把本地备注和手动补充条目一并丢失。

为更新与切换留出回退点

订阅更新可能覆盖服务器参数、替换标识或移除来源已删除的条目。需要长期保留的手动修改，宜复制到单独的本地分组，并记录修改原因，不要直接依赖订阅内的条目长期承载定制参数。更新完成后，重新确认活动服务器是否仍然存在，再做一次实际网页请求。延迟测试只能说明某种探测路径的结果，不等于完整业务可用；节点取舍可继续阅读延迟、倍率、地区与协议类型的取舍方法。

02 · 匹配与分流

V2Ray 路由规则实战

路由解决的是“已经进入内核的连接，应该交给哪个出站”。它不负责让所有应用自动进入客户端，也不等同于系统代理开关。应用若绕开本地代理，内核中的规则就没有机会匹配。排查分流时，首先确认请求确实进入客户端，再检查目标域名或地址、命中的规则以及最终出站。把接管、匹配和转发拆成三个环节，比直接更换整套路由预设更容易定位问题。

理解规则顺序与匹配字段

常见内核按规则顺序寻找匹配项，前面的宽泛规则可能遮住后面的精确规则。因此，把明确的本地服务和特定域名放在前面，再安排较大的地址集合，最后才处理默认方向。同一条规则里多个不同类型的条件通常需要同时成立；同一域名列表里的多个值则用于表达候选匹配。不要把一个域名条件和一个不相关的地址条件放在同一条规则中，却期待它们分别命中。阅读配置时应按单条规则的完整条件判断。

域名写法也有边界：full:example.com只匹配指定域名，domain:example.com匹配该域名及其子域名；普通字符串可能执行更宽泛的关键词匹配。若只希望处理某个服务，优先精确域名或明确的域名后缀。直接填写 IP 规则时，注意目标可能使用多个地址，甚至在不同网络返回不同结果，单个地址规则不能可靠代表整个网站。需要依赖地理数据库的规则，还必须确认对应数据文件存在且能够被当前内核读取。

从最小规则集开始验证

下面是 Xray 风格的路由片段，不是完整配置。它将测试域名和内网地址交给直连出站，其他连接保持原有默认行为。示例假定已有标签为 direct 的出站；如果实际标签不同，必须一并修改。合并到自定义配置时，应保留原有入站和代理出站，不要直接用片段覆盖整个文件。图形界面中的路由编辑器若会自动生成这些字段，应在界面中修改，避免下一次启动又被覆盖。

{
  "routing": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "domain": ["domain:example.com"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "ip": ["127.0.0.0/8", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16"],
        "outboundTag": "direct"
      }
    ]
  }
}

域名解析策略不是路由预设

AsIs表示路由阶段尽量按已有目标信息判断，不主动为了 IP 规则解析域名。IPIfNonMatch是在域名未匹配时尝试解析，再进行地址匹配；IPOnDemand则可能在遇到地址条件时提前解析。解析策略会改变查询次数和匹配结果，但不会自动把 DNS 请求送往正确的服务器。使用地址集合之前，应先确认 DNS 设置和解析路径，再决定是否需要让路由阶段主动解析，避免为一个本可用域名表达的规则引入额外依赖。

验证时选一个目标，只发起一次新请求，查看访问日志中的目标与出站标签。浏览器已有连接可能继续复用旧路径，修改规则后需要关闭相关连接或重新打开应用测试。如果域名规则始终不命中，检查应用是否只交给内核一个 IP，以及嗅探功能能否获取域名信息；不能仅靠反复调整规则顺序解决信息缺失。系统代理模式的基础区别见代理模式说明，连接后仍无法访问则按逐项排查清单检查。

03 · 查询与解析路径

DNS 配置优化

DNS 设置不能只理解成“换一个服务器地址”。一次访问可能涉及应用自身的解析器、操作系统解析器、客户端内置 DNS，以及远端代理处理目标域名时使用的解析路径。浏览器启用加密 DNS 后，还可能不再使用系统的常规 DNS 请求。优化的第一步是标出谁在查询、查询发往哪里、结果供谁使用。只有请求确实由某个模块处理，修改那个模块的设置才会产生效果。

区分引导解析和业务解析

代理服务器地址若使用域名，连接代理之前就需要得到它的真实地址，这一步属于引导解析。若把所有查询都强制交给尚未建立的代理，可能出现“要先连代理才能解析代理地址”的循环。处理方式是为服务器域名保留能够直接工作的解析路径，或者使用来源明确提供的服务器地址；不要自行把域名解析出的某个地址永久写死，因为来源可能调度或更换地址。业务网站的解析则应结合实际出站需求独立设计。

在 v2rayN 中调整 DNS 前，先记录当前路由预设、内核类型和 DNS 编辑方式。有的界面区分普通代理和 TUN 的 DNS 模板，有的高级入口允许直接编辑内核配置；只改了未被当前模式使用的模板，不会改变运行结果。保存后重新启动相关核心，并从日志确认配置成功加载。若出现字段不识别，先恢复原配置，核对当前内核支持的语法，不要用其他内核的同名设置进行猜测式替换。

读懂常用参数的影响

下面展示常见 Xray 内置 DNS 的最小字段组合，只用于说明结构。公共解析地址不是对所有网络的推荐答案，应先确认当前网络可达。UseIPv4用于明确只查询 IPv4 的测试条件，不应作为所有环境的永久设置；需要 IPv6 时，应在系统、网络与代理路径均可用后再恢复相应查询策略。此片段也不负责接收系统的所有 DNS 请求，更不自动实现 TUN 下的 DNS 接管。

{
  "dns": {
    "servers": ["1.1.1.1"],
    "queryStrategy": "UseIPv4"
  }
}

按现象逐层排查

如果所有域名都失败而数字地址可达，先检查解析器连通性与查询出站；如果只有特定域名失败，检查域名分配规则、缓存及上游返回结果；如果解析成功但连接超时，重点转向所获地址的实际可达性。加密 DNS 的证书验证依赖正确的系统时间，使用域名形式的解析服务还可能增加引导解析需求。测试时一次只换一个变量，保留查询耗时和错误类型，不要同时切换解析器、路由策略与代理节点。

IPv6 问题尤其容易与 DNS 混淆。拿到 IPv6 地址不代表本地网络或代理出站可以成功连接该地址；反过来，全面关闭 IPv6 也可能影响原本可用的服务。应先在可控测试中限制查询类型，观察失败是否随地址族变化，再决定修复网络还是调整策略。切换 Wi-Fi、有线网络或移动网络后，必要时重建连接并清理相关缓存；浏览器与系统各有缓存，只重启客户端未必清除了全部旧结果。

04 · 流量接管

TUN 模式的启用与回退

TUN 是通过虚拟网络接口接收 IP 数据包的接管方式，适用于不遵循系统代理设置的应用，但它并不是一种代理协议。进入 TUN 的数据仍要经过路由、DNS 处理和出站连接，最终能力取决于实际后端。v2rayN 可以由专门的 TUN 后端承担接管工作，因此不能把界面上的 TUN 开关直接理解为 Xray 内核配置中的某个字段。先查看当前客户端说明和运行日志，确认使用了哪种后端，再讨论栈、路由和 DNS 参数。

启用前完成基础连接验证

先在普通系统代理方式下确认节点可以访问目标服务，再检查操作系统是否允许创建虚拟接口和修改路由。Windows 可能需要以相应权限启动或启用客户端服务；macOS 与 Linux 则可能需要授权或配套服务支持。权限不足、接口创建失败和服务器连接失败属于不同层面，应按日志分开处理。桌面安装入口见下载中心，不要通过不明来源的额外组件补齐一个尚未定位的报错。

启用前暂时退出其他会修改默认路由、DNS 或虚拟接口的软件，记录原有网络是否正常。远程连接到另一台设备操作时尤其要谨慎：路由切换可能让管理连接立即断开，应先准备本地恢复方式。首次测试不要同时启用严格路由、自定义排除网段和 FakeDNS；保留默认参数，先确认接口建立、代理服务器可连接、常用网页可访问，再逐项增加需求。

理解栈、自动路由与排除项

网络栈负责把接收到的数据包转成可处理的连接，不同实现对系统兼容性、UDP 和资源占用的表现可能不同。某个栈在一个系统上可用，不代表在所有设备上都应优先选择。自动路由负责把目标流量送到虚拟接口，排除项则用于保留本地服务、局域网或特定连接的原有路径。应先确认后台已经正确排除了代理服务器自身的连接，避免出站再次进入 TUN，形成重复接管。

MTU 表示接口可承载的数据包大小，并非越大越快。若小页面可以访问而大文件、特定应用或某些连接经常停住，除了节点与 DNS，也可检查路径 MTU 和分片问题。调整时按后端支持范围小幅变化，每次重新建立测试连接，并保留原值。仅凭一次网页加载结果就把 MTU 固定为网上某个数值，往往掩盖了真正的问题，尤其在切换网络后更容易复发。

跨平台差异与验证顺序

Android 上 v2rayNG 与 v2flyNG 通常通过系统 VPN 接口接管应用流量，授权界面与桌面的虚拟接口管理不是同一套机制。按应用代理、绕过局域网和后台运行限制，都可能影响最终覆盖范围。启用一个客户端时，应先停止另一个占用同类接口的连接；系统中的省电策略若终止后台进程，也会造成连接随锁屏中断。不要把桌面客户端的服务安装方法原样套到 Android。

验证时依次检查普通网页、本地网关或局域网服务、需要 UDP 的应用，再测试切换网络和唤醒设备。若启用后全面断网，先关闭 TUN，确认普通网络恢复，然后查看接口、路由与 DNS 日志。若关闭后仍异常，退出客户端并检查系统代理是否遗留，再重新连接网络。只有接管层持续稳定，才适合进一步调整严格路由与排除网段；恢复网络优先于继续叠加高级参数。

05 · 域名映射

FakeDNS 与 DNS 接管

FakeDNS 为域名分配合成地址，并在后续连接到达时根据映射找回原始域名。合成地址用于客户端内部识别，不是网站真实服务器地址。它的意义在于：当应用先自行解析、再只用 IP 建立连接时，代理仍有机会恢复域名，从而执行域名路由或把名称交给远端处理。它不自动改善节点质量，也不能脱离 DNS 接管与流量接管单独发挥作用。

先确认映射闭环是否完整

完整路径包括四步：应用的查询进入指定解析模块，模块返回合成地址，应用连接该地址，客户端接收到连接并恢复域名。任何一步绕开客户端都可能失败。例如浏览器使用自己的加密 DNS，查询没有进入映射模块；或系统拿到了合成地址，但连接因排除路由直接发往物理网络；或生成映射的模块与接收连接的模块不是同一个实现。出现这些情况时，单纯开启嗅探不一定能够补救。

因此，先确认普通 TUN 与真实 DNS 解析稳定，再决定是否使用 FakeDNS。v2rayN 的 TUN 后端可能提供自己的合成地址机制，这与 Xray 配置中的 FakeDNS 不能仅凭名称相似就相互替代。字段名、地址池、缓存方式和路由要求都应按实际后端阅读。不要把两套机制同时打开并共享一个地址段，除非已有明确的兼容设计；不同模块持有不同映射时，相同合成地址可能代表不同域名。

地址池与映射容量

下面是 Xray 风格的相关片段，展示地址池、DNS 服务器选择以及入站嗅探之间的关系。它不是可直接替换客户端配置的完整文件。入站上的嗅探字段应合并到实际接收该流量的入站，而不是随便新增到根对象。198.18.0.0/15是常见的合成地址池选择，启用前仍要确认本地网络没有使用或特殊路由到这个范围，并确保相关连接不会直接离开代理接管路径。

{
  "fakedns": [
    {
      "ipPool": "198.18.0.0/15",
      "poolSize": 65535
    }
  ],
  "dns": {
    "servers": ["fakedns"]
  }
}

{
  "sniffing": {
    "enabled": true,
    "destOverride": ["fakedns"]
  }
}

poolSize控制映射容量，不能理解为同时支持的服务器数量。访问大量不同域名时，容量与淘汰方式会影响旧地址还能否恢复为原名称。应用可能长期保留解析结果，而内核重启后原映射已经丢失，此时应用继续连接旧合成地址就可能失败。遇到仅重启客户端后出现的个别应用异常，应先退出应用、清理相关 DNS 缓存并重新建立连接，而不是立即更改代理协议。

例外域名与故障特征

局域网名称、设备发现、依赖真实地址的应用以及需要特殊 DNS 记录的业务，应分别验证是否适合合成地址。某些应用会检查解析结果是否位于预期网络，或者将结果交给不受客户端接管的其他进程，因此需要按后端支持方式配置例外解析。例外域名应继续返回真实地址，并与对应直连或代理规则协调；不能一边返回合成地址，一边又把该范围加入完全绕过客户端的列表。

排查时观察系统或应用是否取得了合成地址，再看连接是否到达接管接口，最后检查日志中是否恢复为原域名。若合成地址出现在物理网络连接里，优先修复接管和路由，而不是更换 DNS 服务器。退出 FakeDNS 时也要处理缓存：先切回真实解析，重启受影响应用，必要时刷新系统缓存，再验证所有连接不再依赖旧映射。仅关闭开关而保留旧地址，可能让故障延续到配置已恢复之后。

06 · 来源与维护

多订阅管理与更新策略

多订阅管理的重点是隔离来源、控制更新影响和保留可恢复状态，而不是把所有服务器合并成一个难以识别的长列表。建议每个来源使用独立分组，备注采用“来源代号与用途”的稳定结构，临时测试的来源单独存放。来源增加后，先建立管理规则再执行批量更新；否则同名条目、不同协议和订阅变化混在一起，切换时很容易选错服务器，也难以判断参数到底来自哪个来源。

明确分组、条目与活动连接的关系

分组选择往往只改变当前列表视图，不必然改变活动服务器；某些界面则允许在分组内重新选择后立即切换。操作时应观察实际活动标记，而不是只看顶部显示的分组名。服务器备注也不是稳定的唯一标识，两个来源可以提供同名条目，同一来源也可能在更新时改名。需要排查更新影响时，比较协议、目标地址、端口及传输参数，比只对比显示名称可靠。

自动去重同样需要谨慎。两个服务器使用相同地址和端口，不代表配置等价，身份字段、TLS 名称、路径或流控参数不同都可能对应不同连接方式。除非明确知道客户端按什么字段判断重复，否则不要为了缩短列表而批量删除。若确需精简，应先按分组筛选，再保存必要的本地记录，操作后进行一次分组更新，确认不会因为来源重新下发而反复出现同样的条目。

为自动更新设置合理边界

更新周期应以来源实际变化频率和客户端使用习惯为依据。过于频繁的更新会增加请求和排错噪声，也不能改善已经失效的来源。首次添加时使用手动更新；确认内容稳定后，再启用客户端支持的定时策略。设备休眠、网络尚未就绪或后台进程暂停时，计划任务未必按预期执行，因此关键使用之前仍应检查最近一次更新结果，不要只看任务已经设置。

还要区分“通过代理更新”和“直接更新”的实际需求。某个来源只能经特定路径访问时，应明确选择更新请求使用的路径，但不能让唯一可用的订阅更新完全依赖即将被替换的活动服务器。修改更新方式后单独测试一个分组，保留失败日志中的网络错误类别，同时隐藏完整订阅地址。多个分组同时失败时，先检查共同的网络与代理依赖，通常不需要逐个重建来源。

备份、迁移与来源下线

迁移客户端前，应使用界面提供的导出或备份功能，并确认导出内容是否包括订阅地址、手动服务器、路由与 DNS 设置。不同备份范围不能混为一谈，单个分享链接通常不足以恢复整个使用环境。备份文件可能包含身份信息，应保存在受控位置。跨设备恢复后，先确认本地端口、文件路径、服务权限和虚拟接口设置是否适用，不要把旧设备的网络参数全部视为通用配置。

来源停用时，先切换到已验证可用的服务器，关闭该分组的自动更新，再决定删除还是保留本地记录。直接删除当前活动条目可能让连接中断，某些应用还会继续复用旧连接，造成“列表已经换了、请求仍走旧路径”的错觉。删除后应重建测试连接，并检查没有遗留的路由或自定义出站引用该条目。长期不用的订阅也应从自动更新清单移除，减少无意义的失败提示。

管理规模扩大后，可以维护一份简短变更记录：改了哪个分组、更新了哪类参数、验证了什么场景、如何恢复。记录不应包含完整订阅地址或身份字段。它的价值是让故障与最近操作对应起来，而不是再造一个复杂配置系统。若无法判断是来源更新还是本地设置造成问题，可先在独立分组导入同一来源，仅比较条目和连接结果，不改动原有稳定分组。

07 · 标签与转发

自定义出站与配置合并

出站描述内核如何发起连接，路由通过标签把请求交给对应出站。一个规则写了 outboundTag，并不代表客户端已经创建该出站；标签必须在最终运行配置中真实存在，拼写和大小写也要一致。自定义出站适合明确的转发需求，不宜用来替代所有图形设置。对于日常使用，优先让 v2rayN 管理标准服务器配置，只把确有需要的部分交给自定义配置，以降低更新与迁移成本。

先检查最终配置的归属

图形客户端通常会根据当前服务器、路由预设和 DNS 模板生成运行配置。直接修改临时生成文件，下一次切换服务器或启动内核时可能被覆盖。应先确认当前入口属于“编辑服务器”“编辑路由”还是“完整自定义配置”，它们控制的范围不同。使用完整自定义配置时，也要确认客户端是否仍会注入本地入站、日志和管理接口；不能假定可视化页面上的每个选项都会继续生效。

准备修改前导出当前可用配置，并从日志确认实际内核。Xray 与 V2Fly 都使用 JSON 风格配置，但字段能力和协议支持并非完全一致，其他 TUN 后端的配置结构更不能直接混用。把片段合并进现有文件时，要保持根对象、数组和逗号正确；同一个对象出现重复键，可能被解析器覆盖而不明显报错。配置能通过语法解析，只说明格式成立，还需要内核接受字段并成功建立连接。

从直连与本地转发理解标签

下面的 Xray 风格出站片段展示两个标签：direct代表直接连接，local-socks将请求交给本机回环地址上的 SOCKS 服务。只有本机端口确有相应服务监听时，第二个出站才可用；示例端口不是对所有客户端的默认值声明。不要把它指向当前配置自己的入站端口，否则可能形成循环转发。若已有出站数组，应合并所需对象，而不是覆盖原来的代理出站。

{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "local-socks",
      "protocol": "socks",
      "settings": {
        "servers": [
          {
            "address": "127.0.0.1",
            "port": 1080
          }
        ]
      }
    }
  ]
}

在这类配置中，没有匹配路由的流量通常使用出站数组中的第一个出站，因此示例的默认方向是直连，不能把它当成完整的日常代理配置。实际合并时保留既有默认出站，并用精确规则引用新增标签。先选一个测试域名交给 local-socks，确认本地服务可用，再扩大匹配范围。不要刚添加出站就用一条覆盖所有连接的规则测试，否则错误会影响整个访问路径。

区分链式转发与出口选择

多个出站同时存在，不代表请求会依次经过它们。通常一条连接只选择一个出站，只有显式配置了内核支持的链式机制，才会形成前后依赖。链式连接还需要考虑哪一段解析服务器域名、哪一段承担 UDP、前段失效后如何处理，以及日志应从哪一侧观察。没有明确需求时，不建议为追求形式上的“多一层”叠加转发，这会增加连接建立时间与故障定位难度。

验证自定义出站时，先确认下游服务监听地址和端口，再确认标签存在，最后查看规则命中与连接错误。如果日志出现连接被拒绝，重点检查监听服务；出现找不到出站，检查标签及配置合并；出现循环或大量重复连接，立即停止相关核心并恢复基线。恢复后再逐条引入修改。关于内核与图形客户端的分工，可参阅Project V 开源生态梳理，不要把客户端名称直接当作出站协议名称。

08 · 兼容与验收

协议、内核与配置验收

完成高级设置之前，需要建立一条兼容性判断链：客户端能否表达这些参数、所选内核能否解析这些字段、服务器端是否配置了对应能力、当前网络是否允许连接建立。四者缺一都会失败。客户端提供某个选项，不意味着任意服务器都能使用；导入后能显示备注，也不代表参数已经完整。桌面优先使用 v2rayN 管理配置，Android 按需求选择 v2rayNG 或 v2flyNG，具体支持范围以实际内核与导入结果为准。

把协议、传输与加密层分开核对

VLESS、VMess、Trojan 和 Shadowsocks 描述的身份与连接机制不同，不能只更改协议名称就相互转换。传输方式负责连接如何承载，TLS 或 REALITY 等设置又涉及握手与目标身份参数。排错时按层核对：先看协议与身份字段，再看地址端口，然后看传输路径、服务名称等参数，最后核对 TLS 名称或 REALITY 所需字段。来源未提供的值，不应凭其他服务器的配置补齐。

VLESS 本身不提供与 TLS 相同的传输加密能力，应结合服务器要求使用对应安全层。REALITY 与 XTLS Vision 也不是两个可以随意互换的协议标签，涉及安全层、流控和内核支持的配合。常见握手失败可能来自服务器名称、密钥相关字段、短标识或系统时间不一致，而不是路由规则错误。原理和配置项的关系可继续阅读REALITY 与 XTLS Vision 原理说明，测试时仍以来源的完整参数为依据。

多内核切换不是故障通用解法

Xray 与 V2Fly 是 Project V 相关生态中的内核路线，图形客户端负责把界面设置转换成内核运行配置。v2rayNG 以 Xray 为主要内核路线，v2flyNG 则面向 V2Fly；不能期待包含特定扩展能力的配置在二者之间原样迁移。v2rayN 的内核选择同样要结合协议及配置模板。切换前先记录原内核与已启用的高级功能，停止原有连接，再观察新内核是否成功启动，而不是只看界面的运行图标。

若导入后某些字段丢失，应先检查分享格式是否能够表达这些参数，以及当前客户端是否支持该格式。必要时在图形界面逐项核对，但不应把真实身份字段粘贴到公开求助内容中。内核启动失败通常优先检查配置语法、未知字段、端口占用和依赖文件；启动成功但握手失败，再转向服务器参数、系统时间与网络连接。两类故障的修复路径不同，盲目换内核会让证据变得混乱。

建立可重复的验收流程

每次修改后都按相同顺序验收：先确认核心成功加载配置，再确认本地入口可用，接着测试一个普通域名、一个明确直连的目标和一个需代理的目标，最后才检查 TUN、UDP、IPv6 或合成地址等附加能力。浏览器成功打开一个页面，只能证明该页面当时经过的路径可用。对长连接、后台应用和网络切换，应另外重建连接测试，避免旧连接掩盖新配置的实际问题。

日志记录应围绕时间、目标、入站、命中规则和出站标签整理，错误信息保留原始类别，但隐藏订阅地址、身份字段和不必要的个人访问记录。临时提高日志级别可以帮助定位，问题解决后应恢复合适级别，减少长期记录。若一次改动涉及多个章节，先回到最后可用状态，再按订阅、路由、DNS、接管与扩展功能逐层恢复；这比继续在异常状态下微调更有可重复性。

本页用于理解配置依赖，不要求把全部功能都开启。最终应保留能解释、能验证、能恢复的一组设置：普通应用按预期接管，本地服务可访问，解析路径与路由一致，更新订阅不破坏手动配置。需要重新完成首次连接时返回快速上手主线；需要按现象检索则查看常见问题。把每次验证结果与最近修改关联起来，才能让进阶配置从一次性的尝试变成可维护的使用环境。