V2Ray 进阶配置
系统查阅手册

配置分层与修改顺序

进阶配置最常见的问题不是某个参数写错，而是把不同层级的职责混在一起。例如，服务器过滤只决定客户端列表中哪些条目便于选择，并不直接决定浏览器流量是否经过代理；路由规则负责把已经进入内核的连接分配给不同出站，却不能接管没有遵循系统代理的应用；TUN 能扩大接管范围，但不会自动修正错误的 DNS 服务器或无效节点。把配置拆成输入、选择、接管、解析、判定和出站六层，可以显著缩短排查路径。

从输入到出站的完整链路

输入层包括订阅地址、单条分享链接和手工配置。客户端更新订阅后，把远端内容转换为本地服务器条目。选择层负责当前活动服务器、服务器分组和筛选结果。接管层决定哪些应用流量会进入内核：系统代理通常覆盖遵循系统代理设置的程序，TUN 则通过虚拟网络接口接收更广泛的 IP 流量。解析层把域名转换为地址，路由层根据域名、地址、端口、协议等条件匹配规则，最后由代理、直连、阻断或自定义出站完成连接。

这条链路具有明确的先后关系。浏览器没有进入系统代理时，调整路由规则不会改变结果；DNS 已在操作系统侧提前解析时，仅依赖域名规则可能得不到预期匹配；路由命中代理出站后，如果当前服务器不可用，连接仍会失败。因此，每次修改都应回答两个问题：变更发生在哪一层，以及用于证明它生效的观察点是什么。只有把验证点和变更层对应起来，才能避免同时改动多个选项后无法判断真正原因。

建立可回退的配置基线

开始进阶调整前，应先保留一份能够正常连接的基线。基线不需要复杂：保留一个已验证服务器、默认路由、明确的 DNS 设置，以及当前使用的系统代理或 TUN 状态。随后一次只改一个主题，例如先完成订阅分组，确认服务器选择不受影响，再进入路由配置。若客户端提供配置备份或导出功能，可在关键阶段保存快照；也可以记录界面选项、规则顺序与测试结果，避免仅依靠记忆恢复。

验证基线时不要只测试单个网页。至少应包含一个预期直连的域名、一个预期代理的域名、一个纯 IP 连接场景和一次 DNS 查询。测试结果需要能够区分“没有进入客户端”“进入后路由错误”“DNS 返回异常”和“选中服务器不可用”。在 Windows 上可结合任务管理器、系统代理设置和客户端日志观察；macOS 与 Linux 可查看当前路由、代理设置和解析状态；Android 端的 v2rayNG 或 v2flyNG 则以连接日志、虚拟网络授权状态和目标应用表现为主要依据。

客户端界面名称可能随版本与平台略有差异，但核心关系不会改变。v2rayN 是桌面平台的首选管理客户端，适合集中维护订阅、路由与出站；Android 上的 v2rayNG 使用 Xray 内核体系，v2flyNG 则以 V2Fly 内核为主要选择。跨平台迁移时应迁移“配置意图”，而不是假设菜单位置和全部字段完全相同。先确认目标平台支持对应能力，再逐层重建配置，通常比直接复制一份庞大配置更容易发现兼容边界。

订阅分组与服务器过滤

订阅条目变多后，真正影响使用效率的不是列表长度本身，而是能否稳定地找到符合当前任务的服务器。分组负责给服务器建立长期归属，过滤负责在某次选择中缩小候选范围。两者应分开设计：分组表达来源、用途或维护边界，过滤表达名称匹配条件。把过滤结果当作永久分类，容易在订阅改名后失效；把所有条目塞进单一分组，又会让更新、测速和故障定位互相干扰。

按来源还是按用途分组

来源分组最容易维护：每个订阅地址对应一个分组，更新失败时可以直接定位来源，也便于撤销某个订阅而不影响其他条目。用途分组更适合已经建立稳定命名规则的环境，例如把日常浏览、开发测试和临时备用拆开。实际配置通常采用两级思路：底层保留来源边界，上层通过筛选或收藏形成用途视图。这样既能追踪条目来自哪里，也能减少日常选择时的信息噪声。

