V2Ray 进阶配置手册

分清界面设置、内核配置与系统网络状态

进阶配置最容易出现的问题，不是某个参数完全写错，而是同时改动了多个层级。v2rayN 的界面负责订阅、服务器选择、系统代理、TUN 开关与配置生成；Xray 或 V2Fly 内核负责执行入站、出站、DNS 和路由；操作系统则决定默认路由、网络接口、名称解析顺序与应用是否绕过代理。三个层级会互相影响，但排查时必须拆开。看到“客户端显示已启动”只能说明进程进入运行状态，不能直接推导出系统流量已经按预期进入内核。

开始修改前，先保留一套已知可用的普通系统代理配置。选择一个能够正常连接的服务器，使用默认路由模式，关闭 TUN 与 FakeDNS，确认浏览器和一个常用桌面程序都能访问目标站点。随后记录当前订阅分组、活动服务器、系统代理状态、DNS 设置和路由模式。这样做的意义在于建立对照组：后续启用某项功能后出现异常，可以立即退回基线，而不是在多个未知变量之间来回试错。

配置文件应按职责理解。常见结构中的 inbounds 接收来自系统代理或 TUN 的流量，outbounds 定义代理、直连和阻断等出口，routing.rules 决定流量落到哪个出口，dns 决定域名怎样解析。路由规则中的 outboundTag 必须与出站的 tag 完全对应；DNS 服务器的选择也可能受到路由规则影响。只复制其中一段而忽略关联标签，通常会得到能载入但行为不完整的配置。

用最小改动法确认问题边界

建议按照“订阅整理 → 路由 → DNS → TUN → FakeDNS → 自定义出站”的顺序推进。订阅和服务器过滤只影响可选服务器集合，风险较低；路由与 DNS 会改变请求去向；TUN 接管范围更广；FakeDNS 又依赖 TUN 或透明代理链路。顺序反过来时，一旦域名解析或网络接口出现问题，很难判断根因来自服务器、路由、DNS 还是虚拟网卡。

每次改动后至少做三类验证。第一类是域名访问，选择一个明确的网页确认 HTTP 与 TLS 连接；第二类是直接 IP 连接，用于区分 DNS 故障和传输故障；第三类是应用覆盖，分别检查遵循系统代理的程序与不读取系统代理的程序。若域名失败而直接 IP 正常，优先检查 DNS；若浏览器正常而其他程序失败，优先判断该程序是否进入系统代理或 TUN；若全部失败，再检查当前服务器、出站标签与内核日志。

日志查看也应有明确目标。启动阶段重点找配置解析、端口占用、权限和虚拟网卡错误；连接阶段重点看域名、目标端口、命中的出站标签和上游握手结果；停止阶段则确认系统代理与路由是否恢复。日志级别不宜长期保持在最详细状态，因为大量正常连接记录会掩盖关键错误。完成排查后恢复常规级别，并保留问题发生前后的一小段上下文即可。

让订阅来源和使用目的分开表达

订阅分组解决的是“服务器从哪里来”，服务器过滤解决的是“当前需要看到哪些服务器”。这两个概念不应混在一个名称里。分组名称适合记录来源或用途，例如“日常订阅”“测试订阅”“备用线路”；服务器名称则保留地区、协议或提供方原有信息。这样更新订阅后，服务器名称发生变化也不会破坏整体结构。分组命名应保持短而稳定，避免把到期日、临时状态和长说明全部塞进名称。

在 v2rayN 中添加订阅时，先为每条链接建立独立分组，再执行单组更新。首次导入不要立刻全选更新，因为一条格式异常的订阅可能让结果难以判断。更新完成后先观察服务器数量是否符合预期，再随机打开几项查看地址、端口、协议和传输字段是否完整。订阅只负责传递服务器配置，不会自动替用户决定路由策略、系统代理模式或 DNS 方案。

