v2rayN 进阶配置手册

订阅分组与服务器过滤

订阅分组负责保存来源和更新方式，服务器条目负责保存具体连接参数。两者不是同一个层级：改分组备注不会改变协议，切换当前服务器也不会更新订阅。先把来源整理清楚，再做过滤和选择，可以避免把“列表变化”误判为“连接故障”。建议用用途或来源命名分组，不把密码、访问令牌或个人账号写进备注。

建立分组，再检查更新结果

在 v2rayN 的订阅分组设置中新增分组，填写备注和订阅地址，保存后对该分组执行更新。地址应保持完整，尤其不能遗漏问号后的参数；从聊天窗口复制时，注意末尾的空格、换行和标点。更新后先查看该分组的服务器列表，再选择条目作为当前服务器。新增分组本身只保存来源，不等于已经下载并解析了内容。

订阅更新是一条独立的请求路径。有的环境可以直接访问来源，有的需要通过已经可用的代理更新；两种方式应分别尝试，不要反复切换连接参数。如果列表为空，先看更新日志中的响应状态与解析提示。返回网页、登录页面或访问错误时，即使网络请求成功，也不能得到有效服务器。检查来源有效期比重装客户端更有针对性。

过滤决定显示范围，不改变协议能力

服务器过滤通常按备注文本匹配，具体入口可能位于分组设置或列表筛选区。开始时使用一个明确的关键词，确认预期条目仍可见，再增加条件。筛选框有的接受普通文本，有的接受正则表达式，须以字段提示为准。不要把列表搜索当成订阅过滤：搜索往往只临时改变当前视图，更新过滤可能决定哪些条目被保留。

支持正则的字段可用下列模式理解匹配边界。竖线表示任一词命中，行首符号限制备注开头，负向前瞻用于排除特定词。备注规则由来源自行决定，不能把文字标签当成连接能力证明；含有某个协议名称的备注，也不保证实际参数采用该协议。先检查条目的协议、传输和安全字段，再判断所选内核是否能够运行。

办公|备用
^办公
^(?!.*测试).*$

手动修改与订阅刷新分开处理

订阅提供的条目可能在更新时重建。对这些条目修改地址、端口或安全参数后，下一次刷新可能覆盖修改，也可能留下新的重复条目。需要长期保留的实验设置，应复制到单独的手动分组，并用备注说明修改原因。这样既能继续接收来源更新，也能明确区分服务端提供的数据与本地测试的数据。

安卓客户端同样应先建立可识别的订阅分组，再执行更新并检查结果。v2rayNG 与 v2flyNG 的分组界面和过滤能力不必完全相同；没有专门过滤入口时，使用分组选择或列表搜索，不要强行套用桌面步骤。导入成功只证明格式被识别，协议字段能否被当前内核接受，还需要通过启动日志和实际请求验证。

保存一份简短的更新记录：来源名称、采用的更新方式、结果是否正常，以及过滤条件是否改动。若更新后条目突然减少，先暂时清空过滤再刷新；若条目恢复，问题在筛选条件，而不是内核。仍无法解析时，到连接验证与回退按订阅请求和服务器连接分别检查。不要用不断导入同一地址的方式累积重复分组。

路由规则实战

路由接收已经进入内核的请求，再决定使用哪个出站。系统代理开关则决定应用是否把请求交给本地代理。应用完全绕开入口时，修改路由不会产生效果。开始编写规则前，应先确认应用流量确实进入客户端，再确认生成配置中的代理、直连和阻断标签，不能凭界面名称猜测实际标签。

按首个命中规则设计顺序

常规字段规则按顺序查找，先命中的有效规则决定出口。把具体例外放在前面，把较宽的地域或类别规则放在后面。例如，某个测试域名需要代理，即使它属于后面的直连集合，也应先写它的代理规则。多个独立规则不是叠加投票；同一条规则内填写多个不同字段时，通常要求这些字段同时满足。

下例是可嵌入 Xray 配置的路由对象。它先代理指定域名及其子域，再让私有地址和中国地址直连，最后按所使用的域名集合匹配直连请求。示例假设已经存在标签为 proxy 与 direct 的出站，并且内核能读取所需规则数据。实际客户端生成的标签可能不同，使用前必须核对。

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

区分域名匹配、地址匹配与解析策略

full:example.com 只匹配完整域名，domain:example.com 还包含其子域。没有前缀的域名文本可能按包含关系处理，容易扩大范围；需要明确边界时优先写前缀。正则适合已有清晰命名规律的域名，不适合代替所有普通规则。规则写得越复杂，排错时越难知道是哪一个条件真正命中。