分组名称应稳定、短而可辨认，不要把更新日期或临时状态写进长期名称。更新日期属于日志信息，线路状态则应通过实际连接测试判断。若多个订阅中出现同名服务器，可以在导入阶段增加来源前缀，或者让分组承担来源区分，避免在服务器名称中堆叠过多标签。名称越复杂，正则过滤越容易误匹配，后续订阅方调整命名时也更难兼容。

构造可维护的过滤表达式

服务器过滤通常针对备注名称执行文本或正则匹配。应先从最小条件开始，例如只匹配一个稳定关键词，再逐步加入同义写法。正向过滤适合从大量条目中选择特定区域、用途或线路标识；反向过滤适合排除测试条目、过期标识或明确不适用的架构。过滤表达式不应依赖“第几个字符”这类脆弱位置，而应依赖相对稳定的完整词段和分隔符。

常用过滤思路：

包含任一关键词：
(办公|开发|备用)

匹配名称开头的来源标记：
^(来源甲|来源乙)[-_ ]

排除带有临时或过期标记的条目：
^(?!.*(临时|过期)).*$

同时要求两个条件：
^(?=.*开发)(?=.*TCP).*$

正则中的括号用于分组，竖线表示多个候选，点号与星号组合表示任意长度文本，前瞻可用于要求或排除某个条件。录入表达式前要确认客户端对应输入框是否启用正则模式；如果只是普通文本搜索，特殊符号会被当作字面字符。过滤后还应人工抽查列表首尾与边界名称，确认没有把同音、缩写或嵌套词错误纳入。

不要用过滤结果替代连接质量判断。名称只能表达订阅发布者提供的标签，不能证明实时可用性，也不能代表当前网络路径。筛选完成后，应在候选集合中执行真实连接测试，而不是只看基础连通结果。连接测试需要访问实际目标并观察握手结果；若测试全部失败，应先取消过滤确认原始列表是否正常，以区分“表达式没有匹配到条目”和“匹配条目本身不可连接”。

更新后保持选择稳定

订阅更新可能新增、删除或重命名条目。当前选中服务器若被删除，客户端可能回退到其他条目，也可能保留一个无法继续使用的旧引用。更新后应检查当前选择是否仍属于目标分组，并重新执行一次实际连接。对于承担固定任务的配置，不建议只依赖列表序号，因为排序变化会让原来的第一项变成不同服务器。更稳妥的方法是使用唯一且稳定的名称规则，或者在更新后由人工确认活动条目。

如果过滤条件突然得到空列表，先查看未过滤的原始分组。原始分组为空，问题在订阅更新或解析；原始分组有内容但过滤为空，问题在名称变化或表达式；过滤有结果但无法连接，问题才可能落在节点、网络、DNS 或传输配置。把这三个分支分开处理，可以避免因列表为空而误改路由或 TUN。关于首次选择与真实连接测试的顺序，可同时参考v2rayN 首次连接步骤。

当分组规则成熟后，应把它写成简短的维护约定：每个来源使用什么前缀，哪些关键词允许用于用途筛选，哪些临时标签会被排除，以及更新后需要执行哪些检查。这份约定比复杂表达式本身更重要，因为它让后续新增订阅仍能进入同一套结构。若规则只有创建者能够理解，随着名称变化，分组很快会重新退化为杂乱列表。

多订阅管理与更新边界

多订阅管理的目标不是把更多地址集中导入，而是让来源之间保持可识别、可停用、可恢复的边界。每个订阅都可能拥有独立的更新周期、命名方式和服务器字段。如果所有来源更新后直接混在同一个无标识列表中，一旦出现重复条目、批量失效或命名冲突，就很难判断应该修复哪一条输入。合理的多订阅结构应先保证来源隔离，再考虑统一筛选和日常使用便利。

为每个来源建立独立生命周期

新增订阅时，先记录用途、来源标识和预期更新方式，再执行首次更新。更新成功只说明客户端取得并解析了内容，还需要抽查服务器数量变化、关键字段和至少一个真实连接。某个来源临时异常时，应优先停用该来源或暂停自动更新，而不是立即删除。停用能保留既有配置和排查线索；确认不再使用后再移除，可以减少误操作造成的恢复成本。

