订阅分组、路由、DNS 与 TUN 配置

一、订阅分组与服务器过滤

订阅分组解决“配置从哪里来”，服务器过滤解决“列表里显示什么”。两者应分开设置：分组管理来源，过滤器只改变可见范围，不应承担删除配置的职责。

建立稳定的分组边界

在 v2rayN 中导入多个订阅时，先为每个来源建立独立分组，不要把全部服务器长期堆在默认分组。分组名称应描述用途或来源，例如“日常”“办公测试”“手动配置”，而不是使用容易变化的地区名。地区、协议和线路标签更适合由过滤规则处理。这样调整订阅地址时，原有路由和筛选逻辑不会跟着名称一起失效。

新增订阅后，先执行一次单组更新，再观察该分组内是否出现配置。确认无误后才开启自动更新。若更新结果为空，不要立即删除旧分组；先检查订阅地址是否完整、当前分组是否启用了排除规则，以及更新请求是否需要沿用当前系统代理。更完整的检查顺序可参阅订阅更新失败自查清单。保留旧数据直到新数据验证完成，可以避免一次错误更新覆盖可用配置。

手动添加的 VMess、VLESS、Trojan 或 Shadowsocks 配置建议放入独立分组。订阅更新通常会以远端内容为准重建列表，如果把手动配置混在订阅分组里，后续更新时很难判断某条记录来自本地还是订阅。独立分组也便于导出、迁移和逐项核对传输参数。

包含、排除与正则过滤

过滤器通常包含“包含关键词”和“排除关键词”两类条件。包含条件用于缩小候选范围，排除条件用于剔除已知不需要的标签。建议先设置排除，再逐步增加包含条件。若同时设置，通常只有满足包含条件且不命中排除条件的记录才会显示。过滤只针对备注或订阅提供的标签，不会验证服务器的真实位置、协议能力或可用状态。

简单场景优先使用普通关键词。多个词需要表达“任意一个”时，可以使用正则表达式中的竖线，例如 家用|办公。需要匹配开头时使用 ^，匹配结尾时使用 $。正则里的括号、点号和加号具有特殊含义，直接匹配这些字符时要先转义。设置后应立即查看筛选结果数量和首尾记录，避免表达式范围过大。

包含：^(家用|办公).*(VLESS|Trojan)$
排除：测试|到期|维护
说明：只显示以“家用”或“办公”开头，且以指定协议标签结尾的记录

筛选后列表为空时，按三个层次排查。第一层是暂时清空全部过滤条件，确认原始列表是否存在；第二层是只保留一个普通关键词，确认备注字段是否确实包含该词；第三层才恢复正则，并逐段增加表达式。不要一开始同时修改订阅地址、分组和正则，否则无法确定是哪一步导致结果变化。

排序、选择与更新后的稳定性

服务器排序只是界面展示顺序，不等同于路由优先级。按备注、地址或协议排序后，当前选中的服务器仍由客户端状态决定。订阅更新可能改变列表顺序，也可能重建记录标识，因此不要依赖“第几行”作为长期选择条件。更稳定的做法是使用清晰备注、固定分组和可重复的筛选规则。

完成分组后，分别检查每组的更新方式、自动更新开关和过滤条件。经常使用的分组可以启用定时更新；临时测试分组适合手动更新，避免远端变更频繁打断对照测试。更新前后若服务器数量差异明显，应先查看客户端日志和过滤结果，再决定是否切换当前配置。

二、路由规则实战与匹配顺序

路由规则负责把连接送往不同出站。判断结果由目标信息、规则顺序和出站标签共同决定。配置时应先定义策略，再填写语法。

理解从上到下的命中过程

路由引擎通常从上到下检查规则，第一条满足条件的规则决定出站，后面的规则不再参与。精确规则应放在前面，范围宽的规则放在后面，最后保留明确的默认策略。例如，局域网地址直连应位于大范围代理规则之前；指定域名的直连或拦截规则也应放在分类集合之前。若把覆盖面很广的规则放在顶部，后续细分规则即使语法正确也不会生效。

常见匹配对象包括域名、IP、端口、网络类型和进程。域名规则可使用完整域名、后缀、关键词或 geosite 分类；IP 规则可使用单个地址、CIDR 网段或 geoip 分类。端口只描述目标端口，不能判断应用类型。进程匹配依赖系统和客户端是否能取得进程信息，跨平台迁移时不能把它当作唯一条件。