地址规则处理请求目的地址，不会自动理解域名背后的业务含义。IPIfNonMatch 在域名规则未匹配时尝试解析，再进行地址匹配；这会引入 DNS 的依赖。应用若只提交地址，内核也不一定知道原始域名。嗅探可以从部分协议中获取域名线索，但并非对所有流量有效，不能把它当成可靠的域名还原工具。

验证规则，不只观察网页是否打开

添加规则后重启或重载内核，确认日志没有未知标签、字段错误或规则文件缺失。随后使用单一目标发起新请求，观察访问日志中的出口信息。浏览器可能复用已经建立的连接，修改规则后原连接仍沿旧路径运行；关闭相关标签页或重新建立连接，可以避免把连接复用误判成规则失效。

没有任何规则命中时，常规配置会落到默认出站，通常是出站列表中的第一项。因此，默认出口同样属于路由设计，不能遗漏。用阻断规则做排查时，应只限制一个明确的测试目标，并准备恢复方式。直接阻断大类流量可能同时影响 DNS、订阅更新和连接建立，使原本简单的匹配问题变成多个问题。

客户端预设路由和自定义规则可能共同参与配置生成。保存后检查实际生效的规则顺序，不要只检查编辑窗口中的顺序。需要更细的语法对照，可阅读自定义路由规则写法；需要理解入口与模式的分工，可阅读系统代理与路由模式对比。测试期间一次只移动一条规则，保留可回退的顺序。

DNS 配置优化

DNS 配置首先要回答“谁在解析”。浏览器、操作系统、客户端内核和远端出口都可能参与域名解析。只更换客户端 DNS，不一定改变浏览器的加密解析，也不一定改变系统缓存。优化应围绕请求路径展开：先确定应用提交的是域名还是地址，再确定哪个环节查询上游，最后检查 DNS 请求本身从哪里出站。

拆开目标解析与连接地址解析

浏览目标网站的解析，与连接服务器地址的解析，虽然都使用 DNS，却承担不同任务。若服务器填写域名，建立代理之前就可能需要解析它；此时不能把唯一解析路径设成尚未建立的代理，否则形成循环依赖。先保证服务器地址可以通过基础网络解析，再讨论目标网站的分流解析，是更稳妥的顺序。

客户端中的“远程 DNS”“直连 DNS”等选项通常属于配置生成器的抽象，不一定与内核字段一一对应。修改时应查看字段说明，并核对生成结果。安卓 VPN 模式可能向应用提供专门的 DNS 入口，桌面系统代理则不一定接管所有 DNS 请求。不能因为浏览器可访问，就认定整个系统都使用了同一解析路径。

先配置可解释的上游与策略

下面演示 Xray 内置 DNS 的基本对象：为明确域名集合指定一个上游，其余请求交给另一个上游。UseIP 允许返回两类地址，但实际结果还取决于上游和网络。示例中的公共解析地址仅用于解释字段，不代表适用于所有网络；应先在当前连接环境中确认可达，再纳入配置。路由对象仍须另行安排这些查询的出口。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": ["geosite:cn"]
      },
      "1.1.1.1"
    ]
  }
}

域名条件是选择上游的依据之一，不等于严格隔离所有回退请求。部分上游失败后，内核可能继续尝试其他服务器；是否限制回退，要结合当前内核支持的字段理解。为了追求形式上的分流而关闭全部回退，可能使短暂的上游故障变成所有域名都无法解析。先验证基本查询成功，再逐步收紧边界。

加密解析仍需要正确出口

使用加密 DNS 可以改变传输方式，但不能自动解决上游不可达或连接循环。采用 HTTPS 上游时，还需要处理上游主机名的初始解析、连接地址、证书验证和路由。把加密上游设为代理出站前，要确认代理自身不依赖这条解析链。若应用同时启用自己的加密 DNS，客户端的域名集合规则可能只能看到解析后的地址。

排查地址族问题时，分别确认网络是否能使用 IPv4 与 IPv6。只返回某一类地址可以暂时缩小问题范围，却不是通用性能优化。若系统能获得 IPv6 地址但没有可用出口，应用可能先尝试不可达路径；若业务仅提供 IPv6，强制 IPv4 又会使它直接失败。保留原策略，单独改变一次查询策略并比较结果。