自动更新间隔不宜只追求频繁。更新过密会增加不必要的请求，也可能让正在使用的列表在工作过程中发生变化。对稳定来源，可以安排在可观察的固定时段更新；对临时来源，可以保留手动更新。若客户端支持启动时更新，应考虑启动频率与网络环境：设备每次唤醒都更新可能造成状态反复，而长期不重启又会错过变化。关键不是统一间隔，而是知道更新发生在什么时候，以及更新后是否执行验证。

处理重复条目与名称冲突

不同订阅可能包含相同服务器，也可能只是名称相同但实际参数不同。不能仅凭备注名称直接判定重复。判断时应比较地址、端口、协议、传输、安全设置和服务器标识等关键字段。两个条目名称一致但传输参数不同，可能承担不同入口；两个名称不同但连接字段完全一致，则可能只是不同来源的重复发布。保留重复项会增加选择噪声，但贸然合并也可能丢失更新归属。

稳妥方法是保留来源分组，并在日常用途视图中过滤或收藏一个主要条目。这样即使主要来源更新失败，仍能回到其他来源检查同类配置。若需要重命名，尽量使用客户端本地备注能力，不要直接修改订阅内部关键字段。订阅下次更新时，本地名称是否保留取决于客户端合并策略，因此重命名前应确认更新行为，并避免把重要分类完全建立在可能被覆盖的手工名称上。

更新失败的分层判断

订阅更新失败时，先区分获取失败与解析失败。获取失败通常表现为无法建立连接、返回状态异常或超时，此时要检查订阅地址是否完整、当前网络是否能够访问，以及系统代理是否形成循环。解析失败则表示已经取得内容，但格式不符合客户端预期，可能是返回了网页提示、编码内容发生变化，或订阅类型选择不匹配。不要在未查看返回类型时反复刷新，因为重复请求不会修正格式问题。

如果订阅地址只有在代理开启时可访问，要明确更新请求走哪个出站。某些配置会让客户端更新自身订阅时经过当前代理，如果活动服务器已失效，就会形成“需要更新才能取得新条目，但更新又依赖旧条目”的闭环。处理方法是临时选择一个可用来源、调整订阅更新的代理策略，或在可直连环境下完成更新。修改后应恢复原有策略并记录原因，避免下一次更新再次遇到同样问题。

订阅格式之间的差异也会影响多来源合并。Base64 列表、单条分享链接和原生 JSON 配置承载的信息范围不同，转换时可能丢失路由、DNS 或自定义出站等全局设置。服务器订阅应主要承担服务器条目分发，客户端全局路由与 DNS 则由本地配置维护。不要期望单条分享链接完整表达整套客户端策略。有关格式边界与转换字段，可阅读V2Ray 订阅格式解析。

成熟的多订阅方案应能回答三个问题：某个服务器来自哪里，某个来源失败时影响哪些用途，以及恢复后如何验证。建议定期清理长期停用的来源，但清理前先导出必要配置，并确认没有路由规则或收藏项依赖其名称。跨设备迁移时先迁移来源与分组，再迁移用途筛选；等基础条目稳定后，最后恢复路由和自定义出站。这个顺序能够把输入问题与高级策略问题清楚分离。

路由规则实战与命中顺序

路由规则的作用是为已经进入内核的连接选择出站。常见条件包括域名、目标 IP、端口、网络类型、协议和进程信息，常见结果则是代理、直连、阻断或自定义出站。规则系统通常按照既定顺序匹配，连接命中一条可执行规则后就不再继续向下。因此，路由配置的核心不是规则数量，而是条件是否互斥、顺序是否清晰，以及默认流量最终落到哪里。

先定义结果，再编写条件

编写规则前应先列出预期结果，例如：局域网与本机地址直连；明确的工作域名走指定代理；特定更新服务直连；其余流量使用默认代理。结果明确后，再为每一类流量选择最稳定的判断条件。域名规则便于阅读，但依赖内核能够获得域名信息；IP 规则适合地址范围稳定的目标；端口规则范围较宽，通常只应作为辅助；进程规则具有平台差异，不适合直接复制到所有设备。