一套可解释的基础顺序

基础分流可以从三层开始。第一层处理私有地址，避免打印机、路由器和局域网服务进入远端出站；第二层处理明确的域名分类；第三层设置默认代理出站。不要一次加入大量来源不明的规则集。规则越多，优先级冲突越难定位，资源更新也更难管理。

{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "direct"
      },
      {
        "type": "field",
        "domain": ["geosite:geolocation-!cn"],
        "outboundTag": "proxy"
      }
    ]
  }
}

domainStrategy 决定域名规则未命中时是否继续解析 IP。使用 IPIfNonMatch 时，路由先尝试域名规则，未匹配后再通过 DNS 取得地址并检查 IP 规则。它适合同时使用 geosite 与 geoip 的配置。若选择只按域名判断，依赖目标 IP 的规则可能无法参与；若对所有域名提前解析，则会增加 DNS 查询并改变连接时序。

规则不生效时如何定位

先确认实际目标是域名还是已经解析好的 IP。浏览器通常提交域名，而部分应用会自行解析后直接连接 IP，此时域名规则看不到原始名称。其次确认规则命中的出站标签确实存在，标签拼写区分大小写时，proxy 与 Proxy 会被视为不同目标。再次检查规则顺序，尤其是顶部是否存在覆盖全部端口、全部网络或大范围域名的规则。

测试单条规则时，应暂时缩小条件。例如把分类规则替换成一个完整域名，将日志级别调到能够观察路由判定的位置，发起一次新的连接，再确认所选出站。已有连接可能复用旧链路，修改规则后应关闭对应应用连接或重启客户端核心。只刷新页面不一定会建立新连接。

UDP 与 TCP 可以使用不同规则，但需要明确应用行为。域名解析通常涉及 UDP，也可能回退到 TCP；实时通信可能同时使用多个目标端口。若只允许 TCP 进入某个出站，相关 UDP 请求可能走默认规则，从而形成“页面能打开但部分功能异常”的现象。排查时同时观察网络类型、目标端口和最终出站，不要只看域名。

三、DNS 配置优化与查询路径

DNS 配置不只是填写服务器地址。需要同时回答三个问题：谁发起查询、查询经过哪个出站、返回结果如何参与路由。

区分系统解析与内核解析

系统代理模式下，部分应用会自行调用系统 DNS，再把解析后的 IP 交给代理；另一些应用会把域名直接交给代理客户端。两类请求进入内核时携带的信息不同。前者可能只剩 IP，路由只能依靠 geoip 或网段规则；后者保留域名，可以先使用 geosite、后缀和完整域名规则。遇到同一网站在不同应用中走向不同出站时，应先检查解析发生在应用侧还是内核侧。

TUN 模式能够接管更多系统流量，也更容易统一 DNS 路径，但仍要避免系统 DNS、TUN DNS 和浏览器自带解析策略同时竞争。配置目标不是让所有查询都走同一服务器，而是让查询结果和路由策略一致。例如计划按域名分类分流，就应尽量保留域名信息；计划按目标 IP 分流，则要保证用于判断的解析结果稳定可用。

服务器类型与匹配条件

DNS 服务器可以按域名条件分组。面向直连域名的查询可使用本地网络可达的解析服务，其他查询可沿代理出站发送。配置时要明确服务器地址本身如何解析和连接。如果加密 DNS 的主机名还需要另一次 DNS 查询，必须为它准备可达的引导解析地址，否则会形成循环依赖。

queryStrategy 用于控制返回 IPv4、IPv6 或两者。选择时应以当前网络和目标服务实际可达性为准。只返回 IPv4 能减少双栈环境中的不确定分支，但会排除仅提供 IPv6 的目标；同时返回两者则要求系统路由和出站链路都能正确处理双栈。不要仅因为日志中出现某类地址就强制关闭另一类，应先测试本地网络是否具备稳定连接。

{
  "dns": {
    "queryStrategy": "UseIP",
    "servers": [
      {
        "address": "223.5.5.5",
        "domains": [
          "geosite:cn"
        ],
        "expectIPs": [
          "geoip:cn"
        ]
      },
      {
        "address": "1.1.1.1",
        "domains": [
          "geosite:geolocation-!cn"
        ],
        "skipFallback": true
      },
      "localhost"
    ]
  }
}