过滤器适合处理名称中已有稳定标记的服务器。常见做法是按关键词包含或排除，例如只看名称包含“低倍率”或特定地区缩写的项目，或者排除“维护”“剩余流量”等非连接条目。正则表达式更灵活，但也更容易误选。应用表达式前，先用普通关键词缩小范围，再考虑是否确实需要正则。中文括号、全角符号、空格和大小写差异都可能影响匹配结果。

包含任一关键词
HK|SG|JP

排除状态类名称
维护|到期|剩余流量|官网

匹配名称开头的地区标记
^(HK|SG|JP)[-_ ]

上面的表达式只展示过滤思路，实际名称应以当前订阅内容为准。过滤不会修改服务器本身，它只改变列表结果或批量操作范围。若过滤后列表为空，先清除条件，再检查名称是否使用了不同缩写。不要为了让过滤器工作而逐个手动重命名大量服务器，因为下次更新可能重新生成列表，手工名称也可能失去与源数据的对应关系。

更新、去重与失效项目的处理

同一服务器有时会被多条订阅重复提供。判断重复不能只看显示名称，还应比较地址、端口、协议以及传输层参数。名称相同可能是不同入口，名称不同也可能指向同一连接信息。最稳妥的处理方式是按分组保留来源边界，不在导入后跨组大规模合并。需要简化日常列表时，用过滤视图或固定收藏处理，而不是破坏订阅的可更新结构。

更新订阅后出现服务器消失，先确认它是被源订阅移除、被过滤条件隐藏，还是进入了另一个分组。若更新后完全没有项目，应检查订阅链接是否完整、网络请求是否成功，以及返回内容能否被客户端识别。相关基础操作可回到入门指南核对。若只有个别服务器无法连接，则应把问题归入服务器配置或网络链路，不要反复删除并重新添加整条订阅。

服务器排序也需要明确目的。按名称排序适合固定地区标记，按分组排序适合区分来源；测速结果只能反映测量时刻和测量目标，不等于所有业务的实际体验。测试前应确保当前系统没有大量下载任务，并用同一种测试方法比较。测试失败也不必立即删除服务器，因为 ICMP、TCP 探测与真实协议连接经过的流程不同，部分服务器可能不响应某类探测但仍能建立正常连接。

在 Android 上，v2rayNG 与 v2flyNG 的界面组织方式和桌面端不同，但原则一致：订阅来源保持独立，更新前确认目标分组，更新后检查当前选中的配置是否仍然存在。移动端还要留意系统后台限制，订阅更新中断与连接后台停止是两类问题。关于 VpnService 授权和省电白名单，可继续阅读v2rayNG 安卓使用要点。

把主用、备用和实验来源隔离

多订阅管理的重点不是订阅越多越好，而是避免不同来源互相覆盖。建议至少划分主用、备用和实验三种角色。主用订阅承担日常连接，变更频率应最低；备用订阅只在主用来源异常时启用；实验订阅用于观察新协议或临时配置，不应直接混入日常服务器列表。角色确定后，更新、筛选和删除都以分组为单位进行。

每条订阅都应有稳定名称和清楚用途。可以在分组名称中写来源简称与角色，但不要记录访问凭据、完整链接或其他敏感内容。订阅链接本身应只保存在客户端的订阅配置中，不要复制到截图、公开日志或共享配置示例。需要迁移设备时，优先在新设备上重新添加订阅，而不是直接复制包含本地状态、历史日志和界面偏好的整个数据目录。

更新计划应考虑来源稳定性。频繁手动刷新不会让线路本身更快，反而可能在源服务短暂异常时覆盖原有结果。日常使用可以先更新单条主用订阅，确认返回内容正常后再更新其他分组。若客户端支持保留更新前内容，应开启相应的失败保护；若没有这一选项，则在重要调整前导出不含订阅凭据的本地服务器配置或记录当前可用项。

处理同名、改名和来源迁移