宽泛条件应放在具体条件之后。若第一条规则把全部 TCP 与 UDP 都发送到代理，后续局域网直连规则就没有机会生效。相反，如果先放置一个过宽的直连域名后缀，也可能让本应代理的子域名提前直连。排查规则顺序时，可以暂时把目标域名单独放在最前，并指定一个容易识别的出站；确认匹配后，再逐步恢复其他规则，观察是哪一条产生覆盖。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": [
          "full:docs.example.com",
          "domain:example.net"
        ],
        "outboundTag": "proxy"
      },
      {
        "type": "field",
        "network": "tcp,udp",
        "outboundTag": "proxy"
      }
    ]
  }
}

示例中的 full: 表示完整域名匹配，domain: 通常包含该域名及其子域名，geoip:private 用于识别私有地址范围。最后一条网络规则承担默认出口，因此必须位于具体规则之后。示例域名仅用于说明结构，实际配置应替换为需要控制的目标。若客户端使用图形化路由编辑器，应把同样的条件拆入对应字段，而不是把整段 JSON 粘贴到不接受完整配置的输入框。

理解域名策略与解析时机

domainStrategy 决定域名规则未命中时是否继续解析 IP，并尝试 IP 规则。AsIs 倾向于保留原始域名进行匹配，不主动为了路由而解析；IPIfNonMatch 会在域名规则未命中时解析并继续检查 IP；某些内核还提供更积极的解析策略。策略越积极，IP 规则覆盖越完整，但也会增加 DNS 查询，并让解析路径对路由结果产生更直接的影响。

如果应用已自行解析域名并只把目标 IP 交给内核，域名规则可能无法获得原始名称。TUN 嗅探、FakeDNS 或应用代理方式会影响域名信息是否可见。遇到“域名规则看似正确却不命中”时，应先查看日志中目标究竟以域名还是 IP 出现，再决定调整解析策略、启用合适的嗅探，或补充 IP 条件。盲目添加更多域名后缀不会解决内核没有取得域名的问题。

建立最小规则集并逐步扩展

建议从三段式规则开始：私有地址直连、少量明确目标按需分流、其余进入默认出站。确认稳定后，再增加更新服务、开发环境或特定进程规则。每新增一组规则，都要准备正向与反向测试：一个应该命中的目标和一个不应该命中的相似目标。例如配置 domain:example.net 后，应同时测试根域名、一个子域名以及名称中仅包含相似字符串的其他域名。

路由排错应优先查看连接日志中的目标、命中规则和出站标签。如果日志只显示连接失败而没有规则信息，可暂时提高客户端日志级别，完成测试后再恢复，避免长期产生大量记录。若目标命中了正确出站但仍失败，问题已经离开路由层，应转向服务器、DNS 或传输连接；若目标没有进入任何日志，则先检查系统代理、TUN 或应用自身代理配置。

系统代理、全局模式和按规则分流控制的是不同维度。系统代理决定部分应用是否把请求交给客户端，路由模式决定内核收到连接后如何选择出口。需要重新确认两者关系时，可参考V2Ray 系统代理怎么选。当规则表现随网络变化而波动时，还要检查 DNS 返回地址是否改变，因为依赖 IP 范围的规则可能因解析结果变化而命中不同出口。

DNS 配置优化与解析路径

DNS 配置的关键不是简单替换一个服务器地址，而是确定查询由谁发起、经过哪个出站、返回结果供哪一层使用。操作系统、浏览器、客户端内核和远端服务器都可能参与解析。若同一域名在不同层被重复解析，得到的地址可能不同，路由判断也会随之变化。优化 DNS 前应先画出查询路径，明确本地解析、内核解析和远端解析之间的边界。

区分系统 DNS 与内核 DNS

系统 DNS 服务于没有被客户端接管的普通程序，也可能在应用进入代理前完成解析。内核 DNS 则供路由、TUN 或内核自身连接使用。系统代理模式下，支持域名代理的应用可能把域名直接交给代理内核，也可能先在本地解析；具体行为取决于应用与代理类型。TUN 模式下，客户端通常有更多机会截获 DNS 流量，但仍需正确设置 DNS 劫持、路由和排除项。

诊断时不要只修改操作系统 DNS 后观察网页。应分别检查系统查询与客户端日志。在 Windows 可使用 ipconfig /flushdns 清理系统缓存，再执行 nslookup 或 PowerShell 查询；macOS 可用 scutil --dns 查看解析器顺序；Linux 可根据系统环境使用 resolvectl status 检查当前上游。清理缓存只用于排除旧结果，不应被当作长期解决方案。