expectIPs 用于验证响应地址是否符合预期分类。它不是把结果强制改成某个地区，而是在响应不符合条件时让解析流程尝试其他候选服务器。skipFallback 表示该服务器不参与普通回退流程，适合只服务于明确域名集合的解析器。具体字段支持情况取决于当前使用的内核配置格式，导入自定义片段前应先查看 v2rayN 生成后的完整配置和启动日志。

缓存、回退和污染式错误的辨别

修改 DNS 后若结果未立即变化，可能是浏览器、系统、客户端内核或上游解析器仍保存缓存。排查时先关闭测试应用的现有连接，再重启核心；必要时清理系统 DNS 缓存。不要连续刷新同一页面后仅凭一次结果判断，因为连接池和缓存会绕过新配置。

解析异常通常分为超时、返回空记录、返回不可达地址和返回类型不匹配。超时应检查 DNS 请求使用的出站和防火墙；空记录要确认域名本身及查询类型；不可达地址要检查路由表与目标网络；类型不匹配则检查 queryStrategy。若日志显示解析成功但连接失败，问题通常已经从 DNS 层转移到路由、出站或传输层。

评估 DNS 配置时，至少选三类目标：明确直连的域名、明确经代理的域名、只提供特定地址族的测试目标。分别记录解析结果、命中规则和最终出站。只测试一个常用网站，无法证明回退顺序和边界条件正确。

四、TUN 模式的接管范围与系统路由

系统代理只影响主动读取代理设置的应用，TUN 模式通过虚拟网络接口接管更广的流量。两者不是简单的强弱关系，而是不同的接入方式。

什么时候需要启用 TUN

浏览器、下载工具和多数桌面应用能够读取系统代理时，优先使用系统代理，路径更短，也便于单独退出。游戏启动器、命令行程序、部分商店组件或固定直连的应用不读取系统代理时，才需要考虑 TUN。启用前先确认普通系统代理配置已经可用，否则在基础链路尚未验证的情况下增加虚拟网卡和路由表，只会扩大排查范围。

TUN 启动后，客户端会创建虚拟接口，并按设置写入系统路由。流量先到虚拟接口，再由内核判断路由和出站。DNS 也可能被重定向到内核处理。关闭客户端时应恢复原路由；若进程异常退出，可能留下临时接口或路由状态，表现为客户端已关闭但网络仍异常。此时先重新启动客户端并正常关闭 TUN，再检查系统网络设置。

常见参数的含义

stack 表示 TUN 使用的网络栈实现。不同实现对 TCP、UDP、双栈和系统兼容性的侧重点不同。正常情况下保留客户端推荐值，只有出现特定应用无法建立连接、UDP 异常或高负载时再逐项切换测试。切换网络栈后需要完全重启核心，已有连接不会自动迁移。

autoRoute 用于自动添加路由，让目标流量进入虚拟接口。关闭后需要自行维护系统路由，适合已经有明确网络拓扑的环境，不适合初次配置。strictRoute 用于更严格地限制绕过路径，可减少部分流量脱离 TUN，但也可能影响局域网发现、虚拟机或其他网络工具。mtu 控制单个数据包的最大传输单元，设置过大会在部分链路上发生分片或丢包，设置过小则增加额外开销。

局域网、虚拟机与其他网络工具

启用 TUN 后若无法访问路由器管理页、网络存储或打印机，先确认 geoip:private 是否直连，并检查严格路由是否拦截本地网段。局域网可能使用不常见的私有网段，不能只依赖分类数据；必要时为实际网段添加 CIDR 直连规则，例如 192.168.50.0/24。规则必须位于默认代理规则之前。

虚拟机、容器和企业网络客户端也会写入路由表。多个工具同时启用时，系统可能根据前缀长度和跃点值选择不同接口。不要通过反复开关所有工具碰运气。先记录 TUN 启动前后的路由表差异，再关闭其他会修改网络栈的软件，确认单独运行时是否正常。若单独正常，再逐个恢复其他组件。

睡眠唤醒、网络从有线切换到无线、从家庭网络切换到办公网络后，原有接口索引可能变化。出现连接停滞时，先关闭 TUN，等待虚拟接口退出，再重新启用。若客户端持续提示创建接口失败，需要检查运行权限、系统网络组件状态以及是否存在同名残留接口。

五、FakeDNS 的工作方式与适用边界

FakeDNS 为域名临时分配保留地址，使只携带目标 IP 的连接仍能恢复原始域名。它主要解决域名信息在应用解析阶段丢失的问题。