订阅提供方调整命名规则后，收藏、过滤表达式和手工备注可能失效。应优先根据稳定字段重新识别服务器，例如地址、端口、协议与传输组合，而不是只看显示名称。确认是同一连接配置后，再更新过滤条件。若来源整体迁移到新订阅链接，先把新链接添加为新分组并完成一次更新，确认服务器可用后再停用旧分组，避免在替换过程中失去回退入口。

同一个连接被多个分组提供时，不建议把它们立即视为冗余。不同订阅可能有不同更新周期、参数细节或使用范围。可以先在名称过滤中隐藏重复项，等连续几次更新都确认内容一致后，再决定是否移除某一来源。删除订阅配置前，要区分“删除订阅入口”和“删除已经导入的服务器”，部分客户端会将两者分开处理。

批量操作前先限定分组。批量测速、批量删除和批量修改容易误伤其他来源，尤其在过滤器仍然生效时，界面显示范围未必等于实际操作范围。执行前应清楚确认当前分组、过滤条件与选中数量。批量改传输参数通常不推荐，因为订阅中的路径、主机名、TLS、REALITY 公钥和短标识具有服务器端对应关系，不能仅凭相似名称互换。

建立可维护的变更记录

多订阅环境中，简单的变更记录比复杂备份更实用。每次只记录日期、修改模块、修改前状态、修改后状态和验证结果。例如“启用主用分组的地区过滤，未改路由；浏览器与桌面程序连接正常”。出现问题时，就能快速找到最后一次影响范围较大的改动。记录中不要保存完整订阅链接、服务器密钥或可直接复用的认证字段。

当服务器列表突然扩大或缩小时，先比较各分组的更新时间与返回状态，再看过滤条件。若只有一个来源异常，就暂停该来源的自动更新，不要立即重建全部配置。若所有来源都无法更新，但已有服务器仍可连接，问题更可能在订阅请求、系统代理或 DNS 路径；若更新正常而所有服务器同时连接失败，则应进一步检查本地网络、活动出站和系统时间。

先理解入口、条件与出口

路由规则回答三个问题：流量从哪个入口进入、它满足什么条件、最终交给哪个出口。常用条件包括域名、IP、目标端口、网络类型、入站标签和进程信息。出口通常至少包含代理、直连与阻断三类。客户端从上到下读取规则，首个匹配结果决定出口，因此更具体的规则应放在前面，更宽泛的兜底规则放在后面。

域名规则只在内核能够获得域名时生效。如果应用先在本地解析并只向代理提交 IP，单纯的域名规则可能无法命中。反过来，IP 规则需要解析结果或直接 IP 目标。domainStrategy 决定路由模块是否以及何时为域名补充 IP 判断。常见思路是先使用域名规则，在需要匹配 IP 规则时再解析；若设置为始终仅按 IP 处理，会损失部分域名规则的可读性和控制能力。

规则设计应从业务目的出发，而不是堆叠大量列表。先列出必须直连的本地地址与局域网，再写明确需要代理的域名组，随后处理特定 IP 范围，最后设置默认出口。阻断规则只用于确定不需要建立连接的目标或协议类型。规则越多，越要保持命名、注释与顺序稳定，否则后续无法判断某条流量为何命中某个出口。

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

domain: 通常表示匹配指定域名及其子域，full: 用于完整域名匹配，普通字符串规则的具体解释取决于内核格式。对单个明确主机优先使用完整匹配，对一个服务的多个子域使用域名后缀匹配。不要用过短的关键词做宽泛匹配，例如只写一个常见单词可能命中大量无关域名。

从简单三段式逐步扩展

第一阶段只保留“私有地址直连、明确域名代理、其余走默认出口”三段。确认结果后，再添加需要直连的业务域名或特定 UDP 处理。若客户端提供预定义路由方案，可以先复制一份再修改，不要直接在唯一方案上反复覆盖。每条规则应有明确的验证目标，例如新增一条完整域名规则后，只测试该域名以及一个不应受影响的对照域名。