Windows:
ipconfig /flushdns
nslookup docs.example.com

macOS:
scutil --dns
dscacheutil -q host -a name docs.example.com

Linux:
resolvectl status
resolvectl query docs.example.com

按域名选择解析服务器

复杂环境可以为不同域名选择不同 DNS 服务器。例如，局域网内部域名需要交给本地解析器，公共域名交给常规上游，特定目标则通过代理出站查询。分流 DNS 的价值在于保持内部名称可解析，并让外部查询路径与路由意图一致。配置时应先放具体域名规则，再放默认服务器，避免默认项提前覆盖。局域网解析器还应设置明确的地址范围，防止它被错误地通过代理访问。

{
  "dns": {
    "hosts": {
      "router.internal": "192.168.1.1"
    },
    "servers": [
      {
        "address": "192.168.1.1",
        "domains": [
          "domain:internal"
        ],
        "skipFallback": true
      },
      "1.1.1.1",
      "8.8.8.8"
    ],
    "queryStrategy": "UseIP"
  }
}

hosts 适合少量固定映射，不适合维护频繁变化的大型域名集合。带 domains 的服务器只处理匹配范围，skipFallback 用于控制失败后是否进入其他候选。queryStrategy 决定查询地址族的倾向，应结合当前网络是否具备稳定的 IPv4 或 IPv6 连接选择。若网络没有可用的对应地址族，却强制只查询该类型，可能表现为域名可见但连接始终超时。

缓存、回退与循环查询

DNS 缓存可以减少重复查询，但会让配置变更后的旧结果继续存在。调整解析服务器、域名规则或 FakeDNS 后，应同时考虑操作系统缓存、浏览器缓存和内核缓存。关闭再开启代理并不一定清除所有层级。测试时可以使用一个此前未查询过的子域名，或者按平台清理相关缓存。若清理后短暂正常、随后再次异常，要检查是否存在多个解析器轮流返回不同结果。

回退机制需要清晰边界。默认服务器查询失败后切换备用服务器可以提高可用性，但如果不同服务器承担不同分流意图，任意回退可能把内部域名发送到不合适的上游，或返回与路由不一致的地址。内部域名通常应禁止向公共上游回退；普通公共域名可以配置有序候选。判断回退是否发生，不能只看最终地址，还应查看日志中的实际查询服务器。

循环查询通常出现在 DNS 请求被路由到代理，而代理服务器域名本身又需要同一套代理 DNS 才能解析。解决思路是为服务器地址建立启动链路：优先使用已知 IP、为服务器域名单独指定可直接访问的解析器，或让对应 DNS 请求走不依赖当前代理的出站。修改时要保留最小直连解析能力，否则客户端可能在启动阶段就无法获得代理服务器地址。

当连接速度变慢或部分域名偶发失败时，DNS 只是可能原因之一。应同时检查服务器状态、网络线路、代理模式和本机资源占用，避免把所有波动都归因于解析。可按照V2Ray 速度慢分层排查中的顺序，先确定故障层，再决定是否调整 DNS。配置优化的标准是路径可解释、结果可复现，而不是堆叠尽可能多的上游服务器。

TUN 模式的接管范围与排除项

TUN 模式通过虚拟网络接口接收系统流量，适合不遵循系统代理、使用独立网络栈或需要处理更多 UDP 流量的程序。它改变的是流量进入客户端的方式，并不会自动替代订阅选择、DNS 和路由配置。启用 TUN 后，原本没有进入日志的应用可能开始被内核处理，错误路由与 DNS 问题也会因此更明显。使用前应先确保普通代理模式能够稳定连接，再扩大接管范围。

系统代理与 TUN 的选择

日常浏览和遵循系统代理设置的桌面应用，通常先使用系统代理，配置简单且影响范围可控。遇到应用忽略系统代理、需要接管特定 UDP 连接，或希望统一应用层差异时，再考虑 TUN。不要仅因为某个网站打不开就立即切换 TUN；如果原因是服务器不可用或路由错误，切换接管方式只会增加新的变量。先检查目标请求是否已经出现在客户端日志中，若已经出现，问题通常不在接管层。