从查询到连接的映射过程

启用 FakeDNS 后，受接管的 DNS 查询不会立即把真实目标地址交给应用，而是返回一个专用地址池中的临时地址。应用随后连接该地址，内核根据映射表找回原始域名，再执行域名路由和真实解析。这个过程让 TUN 场景中的域名规则更稳定，因为应用即使先解析再连接，内核仍能知道连接最初对应哪个名称。

临时地址只在当前映射有效期内具有意义，不能把它当作目标服务器的真实地址保存、共享或写入长期规则。如果应用把解析结果缓存很久，而内核映射已经过期，连接可能失败。重新启动应用或清理其 DNS 缓存通常能建立新映射。客户端核心重启后，旧临时地址也可能不再对应原域名。

地址池和例外域名

FakeDNS 地址池不能与当前局域网、虚拟机网络、容器网络或其他隧道地址段重叠。重叠时，系统可能把临时地址发送到错误接口，日志中甚至看不到连接进入内核。选择地址池前应查看本机路由表和常用网络环境，而不是只检查当前无线网络。

并非所有域名都适合进入 FakeDNS。局域网设备名称、企业内部域名、需要由特定系统解析器处理的名称，以及依赖真实 IP 做本地判断的应用，可以加入例外。例外列表应保持精确，优先写完整域名或明确后缀。把范围过大的分类全部排除，会削弱 FakeDNS 恢复域名的作用。

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

198.18.0.0/15 常被用于基准测试网络，不应直接理解为任何真实目标位置。配置前仍需确认它没有被当前虚拟网络占用。poolSize 决定可维护的映射数量，日常桌面使用通常不需要盲目扩大。过大的池不会提升单次解析速度，反而会让冲突范围更难检查。

与真实 DNS、嗅探和路由的关系

FakeDNS 不替代真实 DNS。它先向应用返回临时地址，内核在准备连接时仍需取得目标的真实地址。真实解析所用服务器、查询策略和出站路径仍由 DNS 配置决定。若真实解析超时，应用看到的现象可能是连接临时地址失败，因此排查时要同时查看 FakeDNS 映射和后续解析日志。

协议嗅探也能从部分流量中恢复域名，例如从 TLS 握手或 HTTP 请求中读取主机信息，但它依赖流量中存在可识别字段。FakeDNS 在连接建立前通过映射恢复域名，两者工作阶段不同。启用其中一个并不保证另一项必须开启。配置应以日志中实际缺失的信息为依据，而不是把所有相关开关同时打开。

判断 FakeDNS 是否适用，可以先选一条明确的域名规则，在未启用时观察 TUN 连接是否只能命中 IP 规则；再启用 FakeDNS，清理应用缓存并建立新连接，查看日志是否恢复域名以及是否命中预期出站。若域名已经能稳定传入内核，额外启用 FakeDNS 的收益有限。

六、多订阅管理与更新治理

多订阅管理的重点不是导入更多地址，而是让更新、筛选、切换和回退都可追踪。每个订阅都应有独立边界和明确用途。

命名、更新与责任分离

订阅名称建议包含用途和来源类别，例如“日常主用”“临时测试”“手动归档”。不要把更新时间写进名称，时间会快速失效，也会让自动化筛选变得困难。若同一来源提供不同协议或用途的订阅，仍应分开导入，使每组可以独立更新和停用。

自动更新不宜对全部分组使用完全相同的短周期。主用分组按稳定周期更新，测试分组手动触发，暂时不用的分组可以关闭自动更新但保留地址。更新时客户端需要访问订阅地址；若该请求依赖当前代理，应确认“更新订阅时使用代理”或对应选项与当前网络一致。当前服务器失效时，依赖它更新订阅可能形成循环，因此应保留能够直接访问更新地址的路径或可手动恢复的旧配置。

执行批量更新前，先单独更新一个分组并观察结果。需要检查的不只是是否提示成功，还包括记录数量是否异常、备注是否改变、协议字段是否完整、过滤器是否仍能匹配。远端订阅格式变化时，客户端可能完成下载但解析结果为空，成功获取与成功生成服务器列表不是同一件事。

去重与冲突处理

不同订阅可能包含地址、端口和协议相同但备注不同的记录，也可能备注相同而传输参数不同。只按备注去重容易误删有效配置，只按地址去重又会忽略端口、用户标识、传输层和安全参数。长期管理时，应把协议、地址、端口、身份字段、传输方式和安全设置视为一组配置指纹，通过客户端实际展示的字段逐项比较。