缓存会让改动效果延后出现。测试前重新建立应用连接，必要时按系统提供的方式清理 DNS 缓存，但不要把清缓存当成持续修复手段。命令行的系统查询通常只测试系统解析器，不会自动经过内核 DNS；必须结合内核日志，才能确认新设置是否参与了请求。保留测试域名、返回地址和出口记录，避免只用“打开速度”判断。

最终配置应能够说明每一类查询的去向，而不是堆叠多个解析服务。若加入 TUN 或 FakeDNS，解析入口和返回结果都会发生变化，须继续阅读对应章节。出现解析错误时先退回单一可达上游，确认基础连接恢复，再逐项重加分流、加密和缓存设置。这样可以区分上游问题、路由问题和接管问题。

TUN 模式

TUN 通过虚拟网络接口接收被系统路由导入的 IP 流量，适合不遵循系统代理的应用。它扩大了接管范围，却不等于修改系统代理开关，也不等于所有请求必须使用代理出口。流量进入接管组件之后，仍然需要路由规则决定直连、代理或阻断。开启前先在普通代理入口验证当前服务器，避免同时排查入口和远端连接。

理解权限、路由与内核的分工

v2rayN 的 TUN 实现取决于客户端集成的接管组件和对应配置，不应把普通 Xray 配置片段当成通用 TUN 配置。虚拟接口的创建、系统路由的写入和 DNS 的接管属于不同动作，其中部分需要提升权限。按界面提示授予必要权限后，再检查日志是否完成接口初始化；仅看到开关处于开启状态，不足以证明路由已经生效。

开启前记录现有默认路由、DNS 设置，以及正在运行的其他网络接管工具。多个组件同时修改默认路由，可能造成请求循环或出口竞争。实验时保留一种接管方式，暂时关闭其他会接管流量的程序。需要访问局域网设备、共享目录或公司网络时，应提前记录目标网段，避免启用后失去访问配置入口的能力。

避免代理连接重新进入接管入口

代理连接本身必须能够离开接管回路。如果连接远端服务器的流量又被送回虚拟接口，内核会不断尝试通过自己建立出口。客户端通常会提供出口绑定、进程排除或路由例外等机制，具体采用哪一种取决于实现。手动添加服务器地址例外时，还要考虑域名解析结果变化；固定写入旧地址可能在来源切换后失效。

局域网直连与系统路由排除也不是同一个概念。路由中的直连出站让内核代为发起连接；系统排除则让请求完全不进入内核。打印机发现、广播和某些本地服务可能依赖后者，单纯写私有地址直连不一定覆盖所有需求。先验证一个明确的本地地址，再测试发现功能，按现象决定调整哪一层。

从最小接管范围开始验证

初次测试使用默认且可解释的接管设置，先打开一个已知可访问的目标，再测试一个不遵循系统代理的应用。查看应用是否真正产生了内核记录；没有记录时，应检查系统路由与应用排除设置，而不是先换服务器。出现记录但失败时，再检查出口和 DNS。应用选择功能若同时提供包含与排除模式，应先确认当前模式的含义。

UDP、地址族和 MTU 是常见边界。网页正常但某些实时应用失败，可能与 UDP 转发能力或防火墙有关；小请求成功而大传输停滞，才值得进一步检查路径 MTU。不要随意抄用一个固定 MTU 数字。先通过日志与网络诊断确认现象，再小幅调整并比较。需要 ICMP 的功能也不一定获得与普通 TCP 相同的处理方式。

退出测试时先关闭 TUN，再观察普通网络和局域网是否恢复。若退出客户端后仍存在异常，检查虚拟接口、默认路由与 DNS 是否已还原；重新启动客户端并正常关闭接管，有时比直接结束进程更容易触发清理。不要在没有记录的情况下删除系统路由。需要长期启用时，保留普通代理模式作为回退路径，并记录哪些应用或网段必须排除。

FakeDNS

FakeDNS 为域名分配一个内部使用的合成地址，内核随后根据映射找回域名。它的目标是保留域名信息，让分流能够依据域名进行，而不是单纯加快公共 DNS 查询。合成地址不是真实服务地址，不能脱离生成它的映射和接管链路使用。是否启用，应由应用提交地址后丢失域名的实际问题决定，而不是把它当成默认加速开关。

映射必须贯穿解析和连接

正常链路包含三个环节：应用向被接管的 DNS 入口查询，FakeDNS 返回合成地址，应用连接该地址时内核通过映射恢复域名。只启用地址池，没有把应用查询送入相应入口，映射不会产生作用；只返回合成地址，没有接管后续连接，应用会尝试访问无法在公网使用的地址。因此它常与透明接管配合，但两者仍需要分别验证。