TUN 需要创建虚拟接口并调整系统路由，在 Windows、macOS 与 Linux 上可能涉及不同权限和网络组件。v2rayN 的界面会根据平台提供相应入口，具体权限提示应按系统要求完成。Android 上 v2rayNG 与 v2flyNG 通过系统提供的虚拟网络授权接管流量，运行逻辑与桌面配置入口不同。跨平台参考时应比较接管目标、DNS 流向和排除规则，不要照搬设备名称或接口编号。

路由表、MTU 与网络循环

启用 TUN 后，客户端会添加或调整系统路由，使目标流量进入虚拟接口。若默认路由、物理网卡路由与虚拟接口优先级冲突，可能出现连接绕回、局域网不可达或客户端服务器自身流量再次进入 TUN。排查时先查看系统路由表，确认代理服务器地址、局域网地址和 DNS 上游的路径。代理服务器连接必须能够从真实网络接口发出，不能再次被同一个 TUN 接管。

MTU 决定单个网络包在接口上的最大尺寸。设置过大可能在某些路径产生分片或丢包，表现为小请求正常、大页面或文件传输停滞；设置过小则增加包数量和额外开销。出现握手正常但持续传输异常时，可把 MTU 作为排查项，但不应在没有证据时随意修改。先比较不同网络环境、不同目标和不同协议的表现，再小幅调整并记录结果。

网络循环还可能来自应用自身代理与 TUN 同时生效。例如某个程序手工设置了本地代理端口，其连接先进入本地代理，代理出站又被 TUN 捕获，若排除规则不完整就会重复进入。解决时应选定单一入口：要么让应用使用本地代理并排除客户端进程，要么取消应用手工代理，让 TUN 直接接管。客户端核心进程、更新请求和必要的本地监听地址通常需要明确排除。

排除局域网与关键进程

局域网打印、文件共享、路由器管理和本地开发服务通常应保持直连。路由层可以用私有地址规则指定直连，TUN 层也可能提供绕过地址或应用列表。两层规则应保持一致：如果 TUN 在接管前就排除了某段地址，内核路由不会看到这些连接；如果 TUN 接管后由内核直连，则可以在日志中观察匹配结果。选择哪种方式取决于是否需要记录与控制这类流量。

进程排除适合解决客户端自身循环或明确不希望接管的应用，但进程名可能随启动器、子进程和平台变化。仅排除主程序不一定覆盖它创建的网络服务。更稳定的方式是先从地址与路由边界处理，再把进程排除作为补充。每次更新应用后，若接管行为发生变化，应重新检查实际发起网络连接的进程，而不是默认旧名称仍然有效。

TUN 故障可按“接口是否创建、路由是否写入、DNS 是否进入预期路径、目标是否命中规则、出站是否可连接”的顺序排查。关闭 TUN 后立即恢复，说明问题集中在虚拟接口、路由或 DNS 接管；关闭后仍异常，则要检查系统代理是否残留、客户端进程是否仍运行，以及操作系统路由是否恢复。必要时先退出客户端，再重新连接物理网络，以干净状态验证基础网络。

FakeDNS映射原理与适用边界

FakeDNS 的核心做法是：客户端收到域名查询后，不立即把真实目标地址返回给应用，而是从专用地址池分配一个临时映射地址。应用随后连接这个地址，内核根据映射表还原原始域名，再执行域名路由和远端解析。这样即使应用只发起 IP 连接，内核仍能保留域名信息。它主要解决 TUN 场景下域名丢失和本地提前解析的问题，不是提高所有连接速度的通用开关。

一次查询与连接如何完成

应用首先向 DNS 请求 service.example.com，FakeDNS 从地址池返回一个映射地址，同时记录“映射地址对应原始域名”。当应用向该地址发起连接时，TUN 把流量交给内核，内核查表恢复域名，再用域名规则选择出站。若代理协议和服务端支持远端解析，真实 DNS 查询可以在后续链路中完成。映射表有容量和生命周期，过期后旧地址不能无限期保持同一关系。