发现重复记录后，不必立即删除来源。先确定哪个分组负责长期更新，另一个分组是否只是临时备份。删除单条记录可能在下次订阅更新后重新出现，真正的治理位置通常是分组过滤或订阅来源。对备注冲突，可以在客户端允许的范围内使用分组前缀区分，而不是修改远端生成的核心参数。

安全回退与迁移

更换订阅来源或调整大范围过滤前，先导出当前客户端配置和路由设置。导出文件应存放在受控位置，其中可能包含订阅地址和服务器认证信息，不适合公开分享。恢复时先导入到新分组，不要直接覆盖正在使用的分组。验证连接、路由和 DNS 后，再停用旧来源。

跨设备迁移时，需要区分“服务器配置”和“客户端偏好”。服务器链接通常不包含系统代理模式、TUN 参数、路由规则、DNS、自启动和界面筛选等设置。只导入订阅并不能完整复制工作环境。建议使用一份迁移清单，分别记录订阅分组、当前服务器、路由规则、DNS、TUN、自动更新周期和自定义出站。

v2rayN 适合 Windows、macOS 与 Linux 桌面环境；Android 可使用 v2rayNG，或按内核需求选择 v2flyNG。不同客户端的菜单结构和可导入字段并不完全相同。迁移路由时应转换为目标客户端支持的规则表达，而不是假设整份桌面配置可以原样使用。客户端入口与平台说明可在下载页面中查看。

七、自定义出站与链式选择

出站定义连接最终如何离开内核。常见标签包括代理、直连和阻断。自定义出站的关键是标签唯一、引用一致，并避免形成循环。

出站标签与路由引用

每个出站通过 tag 被路由规则引用。标签应使用简短、稳定的英文名称，例如 proxy、direct、block 或 dns-out。修改标签后，所有路由规则、DNS 出站引用、链式代理设置和统计策略都要同步调整。启动日志中的“找不到出站”通常来自拼写不一致或配置合并时标签被覆盖。

直连出站用于由本机网络直接建立连接，阻断出站用于明确拒绝匹配流量。阻断规则应保持精确，先从完整域名或特定端口开始测试。范围过宽会让普通连接表现为无响应，而不是显示清晰错误。代理出站通常由当前服务器配置生成，手工编辑时不要遗漏传输、安全和身份字段。

{
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct",
      "settings": {
        "domainStrategy": "UseIP"
      }
    },
    {
      "protocol": "blackhole",
      "tag": "block",
      "settings": {
        "response": {
          "type": "none"
        }
      }
    }
  ]
}

freedom 出站的 domainStrategy 决定直连阶段如何处理域名。若路由阶段已经完成解析，出站可能直接使用得到的地址；若仍保留域名，出站会按策略解析。该设置要与全局 DNS 和路由策略协调，避免同一域名在不同阶段得到不一致结果。

自定义出站的实际用途

独立直连出站可以绑定特定接口或地址，用于多网卡环境；独立阻断出站可以处理明确不需要的目标；DNS 专用出站可以让解析请求走指定链路。每增加一个出站，都应写下它的入口规则、依赖条件和回退方式。只有出站而没有任何路由引用时，它不会自动参与连接。

多网卡绑定时，要确认所选源地址确实属于当前活动接口。网络切换后，旧地址可能失效，表现为只有绑定出站无法连接。需要长期在不同网络之间移动的设备，不宜固定易变化的源地址。更稳妥的方式是使用系统路由决定出口，只在确有接口隔离需求时绑定。

链式出站与循环风险

链式代理表示一个出站的连接再通过另一个出站建立。它适合有明确上游关系的场景，但会增加握手、解析和故障点。配置前先分别验证每一段能够独立工作，再组合链路。若基础出站本身不稳定，链式配置只会让错误更难判断。

链式关系不能形成闭环。例如 A 通过 B 建立，而 B 的连接又被路由回 A，就会不断递归直至失败。避免循环需要为上游服务器地址设置更精确的直连或指定出站规则，并放在普通代理规则之前。若上游地址使用域名，还要考虑该域名解析请求走哪个出站。