进程路由依赖客户端、内核与操作系统能力，不能作为所有平台都一致的基础规则。进程名称也可能因安装方式或子进程结构发生变化。若某个应用支持自行设置代理，优先在应用内明确配置；需要接管不读取代理的应用时，再考虑 TUN 与进程条件。Android 上的分应用代理属于系统 VPN 接管范围，与桌面端的进程路由不是同一实现。

端口规则适合协议明确的场景，但不应根据“常见端口”猜测业务。现代应用可能复用 443 或使用动态端口，仅凭端口无法准确区分服务。UDP 也不能一概阻断，因为 DNS、实时通信和部分传输会使用 UDP。若某条规则导致网页能打开但媒体、语音或登录功能异常，应检查是否错误处理了 UDP、QUIC 或相关域名。

判断路由是否生效，不要只看出口 IP。更可靠的方法是结合内核日志中的目标、规则条件和出站标签。若日志显示目标进入了错误出口，检查规则顺序和标签；若没有相关连接记录，说明流量可能没有进入该入站；若只看到 IP 而看不到域名，则要继续检查应用解析方式、嗅探设置或 FakeDNS 链路。路由配置和 DNS 紧密相连，下一章应在当前路由稳定的基础上继续。

确认是谁在解析域名

DNS 配置的第一步不是立即更换服务器，而是确定解析发生在哪里。浏览器可能启用自己的加密 DNS，操作系统有系统解析器，客户端内核也可以配置独立 DNS。若三者同时存在，实际请求可能绕过刚修改的那一层。排查时应临时统一路径：关闭浏览器独立解析或明确记录其状态，让测试域名进入客户端内核，再观察日志中的查询和返回结果。

DNS 故障通常表现为域名打不开、直接 IP 可连接，或者同一域名在不同应用中结果不同。连接超时并不自动等于 DNS 故障；如果域名已经正确解析，但目标连接在 TLS 或传输阶段失败，应继续检查服务器与路由。反过来，解析得到地址也不表示结果适合当前网络，缓存、错误上游或分流路径都可能造成连接到不期望的地址。

建议将上游按用途拆分，而不是把多个地址无序放进列表。系统 DNS 可处理局域网主机和本地网络相关域名；指定的普通 DNS 或 DoH 可处理其他查询；需要按域名分配上游时，为每个服务器配置清晰的 domains 范围。解析请求本身也要有正确出口：直连上游应通过直连出口访问，需要经代理访问的上游则要由路由规则送往代理出口。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "https://dns.example.com/dns-query",
        "domains": [
          "domain:example.net"
        ],
        "skipFallback": true
      },
      "localhost"
    ]
  }
}

示例中的域名仅用于说明结构，实际配置应换成可用的 DNS 服务地址。queryStrategy 控制查询 IPv4、IPv6 或两者的策略，应与当前网络能力一致。若网络没有稳定的 IPv6 路径，却优先返回 IPv6 地址，应用可能先等待失败再回退，表现为首连缓慢。直接禁用某类地址也不是固定答案；应先确认系统是否具备可用路由，再决定查询策略。

分流、缓存与回退的关系

分流解析的目标，是让不同域名使用适合的上游并沿正确出口发出。域名规则应尽量精确，避免同一域名同时落入多个重叠范围。回退服务器用于主匹配未得到结果或按配置允许继续查询的情况，不应被当作随机负载均衡。若配置了 skipFallback，要确认对应域名确实只能由当前上游处理，否则主上游短暂失败时不会自动转向其他服务器。

缓存会让调整后的结果看起来没有变化。内核、操作系统和浏览器可能分别缓存 DNS。修改配置后，先重启或重新载入内核，再清理系统和应用层缓存，最后用一个近期未访问的子域做对照。不要在短时间内反复切换多个上游并只测试同一个域名，这样很难区分新结果与旧缓存。