这个过程要求 DNS 查询与后续连接都进入同一套内核。如果 DNS 被浏览器的独立加密解析绕过，而连接又进入 TUN，内核可能只看到真实 IP，FakeDNS 就没有参与；反过来，如果 DNS 返回了映射地址，但连接绕过 TUN 直接发往物理网络，该地址不会在公网得到正确响应。启用前必须保证查询和连接路径一致，否则故障表现往往是域名解析得到地址，但任何连接都立即失败。

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

198.18.0.0/15 是常用于基准测试与映射用途的保留地址范围，不应与实际局域网地址重叠。poolSize 控制可分配映射数量，实际支持方式取决于所用内核与客户端生成的配置。图形客户端若已提供 FakeDNS 选项，应优先通过界面配置，以便同时生成所需的 DNS、嗅探和路由关系；直接插入局部 JSON 时要确认最终配置不会出现重复字段或互相覆盖。

地址池冲突与旁路连接

选择地址池时，应检查企业网络、虚拟机、容器和其他网络软件是否已经使用相同范围。地址冲突会让系统把映射流量发送到错误接口，或者让真实内部地址被当成 FakeDNS 结果。可以在启用前查看路由表，确认该网段没有更具体的现有路由。若冲突无法避免，应根据内核支持选择其他保留范围，并同步更新 TUN 路由和排除设置。

某些应用会缓存 DNS 地址很长时间，甚至在网络切换后继续使用旧映射。客户端重启后映射表可能已经变化，应用仍持有旧地址，就会出现只有该应用失败的情况。处理时应同时重启目标应用或清理其 DNS 缓存。频繁切换 FakeDNS 开关也会使缓存状态难以判断，因此测试期间应固定配置，完成一轮查询、连接和重启验证后再决定是否保留。

局域网域名、打印机发现、设备广播和需要真实 IP 的应用通常不适合进入 FakeDNS。内部域名可以交给局域网 DNS，并通过域名规则跳过映射；私有地址应维持直连。对于依赖返回地址进行访问控制或证书绑定的程序，也要确认映射不会破坏其工作流程。FakeDNS 更适合需要在 TUN 中恢复公共域名信息的普通 TCP 与 UDP 连接。

与嗅探和域名路由的配合

嗅探可以从部分应用层协议中恢复目标域名，FakeDNS 则从 DNS 映射关系中恢复域名，两者并非简单替代。嗅探依赖协议内容可识别，对于加密或非标准流量不一定有效；FakeDNS 依赖查询和连接都经过内核。实际配置可根据流量类型组合使用，但要避免把所有目标都强制覆盖为嗅探结果。日志中应能区分原始目标、嗅探目标和 FakeDNS 映射目标。

验证 FakeDNS 时，先查询一个未缓存域名，确认返回地址位于映射池；随后立即连接该域名，检查日志是否恢复原始名称并命中预期域名规则；最后测试一个局域网域名，确认它仍由内部 DNS 返回真实地址。三步都通过，才说明映射、还原和排除关系完整。仅看到保留地址不能证明配置成功，因为后续连接可能并未被 TUN 捕获。

是否启用 FakeDNS 应由实际问题决定。如果普通 DNS 与域名路由已经稳定，且应用能够把域名交给客户端，没有必要为了配置复杂度而切换。若 TUN 下大量连接只显示 IP、域名分流无法可靠工作，再评估 FakeDNS。上线前应测试浏览器、日常应用、局域网资源和网络切换，并保留关闭后的回退方案。

自定义出站、链式连接与总体验证

出站是路由判定后的执行目标。基础配置通常包含代理、直连和阻断三类出站，进阶场景还可能需要按接口直连、指定 DNS 出站、链式代理或为某类流量设置独立连接参数。自定义出站的价值在于表达清晰的网络路径，而不是增加层数。每增加一个出站，都应有唯一标签、明确调用它的路由规则，以及能够单独验证的目标。

使用稳定且可读的标签

出站标签会被路由规则、DNS 配置和链式关系引用。标签应使用简短稳定的英文或数字组合，例如 proxy-main、direct-lan、dns-direct，避免使用会随服务器名称变化的描述。修改标签时要同步检查所有引用；标签拼写不一致通常会在配置加载阶段报错，也可能让规则回退到默认出站。图形客户端自动生成的标签不应随意覆盖，先确认哪些字段允许用户扩展。