下面是 Xray 的 FakeDNS 相关片段。fakedns 定义地址池，DNS 服务器列表引用它。198.18.0.0/15 属于测试用途地址空间，并非某个真实站点的地址。示例不包含接管入口和完整嗅探设置，不能单独构成可运行方案；若 v2rayN 的接管组件自行实现合成地址机制，应使用该组件的字段，而不是混入另一套内核配置。

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

池大小与回收影响映射生命周期

地址池必须有足够空间，且不能与现有网络重叠。企业网络或实验环境可能已经使用类似测试地址，需要先检查路由表。池大小控制可维持的映射范围，不是网络容量或连接速度指标。长时间运行后映射可能被回收，应用却仍保留旧缓存；内核重启后映射重建，也可能让同一个合成地址对应不同域名。

嗅探相关设置可帮助内核获取域名，但应区分读取信息与改写目的地。针对 FakeDNS 的映射恢复，与从 HTTP 或 TLS 中提取域名并不相同。仅启用路由用途的嗅探，是否满足当前组合的目的地恢复要求，需要核对接管组件的实现。优先采用客户端已经提供的配套选项，再从生成配置确认它们是否同时生效。

为需要真实地址的场景保留例外

有些应用会把 DNS 结果交给另一个进程、保存在配置中，或用返回地址建立局域网会话；这些行为可能让合成地址离开原来的接管链路。此时应按域名或应用设置真实解析例外。局域网设备发现、依赖地址判断的服务，以及需要与其他机器共享解析结果的任务，尤其值得单独测试，不要一次把全部查询都切换成合成地址。

应用自带加密 DNS 时，查询可能不经过 FakeDNS，结果仍是真实地址；这不一定导致连接失败，但会改变域名规则的判断条件。反过来，系统解析已经拿到合成地址，应用连接又被排除在接管外，就可能直接失败。测试要同时核对查询入口和连接入口，不能只看 DNS 返回内容就认定功能正常。

关闭 FakeDNS 后，先让应用停止使用旧结果，再重建连接；必要时清理系统与应用各自的 DNS 缓存。否则旧合成地址仍被请求，表现就像关闭功能后网络反而更差。验证回退时，确认查询结果已经变回真实地址，并确认相同目标能通过原来的 DNS 与路由链路访问。缓存恢复和内核恢复应作为两个独立检查项。

最终只在确有域名保留需求的范围内启用。遇到个别应用异常，先将它切回真实解析并比较，而不是扩大地址池或不断重启。如果普通 DNS 与普通代理模式已经满足需求，可以保留这套更简单的方案。关于内核能力差异，可阅读Xray 与 V2Fly 内核对照，避免把一种实现的字段当成所有客户端共有能力。

多订阅管理

多订阅管理的重点是来源隔离、更新可追踪和当前服务器可确认，而不是把所有地址合并成一个大列表。不同来源可能采用相同备注、不同协议或不同更新周期，混在一起后容易选错条目。按来源建立独立分组，再用用途备注辅助识别，能够让删除、更新与故障回退都有明确范围。

区分来源事实与本地使用策略

来源事实包括订阅地址、返回条目和服务端参数；本地策略包括分组备注、列表筛选、当前选择和路由规则。尽量不要把本地策略写进需要随订阅刷新的参数。某个分组用于工作，只是管理上的约定，并不会自动让工作应用走该分组；应用与出口的绑定需要路由规则或客户端相应功能实现。

首次添加新来源时，先在独立分组更新并核对条目，避免立刻替换已可用的当前服务器。确认格式、内核能力和连接路径后，再决定是否纳入日常选择。订阅来源若返回客户端配置而非服务器列表，应按相应导入类型处理，不能通过不断切换更新按钮来强行解析。更新日志中的格式错误，应与网络超时分别记录。

更新调度与故障范围保持一致

为不同来源设置适当的更新安排，避免短时间重复请求。频繁更新不能修复失效的访问凭据，反而可能触发来源访问限制。失败时先对单个分组更新，不要批量刷新所有来源；单个来源异常，通常不需要修改系统 DNS 或删除其他分组。若所有来源同时失败，再检查共同的基础网络与更新出口。

更新前确认当前使用的条目属于哪个来源，更新后确认选择仍然存在。来源删除条目或调整标识时，客户端可能保留旧选择、改选其他条目，或需要重新选择；具体行为应通过列表和日志确认。客户端显示“更新成功”只代表本次处理完成，不保证当前条目已经切换为新参数，更不保证远端连接已经验证。