测试链式出站时，先检查日志中的连接顺序，再确认目标请求与上游连接分别命中哪条规则。不要只根据最终页面是否打开判断配置正确，因为系统可能绕过预期链路走了默认出站。关闭默认回退做短时测试能帮助发现遗漏，但测试结束后应恢复可控的兜底策略。

自定义完整配置前，建议保留 v2rayN 自动生成的配置作为对照。先导出生成结果，找到 outbounds、routing 和 dns 三个区块，再以最小改动加入新标签。保存后查看核心启动日志，确认配置解析成功。若启动失败，先撤回最近加入的一个区块，不要同时重写全部结构。

八、配置验证、日志读取与回退流程

进阶配置完成后，需要用分层测试证明每个环节有效。测试顺序应从配置加载开始，再到解析、路由、出站和系统接管。

先确认核心接受配置

保存设置并不代表核心已经使用新配置。第一步查看启动日志，确认配置文件能够解析、端口没有冲突、引用的出站标签存在、资源文件能够读取。语法错误通常会给出字段位置或附近结构。遇到错误时，从最近一次改动开始撤回，特别检查 JSON 逗号、数组与对象层级、标签拼写和不受支持的字段。

核心成功启动后，确认本地监听端口和系统代理指向一致。若客户端状态显示运行，但应用无法连接，可能是系统代理仍引用旧端口，或另一个程序占用了监听地址。TUN 模式还要确认虚拟接口已经创建、路由表已写入，并且 DNS 接管没有失败。

按层测试，不用单一结果代替全部结论

第一层测试订阅和服务器配置：选择一条已知可连接的记录，暂时使用最小路由。第二层测试 DNS：分别查询直连域名与代理域名，记录返回类型和使用的解析器。第三层测试路由：为一个完整域名加入临时规则，从日志确认命中。第四层测试系统接管：先用系统代理，再启用 TUN。每层通过后再增加下一层设置。

延迟测试只能说明特定探测方式在当时是否收到响应，不能替代真实连接。某些服务器允许实际协议连接但不响应简单探测，也可能探测正常而目标连接失败。判断配置应结合核心日志、连接建立结果和应用行为，而不是只看列表中的单一状态。

修改规则后要建立新连接。浏览器连接池、DNS 缓存和应用后台进程可能继续复用旧链路。可靠的测试方式是关闭测试应用、等待连接释放，再重新打开；必要时重启核心。若问题只在睡眠唤醒或网络切换后出现，应把网络状态变化纳入复现步骤。

建立最小可用配置

最小配置包含一条可用服务器、一个代理出站、一个直连出站、私有地址直连规则和明确的默认策略。DNS 使用简单且可达的服务器，暂不启用 FakeDNS、链式出站和复杂进程规则。若最小配置正常，再按“订阅过滤、域名路由、条件 DNS、TUN、FakeDNS、自定义出站”的顺序逐项恢复。

每恢复一项，都记录修改内容、测试目标和结果。配置笔记不需要保存认证字段，只需记录开关、标签和规则顺序。这样在后续更新内核或迁移设备时，可以判断问题来自版本行为变化、系统网络变化还是本地规则调整。

验证清单
1. 核心启动日志没有配置解析错误
2. 当前服务器与本地监听端口正确
3. DNS 查询返回预期地址类型
4. 测试域名命中预期路由规则
5. 目标连接进入正确出站
6. 系统代理关闭后网络恢复
7. TUN 关闭后虚拟接口与临时路由退出

常见现象的定位方向

全部应用都无法连接，先看核心、监听端口和服务器配置。只有某个应用异常，检查它是否读取系统代理、是否自行解析 DNS、是否使用 UDP。只有局域网异常，检查私有网段直连和严格路由。域名规则不命中，检查应用是否只提交 IP，以及 FakeDNS 或嗅探是否能恢复域名。订阅更新成功但列表为空，检查解析结果和分组过滤。

若日志信息不足，可以短时提高日志级别完成复现，记录一次完整连接后恢复常规级别。长期保持过细日志会增加文件体积，也会让关键错误被大量正常记录淹没。分享日志前应移除订阅地址、用户标识、服务器认证参数和本地文件路径。

仍无法定位时，先查阅FAQ 故障排查，再对照v2rayN 主界面功能速览确认设置位置。协议字段之间的差异可参考VMess、VLESS、Trojan 与 Shadowsocks 对照。提交问题描述时，应包含操作系统、客户端名称、接管模式、复现步骤和经过处理的错误日志，不要只写“无法使用”。