DoH 将 DNS 查询放入 HTTPS 连接，能够统一传输方式，但它本身仍需要解析 DoH 服务器域名，这会产生引导解析问题。常用处理方式是为 DoH 服务准备可直接到达的引导地址，或者让系统解析器先解析该主机。若路由把 DoH 主机送进依赖同一 DNS 的循环路径，内核可能出现查询等待。此时应检查 DNS 服务器地址、路由规则和出站标签之间是否形成递归依赖。

需要更完整地理解境内外分流解析、DoH 与污染排查时，可阅读V2Ray DNS 配置详解。实际调整仍应以当前网络和内核日志为准，不要把一套上游地址机械复制到所有设备。桌面宽带、移动网络与企业网络的解析限制不同，稳定方案往往来自明确的分工，而不是服务器数量。

TUN 与系统代理解决不同问题

系统代理依赖应用主动读取代理设置，适合浏览器和多数遵循操作系统代理的桌面软件。TUN 模式通过虚拟网络接口接收更广范围的 IP 流量，可以覆盖不读取系统代理的程序。两者不是简单的“普通模式”和“增强模式”，而是两种接入方式。只需要浏览器代理时，系统代理更容易维护；需要处理独立网络栈、游戏启动器或命令行程序时，再评估 TUN。

启用 TUN 前应确认普通系统代理已经稳定，当前服务器可以正常连接，DNS 与路由规则也能单独工作。随后关闭可能冲突的其他虚拟网卡软件，记录系统原有默认路由和 DNS 状态。v2rayN 启用 TUN 时可能需要操作系统权限来创建虚拟接口、设置路由与调整 DNS。权限被拒绝时，界面开关可能已经改变，但虚拟接口并未成功建立，因此要同时查看客户端状态和系统网络接口。

TUN 接收的是网络层流量，仍需要内核将其转换并交给路由与出站。常见配置涉及接口地址、MTU、自动路由、严格路由和协议栈实现。自动路由负责把目标流量导向虚拟接口；严格路由用于减少绕过路径，但也可能影响局域网、容器和虚拟机网络。首次启用应保留默认参数，只在发现明确的兼容问题时调整。

局域网、虚拟机与容器的处理

局域网地址通常应直连，并且排在宽泛代理规则之前。否则打印机、路由器管理页、文件共享或本地开发服务可能被送往代理出口。常见私有地址范围可以使用内核提供的 geoip:private 规则处理，但还要留意本地使用的特殊网段、虚拟机桥接网段和容器网络。企业网络可能使用额外的内部地址与域名，这些内容需要按实际情况添加。

虚拟机使用 NAT、桥接或仅主机网络时，流量入口和源地址不同。宿主机 TUN 不一定自动接管桥接虚拟机的全部流量，也不应假设容器流量会沿桌面应用相同路径。排查时先在宿主机测试，再在虚拟环境内部测试 DNS、默认路由和出口。若只在虚拟环境失败，应检查该环境自己的网络配置，而不是直接扩大宿主机路由规则。

MTU 不合适时，常见表现是小页面可打开，大文件、图片或 TLS 握手在特定阶段卡住。不要看到连接慢就立即降低 MTU。先确认问题是否只发生在 TUN、是否与特定网络有关，再逐步调整并保持每次变化幅度有限。修改后应测试网页、下载和 UDP 应用，而不是只看单一站点。

Windows 查看接口与路由
ipconfig /all
route print

macOS 查看接口与默认路由
ifconfig
route -n get default

Linux 查看地址与路由
ip address
ip route

这些命令用于观察系统状态，不负责直接修复配置。重点确认虚拟接口是否存在、默认路由是否符合预期、局域网路由是否仍然可达，以及关闭 TUN 后相关条目是否恢复。不要在不了解用途时手动删除整张路由表。若客户端停止后网络仍异常，先完全退出客户端并重新连接当前网络，再检查残留接口和 DNS。

避免流量循环与控制连接被接管