去重不能只看备注

相同备注的条目不一定相同，相同地址和端口也可能使用不同身份与安全参数。去重前比较协议、地址、端口、用户标识、传输类型和安全字段。不要为获得整齐列表而手工删除来源中的所有相似项；来源可能故意提供不同连接方式。若客户端具有去重功能，应先了解它采用哪些比较字段，并保留原分组供回退。

备用来源需要独立验证，而不是只在主来源故障时才首次使用。测试时明确切换当前服务器，再执行一次新的请求；只选中列表中的行，不一定等于设为当前服务器。多来源本身也不产生自动故障转移。要实现自动选择或均衡，需要明确支持的机制、可用性判断和出站配置，不能把多个分组误认为已经组成自动切换池。

跨设备迁移时，区分迁移订阅地址和迁移完整客户端设置。完整导出可能包含本地监听、路由、DNS 与设备相关选项；直接复制到另一平台会带入不适合新设备的参数。通常先导入来源，再按新设备设置入口与路由，更容易验证。桌面与安卓应分别确认内核能力，避免在一个设备上可用的协议组合迁移后不能启动。

定期清理失效来源，但先确认没有路由、固定出口或手动测试依赖其中的条目。删除分组前记录用途并切换到可用服务器，再执行删除。若来源地址发生变化，应在原分组中按提供方说明更新，而不是无限增加同名分组。遇到订阅更新失败，可回到订阅分组章节检查地址与过滤，并在分层排查中核对更新路径；无需把所有失败都归因于服务器。

自定义出站

出站是内核实际发起连接的方式，路由标签则是请求出站的引用名称。自定义出站适合明确需要固定出口、局部阻断或连接本地代理的场景。普通用户选择一个服务器并使用预设路由，通常已能完成基本操作；只有能够说明新增出站用途时，再进入完整配置编辑。配置越多，启动检查和回退记录越重要。

先确认编辑入口是否接受完整配置

v2rayN 的服务器编辑、路由编辑和自定义配置入口负责不同层次。服务器表单不能接收任意顶层 JSON，路由编辑也不会自动创建出站。使用自定义配置前，确认客户端是直接加载该文件，还是将片段合并进生成配置。保存到运行目录中的文件可能在下次启动被重新生成，应使用客户端提供的持久化入口，而不是依赖临时修改。

下面是一个只监听本机的完整 Xray 教学配置。它提供 SOCKS 入口，默认直连，并将指定测试域名阻断。配置没有远端代理服务器，因此不能代替订阅连接；其用途是验证入口、标签与路由引用。端口只是本例的选择，若已被占用，应同时修改配置与测试命令。不要在未配置访问控制时把监听地址改成所有网络接口。

{
  "log": {
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "local-socks",
      "listen": "127.0.0.1",
      "port": 10808,
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": true
      }
    }
  ],
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {}
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {}
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "domain": ["full:example.com"],
        "outboundTag": "block"
      }
    ]
  }
}

标签、默认出口与引用闭环

每个需要被引用的出站应有明确且唯一的标签。路由中的 outboundTag 必须对应实际存在的出站；拼写大小写或前后空格不同，都可能导致配置错误或不按预期运行。没有命中规则的请求通常使用第一个出站，所以调整列表顺序会改变默认行为。将默认出口与例外出口分开记录，比只记录规则文本更可靠。

直连出站意味着内核用本地网络连接目标，不意味着请求从未进入客户端；阻断出站则主动终止匹配流量。要连接另一个本地 SOCKS 服务，应明确它的监听地址、端口和认证方式，并保证它不会把请求重新送回当前入口。把同一监听端口同时当入口和下游出口，是常见循环错误；两个服务也不能争用同一地址端口。

远端参数以服务端配置为准

新增远端协议出站时，地址、端口和身份字段之外，还可能需要传输路径、服务名称、服务器名称或公钥等参数。每项都应与服务端配置对应，不能用另一个条目的字段拼接。REALITY 属于传输安全方案，不能只通过把协议名称改成 REALITY 来启用；相关参数的解释可查阅REALITY 概念说明。

客户端能显示某种协议，不代表所选内核能够执行全部安全与传输组合。Xray 与 V2Fly 的支持范围不同，安卓 v2rayNG 与 v2flyNG 也不能被视为字段完全互换。加载配置前先检查内核选择，再检查启动日志。如果提示不支持某字段，应查清字段所属实现，而不是不断删掉安全参数直到配置勉强启动。