{
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct-lan",
      "settings": {
        "domainStrategy": "UseIP"
      }
    },
    {
      "protocol": "blackhole",
      "tag": "blocked"
    }
  ],
  "routing": {
    "rules": [
      {
        "type": "field",
        "ip": [
          "geoip:private"
        ],
        "outboundTag": "direct-lan"
      },
      {
        "type": "field",
        "domain": [
          "domain:blocked.example"
        ],
        "outboundTag": "blocked"
      }
    ]
  }
}

freedom 表示由本机直接建立连接，blackhole 用于拒绝匹配流量。阻断规则应针对明确目标，避免使用过宽条件影响正常服务。示例只展示出站与路由引用关系，不包含服务器配置。若需要把自定义出站加入 v2rayN，应先确认当前配置模板的合并方式；有些界面会在保存时重新生成核心配置，手工修改生成文件可能在切换服务器后被覆盖。

链式连接的依赖关系

链式连接表示一个代理出站通过另一个出站建立底层连接。它适用于确有中间路径需求的环境，但每一层都会增加故障点。配置前应分别验证前置出站和目标出站能够独立工作，再建立链式关系。若前置层失败，后续层的日志可能只表现为握手超时；若后续层参数错误，前置层看起来仍然连接正常。排查时必须能拆开链路逐段测试。

链式配置还要防止环路。出站甲通过出站乙拨号，而出站乙又因路由规则被发送回出站甲，就会形成无法完成的循环。建立链式关系时，应明确服务器地址的解析与连接使用哪个底层出口，并为必要地址设置不依赖链路的启动规则。DNS 同样要避免依赖尚未建立的最终出站，否则客户端启动时无法解析任何一层服务器。

不要把服务器列表中的多个普通条目误解为自动链式连接。客户端切换当前服务器通常只是更换主要代理出站，只有明确配置了代理转发关系，流量才会逐层经过多个出站。链路越长不代表连接质量越高，实际效果取决于每段网络路径、协议开销和故障恢复方式。没有明确需求时，单一可验证的代理出站更容易维护。

按网络接口或地址族直连

多网卡设备可能同时连接有线网络、无线网络、虚拟网络和企业网络。自定义直连出站可用于指定本地地址或接口，使特定流量从预期网络发出。配置前应确认接口名称和本地地址是否稳定；自动分配地址变化后，写死的绑定可能失效。Linux 与 macOS 更常通过系统路由和策略路由控制接口，Windows 则需要同时关注接口跃点与客户端出站绑定。

地址族策略也属于出站边界。若某个网络只有稳定的 IPv4 连接，自定义出站不应强制使用不可达的 IPv6；反之亦然。DNS 返回的地址族、路由规则和出站连接策略需要一致。出现域名有多个地址但连接只在部分网络失败时，应分别测试不同地址族，而不是仅更换服务器。调整后还要确认直连与代理出站是否采用相同策略，避免同一域名在两个出口表现不同。

保存、重载与最终验收

完成自定义出站后，应先验证配置能被内核加载。语法错误、未知标签或不受支持字段通常会在启动日志中出现。加载成功不代表路径正确，接下来要为每个出站选择一个明确测试目标：局域网地址验证直连，指定域名验证主要代理，阻断目标验证拒绝规则，自定义链路则逐层确认。测试时记录目标、命中规则、出站标签与结果，形成可重复的验收表。

图形客户端可能在切换服务器、更新订阅或更改路由方案时重新生成运行配置。保存自定义内容后，应执行一次完整流程：重启客户端、更新一个测试订阅、切换服务器、重新加载路由，再确认扩展配置是否仍然存在。若内容被覆盖，应改用客户端支持的自定义配置入口、模板或合并功能，而不是反复编辑临时运行文件。长期配置必须放在客户端认可的持久化位置。

完整进阶配置应保持“输入可追踪、规则可解释、DNS 可观察、接管可回退、出站可单测”。当连接异常时，先找出请求停在哪一层，再查看该层的日志与系统状态。若需要重新建立最小环境，可回到快速上手主线完成基础连接，再逐章恢复高级能力；客户端安装或平台选择问题可前往安装包页面。这种从最小基线逐层恢复的方法，比同时重建订阅、路由、DNS 和 TUN 更容易得到确定结论。