TUN 最关键的边界是绕过代理进程自身和服务器连接。若连接代理服务器的流量再次进入 TUN，并被路由回同一个代理出站，就会形成循环。成熟客户端通常会自动处理服务器地址、进程或接口绕过，但自定义规则可能破坏这层保护。出现启动后立刻断连、日志重复连接同一目标或流量快速累积时，应优先检查循环。

DNS 也可能形成类似循环：TUN 把 DNS 请求送入内核，内核访问 DoH 服务器时又依赖尚未完成的解析。处理方式是明确引导解析、DNS 出口和 TUN 排除范围。不要同时开启多个系统级 VPN 或透明接管工具来“增强兼容”，它们会竞争默认路由、DNS 与虚拟接口，最终现象往往不稳定。

Android 上的 VpnService 同样会建立系统级接管，但操作方式、权限模型和桌面 TUN 不完全相同。v2rayNG 或 v2flyNG 首次连接时需要完成系统授权，并根据需要配置分应用代理。后台频繁停止时，应检查省电策略，而不是修改桌面端的 TUN 参数。

为什么要给域名分配虚拟地址

某些应用会先自行解析域名，再只把目标 IP 交给系统网络。进入 TUN 后，内核看到的是 IP，原始域名已经丢失，基于域名的路由规则就难以命中。FakeDNS 的作用是为查询返回一段虚拟地址，同时保存“虚拟地址与原始域名”的映射。当应用连接这个虚拟地址时，流量被 TUN 收回，内核再恢复原始域名并执行域名路由。

因此，FakeDNS 不是普通公共 DNS 的替代品，也不是单独打开就能工作的加速选项。完整链路至少包括：应用查询进入内核 DNS、FakeDNS 返回虚拟地址、应用发起连接、连接进入受控入站、内核识别虚拟地址并还原域名、路由选择实际出站、出站侧完成真实解析或建立连接。任何一步绕开客户端，都会导致虚拟地址无法还原或域名规则失效。

启用前必须先让 TUN 和普通 DNS 分别稳定。随后选择不与局域网、虚拟机、容器及企业网络冲突的虚拟地址池。地址池只在本机映射中使用，不应被发送到真实网络。如果路由错误地把虚拟地址直连，应用会表现为持续超时。地址池容量还要覆盖活跃域名数量，但没有必要盲目扩大到与现有网络重叠的范围。

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

198.18.0.0/15 常用于基准测试网络，可作为虚拟地址池示例，但仍应检查当前网络是否已占用相关范围。配置字段会随内核配置方式而有差异，应以客户端生成的结构为基础，不要把片段直接替换进不兼容的配置。FakeDNS 与 DNS 服务器顺序也有关：并非所有域名都必须返回虚拟地址，本地域名、局域网主机和明确要求真实 IP 的应用可以保留普通解析。

识别虚拟地址泄漏和映射失效

如果应用得到虚拟地址后，连接没有进入 TUN，而是由系统直接发往物理网络，就会出现虚拟地址泄漏。现象通常是域名解析看似成功，但连接始终超时，内核日志里也找不到对应请求。此时不要继续更换上游 DNS，应检查应用是否被 TUN 接管、分应用规则是否排除了它、自动路由是否生效，以及虚拟地址段是否被其他路由抢先处理。

映射失效可能发生在内核重启、缓存保留或地址池被重复使用之后。应用仍缓存旧虚拟地址，但新内核已经没有原映射，就无法恢复域名。解决时应重新载入配置，并清理应用与系统 DNS 缓存，让应用重新查询。若问题只出现在长时间运行后，还要检查地址池容量、缓存生命周期和是否存在大量短期域名请求。

部分应用会校验返回地址、使用内置 DNS、直接连接固定 IP，或在应用内部建立加密解析链路。这些流量不一定适合 FakeDNS。遇到单个应用异常时，可先把该应用移出 FakeDNS 测试范围，使用真实解析并通过 IP 或进程规则处理。不要为了一个特殊应用而让全部域名都改走更复杂的链路。