链式代理需要额外确认每一跳的建立路径和解析路径。外层出口未建立之前，内层连接无法通过它；同时还可能叠加超时、证书和地址族问题。首次配置先让各出口独立工作，再按内核支持的链式机制连接起来。界面上同时存在两个服务器，不代表已经组成链式代理，更不代表流量会自动按列表顺序经过它们。

自定义配置验证应从启动成功、入口可达和单条路由依次进行。保留正常的图形配置作为基线，实验失败时切回基线，不要继续在失败状态上追加出站。阅读日志时重点关注协议字段、标签引用和监听冲突，不必公开包含身份字段的完整文件。掌握这三个闭环后，再考虑更复杂的出口组合，维护成本会明显更可控。

连接验证与回退

连接排查应沿请求路径进行：应用入口、本地内核、域名解析、路由出口、远端握手和目标服务。不同错误发生在不同层，统一称为“服务器坏了”会跳过最容易验证的部分。先选一个稳定可重复的测试目标，记录使用的客户端、内核、入口模式与当前服务器，再开始修改。一次改变一个变量，才知道恢复来自哪项设置。

先验证本地入口与内核启动

内核启动失败时，系统代理可能已经设置，应用却连接不到本地监听。先查看日志是否有字段错误、端口占用或权限不足，再确认监听地址和端口。界面显示的本地端口与自定义配置端口可能不同，应以实际运行配置为准。不要把 HTTP 代理端口当成 SOCKS 端口测试；两种入口的握手方式不同，填错后可能立即失败。

使用下列命令可以明确指定 SOCKS 入口，并让域名解析交给代理路径。命令仅适用于设备已经提供 curl 且入口为示例端口的情况；它不会验证所有应用或 TUN 接管。若连接被拒绝，优先检查本地监听；若进入代理后失败，再查看路由与远端日志。测试域名只是用于发起普通请求，不代表所有业务目标具有相同网络条件。

curl --proxy socks5h://127.0.0.1:10808 --connect-timeout 10 --max-time 20 -I https://example.com/

把解析失败与握手失败分开

无法解析服务器域名时，远端握手还没有开始。先检查基础 DNS、当前网络以及是否形成代理解析循环。能解析但连接超时时，再检查端口可达性、防火墙和来源状态。超时并不能说明协议参数正确；它只表示某个等待没有按时结束。连接建立后立即关闭，则更值得检查协议、安全和传输参数是否与服务端一致。

证书相关错误应先检查系统时间、服务器名称和证书链，不应直接关闭验证来掩盖原因。传输采用路径或服务名称时，大小写、前导斜杠与空格都可能影响匹配。REALITY 参数也需要按来源原样核对，不能从相似条目借用。公开排错信息时，只保留错误类别与字段名称，将身份标识、地址令牌等敏感内容隐藏。

按功能逆序撤回复杂设置

如果问题出现在刚启用某项功能后，先撤回该项。复杂组合可以按 FakeDNS、TUN、自定义 DNS、自定义路由的顺序逐步退回普通代理基线，但每次回退后都应重新测试。关闭 FakeDNS 后还要处理旧缓存，关闭 TUN 后还要确认系统路由恢复。只把界面开关改回去，不一定已经清除了先前连接和缓存产生的影响。

订阅更新失败与网页访问失败应分开测试。若代理请求正常而订阅失败，检查来源地址、响应内容及更新方式；若订阅更新正常但服务器不能连接，更新成功不能证明连接参数可用。多个来源同时异常时，先调查共同入口和基础网络。只有某个条目失败时，保留其他可用条目作为对照，不要同时删除全部来源。

部分应用异常时，比较它与正常应用的入口方式、独立 DNS、UDP 使用及应用排除设置。网页正常不能证明 UDP 正常，系统代理正常也不能证明虚拟接口正常。应用已经建立的长连接还可能沿旧出口运行，需要重新建立连接再判断。更完整的远端检查顺序可参阅节点超时排查笔记。

问题解决后整理最小变更记录：原现象、确认的失败层、实际修改和恢复测试。临时提高日志级别后应恢复日常设置，避免长期积累含目标地址的记录。若无法复现，先保持稳定基线，不再追加未经验证的优化。重新学习首次连接流程可回到快速上手；需要更换平台安装入口时使用客户端下载页。一条能解释、能验证、能撤回的配置链，比堆叠更多开关更适合长期维护。