FakeDNS 是否值得启用，取决于是否确实需要在 TUN 环境中保留域名。普通系统代理已经能够传递域名时，额外启用通常不会带来明显收益。配置完成后还应测试局域网主机、常用网页、长连接和休眠恢复，确保虚拟映射不会影响真实本地解析。稳定优先于功能数量。

从直连、阻断和本地代理开始

自定义出站用于描述流量离开内核的方式。最基础的配置通常包含代理出站、直连出站和阻断出站。订阅服务器生成的代理出站由客户端维护，本地规则只需要通过标签引用它。新增出站时，标签必须唯一、含义清楚，并避免与客户端自动生成标签冲突。推荐使用 direct、block、local-socks 这类职责名称，不要用“线路一”“临时二”等难以长期理解的标签。

直连出站把流量交给本机网络，仍受系统路由和 DNS 能力影响；阻断出站明确拒绝匹配流量；本地 SOCKS 出站可以把流量交给另一个运行在本机或可信局域网中的代理服务。自定义链式出口会增加故障点，只有在上游职责明确且能够单独验证时才应使用。若普通订阅服务器已经满足需求，不必额外添加多层转发。

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

示例中的本地端口只有在另一个 SOCKS 服务确实监听 127.0.0.1:1081 时才可用。添加后先检查端口监听，再写一条只匹配测试域名的路由规则，将其送到 local-socks。若直接把默认流量全部切换过去，一旦上游未启动，所有连接都会失败，也难以判断是规则还是上游问题。

理解出站链路中的 DNS 与循环

自定义出站访问的是域名时，仍然需要解析。要确认解析由本地系统、内核 DNS 还是上游代理完成。若希望上游代理解析域名，应保留域名形式并使用支持远程解析的连接方式；若内核先解析，则路由和 DNS 策略会影响得到的地址。把这一点写进配置说明，能避免出现“路由命中了正确标签，但连接到错误地址”的情况。

本地链式代理特别容易产生循环。例如 v2rayN 的出站指向本机 1081，而 1081 又由同一配置的入站占用，或者上游程序的流量再次被 TUN 捕获并送回当前出站。排查时查看端口所属进程、入站监听地址和 TUN 绕过范围。一个端口只能由一个进程稳定监听，入站与出站目标也不能形成闭环。

服务器出站的协议、传输、TLS 与 REALITY 参数应来自实际服务端配置或订阅内容。不能只凭协议名称拼接参数。VLESS、VMess、Trojan 等协议负责不同层面的认证与传输组织，WebSocket、gRPC、TCP 等传输还会携带路径、服务名或主机信息。REALITY 与 XTLS Vision 的关系可参考REALITY 与 XTLS Vision 原理科普，但配置值仍必须与服务器端逐项对应。

按“入口—解析—路由—出口”定位故障

系统化排错应始终沿流量方向进行。第一步检查入口：应用是否读取系统代理，或流量是否进入 TUN；第二步检查解析：日志中是否保留域名，DNS 是否返回可用结果；第三步检查路由：目标命中了哪条规则和哪个出站标签；第四步检查出口：上游地址、端口、协议和传输是否能建立连接。不要从最后一步开始反复更换服务器，因为入口未接管时，更换多少服务器都不会改变现象。

若内核无法启动，先恢复最近一次可用配置，检查 JSON 语法、标签引用、端口冲突与权限。若能够启动但没有连接记录，重点检查系统代理、TUN 与应用设置。若有连接记录但规则错误，暂时缩减为三段式路由。若规则正确但 DNS 失败，切回简单上游并关闭 FakeDNS。若解析和路由都正确而出站失败，再核对服务器配置、系统时间和本地网络。

完成排错后，应把临时日志级别、测试规则和测试出站恢复为日常配置。保留一套基线、一套当前使用方案和简短变更记录即可，不必长期堆积大量几乎相同的配置副本。需要重新选择客户端或安装对应平台版本时，可前往客户端下载页；桌面端优先使用 v2rayN，Android 可按内核需要选择 v2rayNG 或 v2flyNG。