V2Ray 进阶配置手册

订阅分组与服务器过滤

订阅分组解决的是服务器来源和更新范围，服务器过滤解决的是列表里显示哪些条目，二者都不等于流量分流。一个分组可以包含多台服务器，但日常连接仍由当前活动服务器承担；切换分组标签也不一定切换活动服务器。理解这层区别，可以避免“看见另一组列表，就以为连接已经更换”的判断错误。

建立可追溯的分组

在 v2rayN 的“订阅分组”入口新增分组，先填写能辨认来源的备注，再粘贴完整订阅地址。地址通常带有访问凭据，备注只写来源或用途，不复制地址中的参数。检查前后空格和换行，保存后只更新这个分组。首次更新先看日志是否完成，再确认列表有条目，不要同时启用自动更新、过滤和批量删除。

分组名称适合采用“来源加用途”的方式，例如办公订阅、移动网络备用。服务器别名是订阅返回的数据，后续更新可能改写，不能把手动改名当作长期分类依据。需要保留个人说明时，优先使用客户端支持的独立备注或另行记录。手动导入的服务器最好单独归类，避免与订阅条目混在一起后误判更新结果。

更新时要区分直连获取与通过代理获取。已有连接正常、直连更新失败时，可以尝试菜单中通过代理更新订阅的选项；首次配置尚无可用连接，则不能把代理更新当作必然可行的补救。先查看错误是解析失败、连接超时还是服务器拒绝请求。反复更新不会修复过期地址，反而可能触发来源端的请求限制。

先确认列表，再增加筛选

主窗口的搜索或过滤通常只是缩小当前显示范围；分组编辑中的服务器过滤则可能影响更新时保留哪些条目。实际行为以所在设置项的说明为准。开始筛选前，先选“全部”，清空搜索条件，确认目标条目确实存在。再进入目标分组使用一个简单关键词验证，避免多个条件叠加后无法判断是哪一项排除了服务器。

若输入框明确支持正则表达式，竖线表示候选关系，括号用于分组，句点默认匹配任意字符。下面的表达式适合匹配别名中包含这两个用途词的条目，只是筛选语法示例。若输入框只接受普通关键词，就应逐项搜索，不要把正则符号直接放进去。大小写是否敏感也应通过一个已知条目验证。

(办公|备用)

订阅更新后列表变空，先清除显示过滤，再检查分组过滤，最后检查来源返回的内容。显示为空不等于远端订阅为空。服务器列表中的类型、地址、端口和传输设置需要一起保留，不能只凭别名判断重复；名称相同的两个条目，可能使用不同传输方式。清理前记录当前活动服务器，避免删掉唯一可用的测试对象。

更新后的验证与恢复

服务器过滤只按描述信息缩小范围，不会验证可连接性，也不代表自动选择最快线路。更新完成后，在保留的条目中运行“测试服务器真连接延迟”或对应测速菜单，再手动设为活动服务器。测试结果受当前网络、测试目标和服务端状态共同影响，应以同一网络下的重复结果及实际业务访问为依据。

若更新替换了原来的条目，客户端可能无法继续维持旧的活动选择。此时重新选择服务器、重载配置，再查看日志中是否成功启动内核。不要在旧测试结果上直接比较新条目；别名相同不代表连接参数未变。测试失败时先回到一个已知可用的分组，确认基础连接，再处理更新后的列表，而不是同时修改路由和解析设置。

安卓端 v2rayNG 与 v2flyNG 的订阅入口、分组显示和筛选能力并不完全相同，不应照搬桌面端的正则操作。可先按来源管理订阅，再通过列表选择配置。导出配置或分享截图前，删除订阅地址、服务器凭据和可识别账号的备注；订阅链接应按账号凭据管理，不宜放入公开笔记或问题截图。

路由规则实战

路由规则决定进入内核的连接使用哪个出站，不负责把所有应用流量自动送入内核。系统代理只影响遵循代理设置的应用，TUN 则从网络层接入更多连接。因此，浏览器能按规则分流而另一个程序没有变化时，先确认后者是否进入代理链路，再检查规则。否则会把接入范围的问题误认为域名匹配错误。

从预设建立基线

在 v2rayN 的路由设置中，先记录当前预设，再选择“绕过大陆(Whitelist)”“黑名单(Blacklist)”或“全局(Global)”作为起点。预设名称只是入口，最终行为由实际规则、默认出站与规则库决定。全局也不必然覆盖本地地址等所有例外；需要精确判断时，应查看生成的路由内容，而不是只根据模式名称推断。

规则通常按顺序匹配，命中后使用指定出站。把局域网和必要的明确例外放在前面，再放范围较大的集合规则，最后检查未命中流量的去向。同一条规则内同时填写域名、端口和网络类型，通常意味着这些条件需要同时成立，而不是任选一个即可。只想按域名分流时，不要顺手填入无关端口限制。

下面是 Xray 风格的路由片段，假定完整配置已经存在名为 direct 与 proxy 的出站。第一条让私有地址直连，第二条让指定域名及其子域名走代理。示例域名用于说明语法，实际应替换为明确的业务域名。此片段没有定义默认出站，也没有提供连接凭据，不能单独启动。

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

域名、地址与规则库

full: 用于完整域名匹配，domain: 用于指定域名及其子域名，geosite: 引用域名集合，geoip: 引用地址集合。直接填写普通字符串可能采用关键词匹配，范围往往比预期更大。精确业务例外优先写完整域名，确实需要覆盖子域名时再使用域名后缀方式，减少误命中其他站点的可能。

域名规则需要内核知道目标域名。应用通过代理提交域名时通常可以直接匹配；应用先解析再只提交地址时，则可能需要嗅探或其他域名映射机制。嗅探也不是所有协议都能恢复域名。遇到相同站点在不同应用里命中不同规则，先对照日志中的目标形式：一个可能是域名，另一个只是地址，不要先扩大规则集合。

AsIs 不主动为了路由匹配解析目标域名；其他域名策略可能在未命中时或需要地址规则时触发解析，具体行为按内核文档核对。解析得到的地址还可能受缓存和网络位置影响，所以单纯改成地址匹配并不一定更稳定。域名明确的业务尽量用域名规则，只有确需按目标网络范围处理时才增加地址条件。

规则库文件与规则语法必须配套。客户端提供的更新入口可用于更新所需资源，但更新后仍应查看日志是否成功加载。集合名称不存在、资源文件不可读或选错内核，都可能让配置启动失败。不要把其他内核的规则文件直接改名使用。关于集合更新与常用写法，可继续查阅GeoIP 与 GeoSite 规则库说明。

用可观察结果验证

修改后先重载，再用一个目标站点验证，检查访问日志中的目标、命中规则或出站标签。浏览器已经建立的长连接可能继续沿用旧路径，关闭相关标签页或重启应用后再测。一次验证只更改一条规则；如果同时更新规则库、切换服务器和更改 DNS，即便结果恢复，也无法确定哪个改动真正起作用。

本地打印机、文件共享和内网管理页面访问异常时，先检查私有地址是否在宽泛代理规则之前直连，再检查应用是否被另一层代理接管。域名使用内部解析的环境，还需确认 DNS 能返回内网地址。路由正确而解析错误时，连接仍会去往错误目标；这也是路由与下一章 DNS 必须一起核对、但应分轮修改的原因。

DNS 配置优化

DNS 配置先回答三个问题：谁发起查询，查询走哪条路径，返回结果由谁缓存。系统解析器、浏览器的安全 DNS 和代理内核的内置解析器可能同时存在。只修改客户端里的 DNS 地址，并不代表所有应用都改用该地址。排查时先画清请求路径，再处理超时、结果不一致或内网域名失效，避免盲目堆叠解析服务器。

识别解析发生的位置

通过代理提交域名的应用，可以把解析留给代理链路；先在本地解析、再连接地址的应用，则已经在进入内核前完成一次查询。TUN 模式还可能通过 DNS 接管把系统查询引入内核。浏览器自行启用的加密解析通常又是一条独立路径。遇到浏览器与命令行结果不同，应分别确认各自解析设置，而不是认定其中一方使用了错误服务器。

先保留客户端默认 DNS 方案，以可连接服务器建立基线，再按需求增加一个变化。例如内网名称只能由组织内部解析器识别，就需要保留该解析路径；普通公网查询则可采用可达的解析服务。不同网络对公共解析服务的访问条件不同，没有一个地址适用于全部环境。优化目标是结果正确、路径稳定，而不是解析项越多越好。

以下为 Xray 内置 DNS 的最小字段示例，仅展示服务器列表和结果类型，不含 DNS 接管规则，也不承诺系统查询会进入该解析器。使用数值地址可以避开解析服务器自身域名的引导问题，但查询链路是否直连、是否经代理，仍要结合路由和内核行为确认。应在当前网络验证可达性后再采用。

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

分域名解析与引导解析

内网域名、公网业务域名和代理服务器地址，可能需要不同解析策略。内网域名送给公网解析器通常得不到预期结果；代理服务器地址若必须依靠尚未建立的代理才能解析，又会形成启动依赖。先确保服务器地址的引导解析独立可用，再处理普通流量的解析分流。切换网络后尤其要重新验证这一启动路径。

使用带域名的加密解析服务时，需要先知道该服务域名对应的地址，这一步就是引导解析。若引导解析也指向同一个尚未可用的服务，就可能循环等待。部分客户端提供专门的引导项，部分依靠内核或系统处理，不能套用同一字段。保存设置后从日志区分“无法解析解析器域名”和“目标业务域名查询失败”，两者修复位置不同。

解析规则与流量路由要保持一致。计划直连的业务若使用与当前出口相距很远的解析位置，可能拿到不合适的内容分发地址；计划经代理访问的业务，也可能因解析位置不同而出现服务区域判断差异。这里没有必然的快慢关系，应比较同一业务的连接建立、页面资源加载和持续访问，而不只看一次查询的耗时。

IPv6 需要按实际链路决定。系统存在 IPv6 地址，不代表到目标服务器的 IPv6 路径一定可用；同样，禁用全部 IPv6 也不是通用优化。如果日志显示持续尝试不可达的地址族，再针对解析结果策略或出站策略调整。先确认系统路由与网络支持情况，避免只隐藏解析结果，却留下应用自行解析后仍选择另一地址族的问题。

缓存与故障定位

DNS 结果可能缓存在系统、浏览器和内核中。更改设置后，重启相关应用与内核，再用相同目标复测，必要时使用系统提供的缓存清理方式。命令查询只代表该命令采用的解析路径，不一定代表浏览器，也不一定代表经代理的请求。对照日志时应记录目标域名与测试时间，不要把不同层缓存的结果混在一起比较。

“域名访问失败、地址访问成功”只能提示解析值得检查，不能据此直接断定 DNS 故障。使用地址访问 HTTPS 可能改变证书名称、请求主机和服务端路由，很多站点本就不接受这种测试。更可靠的顺序是确认查询是否成功、返回结果是否合理、目标端口是否可达，最后再检查应用协议层错误，保留完整错误类别。

路由策略改为需要地址匹配后，原本不明显的 DNS 问题可能立即出现，因为连接开始依赖本地解析。此时先恢复原来的域名策略，验证基础连接，再单独修复 DNS。不要同时开启 FakeDNS 来掩盖现象；FakeDNS 依赖额外的映射与接管条件，适用边界见后文。更多启动与连接异常可按FAQ中的分类继续排查。

TUN 模式配置

TUN 模式通过虚拟网络接口与路由，把更多应用连接交给代理处理，适合不读取系统代理的程序。它改变的是流量接入范围，不是自动提高连接质量，也不等于所有流量必须走同一个出口。接入后的直连、代理与阻断仍由路由决定。启用前先保证普通代理方式可以连接，避免把服务器故障和网络接管故障放在一起处理。

权限、内核与接管范围

在 v2rayN 主窗口启用“启用 Tun 模式”前，检查当前客户端是否已经具备所需权限。Windows 可能需要提升权限或通过客户端支持的服务方式运行；其他桌面系统也可能需要授权创建网络接口与修改路由。按照当前安装方式给出权限，不要把反复以高权限启动当作长期排错方法。日志应能说明接口和路由是否建立成功。

桌面客户端可能为 TUN 调用不同的运行组件，实际字段与普通代理内核不一定相同。应查看启用后的运行日志和生成配置，确认哪个组件承担接入与出站。不要把 Xray 的 JSON 片段直接粘贴到另一套 TUN 配置格式中。若界面能够正常切换，但日志报告未知字段，优先恢复默认模板，再核对配置与运行组件是否配套。

安卓客户端通常借助系统 VPN 服务接入应用流量，首次连接需要确认系统授权。分应用设置决定哪些应用被纳入或排除，列表采用“代理所选应用”还是“绕过所选应用”必须看清。它不是桌面“启用 Tun 模式”开关的逐项翻译。与另一项占用系统 VPN 服务的工具同时运行时，还可能发生互斥或连接被替换。

先处理回环，再验证分流

TUN 建立后，代理进程连接服务器的流量必须能够绕过自身接管，否则会形成回环。客户端通常会自动处理相关路由或进程排除，但自定义模板、额外网卡和另一套隧道可能破坏这个前提。表现常见为开启后服务器也无法连接、日志重复尝试或全部请求超时。先关闭 TUN 恢复基础连接，再检查出口路由，不要继续扩大代理范围。

局域网访问需要同时检查路由和解析。能访问公网但打不开打印机或内部服务时，确认私有地址是否直连、内部域名是否使用正确解析器，以及局域网路由是否被更宽的接管规则覆盖。不要把整段本地网络送入远端代理来试错。确需访问远端私有网络时，应区分本地同名地址段，避免地址范围重叠造成目标歧义。

第一次验证可分三步：先访问一个已知正常的网页，再测试原本不遵循系统代理的应用，最后验证局域网与内部域名。与此同时查看流量是否实际进入客户端，而不是只看任务栏图标变化。若同时启用了系统代理，浏览器成功可能仍来自旧路径；可以在记录原状态后暂时关闭系统代理，单独验证 TUN 接入是否有效。

UDP、路径 MTU 与退出恢复

应用进入 TUN 不等于全部协议都能经过当前服务器。语音、游戏和部分传输会使用 UDP，还需要客户端、内核、服务器与网络链路共同支持。网页正常而实时通信失败时，检查 UDP 支持及日志，不能只用网页测试结果推断。部分应用还会选择不同传输协议，测试时应保持设置一致，避免把协议切换造成的差异归因于路由。

少数站点能建立连接却卡在大资源传输，可能涉及路径 MTU，也可能是丢包、协议或服务端问题。不要直接套用固定 MTU 数值。先换已知可用服务器，比较关闭 TUN 后的表现，再根据日志和网络诊断缩小范围。只有证据指向分片或路径问题时才调整相关参数，并记录原值；否则修改只会增加一个难以追踪的变量。

退出时先关闭 TUN，再退出客户端，检查普通网络和系统 DNS 是否恢复。如果异常发生在休眠唤醒或网络切换后，重新建立接管通常比立刻改配置更合理。仍无法恢复时，检查是否存在遗留接口、路由或另一项网络接管服务。不要在不了解用途时批量删除系统路由，组织网络中的路由可能由管理策略维护。

安卓后台断连还应检查电池优化、后台运行限制与分应用代理，而不是照搬桌面网络修复命令。保持连接与节电之间需要按实际使用选择，具体取舍见v2rayNG 后台与耗电排查。完成测试后保留一个稳定模式，避免让多个接管工具随开机同时启动。

FakeDNS 映射机制

FakeDNS 用合成地址暂时代表域名，并在后续连接进入内核时恢复域名，用于保留分流所需的域名信息。它不是远端服务器真实地址，也不是额外的加密协议。适合的场景是应用先查询 DNS、再只用地址连接，而代理需要按域名匹配规则。若普通解析和路由已经符合需求，不必为了增加设置项而开启。

查询与连接必须形成闭环

完整路径是：应用查询域名，查询被交给 FakeDNS，应用收到合成地址，随后连接该地址，连接再被交回掌握映射的内核。缺少其中任何一段，都可能出现“有解析结果但无法连接”。尤其要确认应用的 DNS 没有绕开接管，并且合成地址所在范围不会被直连规则提前放行。只配置地址池而没有查询入口，不会自动生效。

下面是 Xray 风格的字段片段，展示合成地址池、DNS 服务器选择以及入站嗅探之间的关联。其中 198.18.0.0/15 来自保留的基准测试地址空间，不是公网服务器地址。示例只描述 IPv4 映射，且没有展示完整入站、出站与 DNS 转发规则。实际合并位置应由当前客户端生成结构决定。

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

需要恢复映射的相应入站，还必须配置能够识别 FakeDNS 的嗅探设置。下方对象是入站内部的 sniffing 字段示例，不是顶层配置。在不支持这些字段或采用其他配置格式的运行组件中，不能直接使用。先确认内核支持，再核对客户端是否已经自动生成等效设置，避免手工重复添加。

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

地址池、缓存与兼容性

ipPool 定义可分配的合成地址范围，poolSize 控制映射容量。地址池必须与实际网络及其他隧道区分，不能随意拿正在使用的局域网地址段代替。默认保留范围也不是绝对不会冲突：测试环境或其他网络产品可能使用相同范围。发生冲突时先确认地址归属与路由，不要只改一个字段便认为整条链路已迁移。

映射只在相关内核及其生命周期内有意义。内核重启后，应用仍可能缓存旧的合成地址，而新实例已经没有对应域名记录，结果就是解析看似正常、后续连接却失败。切换模式时应重启受影响应用，清理必要的解析缓存，再从一次新的域名查询开始测试。长时间运行的后台应用尤其容易保留过期映射。

并非所有应用都接受合成地址。有些程序自行检查地址是否公网可路由，有些把结果交给另一进程或设备，还有些直接固定使用数值地址。前两类可能破坏映射闭环，后一类本来就没有域名可供恢复。出现单一应用异常时，优先为该应用采用普通解析或调整接入方式，而不是不断扩大地址池，容量并不能修复兼容问题。

浏览器自行进行加密 DNS 查询时，查询可能不经过本地 FakeDNS，连接也就不会得到这套映射。反过来，若把合成结果共享给没有运行相同接管链路的其他设备，那些设备通常无法使用。不要把启用 FakeDNS 的本机解析结果当成普通局域网 DNS 服务分发，也不要把合成地址复制到静态服务器配置中。

与规则、解析和回退配合

FakeDNS 恢复域名后，路由仍需命中正确出站；实际建立连接时，也可能需要进一步解析真实地址或把域名交给远端处理。它不会消除所有真实 DNS 需求。代理服务器自身的地址尤其应保留可用的引导解析，避免服务器也拿到只能在已经运行的隧道中处理的合成结果，从而产生启动依赖。

验证时先关闭应用，启动支持映射的配置，再打开应用访问一个明确域名。查看查询是否进入 FakeDNS、连接目标是否落在池中，以及内核是否恢复了域名并命中预期规则。若第一步查询没有进入，就查 DNS 接管；若已经返回合成地址但连接没有进入，就查路由；若连接进入却不能恢复域名，再查嗅探与映射状态。

回退要同时恢复普通 DNS、撤销专门的接管调整，并清理使用过合成结果的应用缓存。只关掉地址池，可能留下继续尝试旧合成地址的进程。回退后先用普通解析验证基础连接，再决定是否重新引入 FakeDNS。保留启用前的 DNS 与路由记录，可以把恢复过程限定在这两层，而不必重建整个订阅配置。

多订阅管理流程

多订阅管理的重点是来源隔离、更新可控与切换可验证，而不是把所有服务器混成一张大列表。主用订阅、备用订阅和临时测试最好分别建组，让每个条目都能追溯来源。订阅增加以后，首先维护的是配置关系：哪组用于日常连接，哪组只在故障时启用，哪些条目允许随更新替换，哪些需要人工保留。

按来源更新，按用途选择

先为每个来源建立独立分组，再用清楚的备注标明用途和更新方式。不要把同一条订阅地址复制成多个用途组来代替分类，这会增加更新请求，并造成重复条目。确实需要相同来源的不同视图时，先了解客户端的过滤能力。来源分组保持稳定，用搜索或支持的过滤项查找用途，通常比重复导入更容易维护。

新增备用订阅时，先只更新该分组，确认日志成功、列表内容合理，再执行真连接测试。不要立即替换主用服务器，也不要同时批量更新其他来源。这样，若订阅返回空内容或新配置无法启动，影响范围仍然清楚。客户端对更新失败和空结果的处理可能不同，重要的手动配置应另行备份，不能依赖一次更新的保留行为。

自动更新间隔应按来源的实际变化频率设置，不宜把频繁请求当作保鲜手段。设备休眠、网络切换与代理尚未启动，都可能造成自动更新失败。判断故障时先看最后一次成功的日志，而不是只看启用了自动更新。需要通过代理获取的订阅，还要明确其依赖哪条现有连接，避免主用连接失效后备用列表也无法刷新。

去重与活动服务器维护

去重应比较连接参数，而不只是别名。相同地址和端口也可能使用不同用户标识、传输路径、服务名称或 TLS 参数，因此不能随便合并。使用客户端的去重功能前，先了解它采用哪些字段，并保留恢复入口。对于只是名称相近的服务器，先按来源保留；确认完全重复后再清理，避免把可用的备用参数当作冗余删除。

订阅更新可能改变条目顺序，也可能替换原来的内部标识。习惯按列表位置选择服务器容易误操作，应在连接前核对当前别名和来源。真连接测速结果也可能随更新失去对应关系，不能沿用旧结果为新条目排序。主用订阅发生参数调整后，重新测试、设为活动服务器并重载，再验证实际应用访问。

备用订阅不等于自动故障切换。普通的活动服务器选择通常只对应一个当前出站，只有显式配置了相应的健康检查、选择或负载策略，才可能按策略切换。不要因为列表有多个来源就假定会自动接替。对多数日常使用，保留一条经过验证的备用路径，并写清手动切换步骤，比引入复杂自动化更便于恢复。

备份、迁移与敏感信息

备份至少要覆盖订阅分组、必要的手动服务器、路由自定义项与 DNS 设置。客户端导出功能包含哪些内容，应实际检查；仅导出服务器链接未必带上路由和程序偏好。备份文件可能含订阅凭据和服务器密钥，应保存在受控位置。迁移到另一设备前，先确认目标客户端支持原协议与传输方式，不要把文件导入成功当作兼容验证完成。

桌面端 v2rayN 与安卓端 v2rayNG、v2flyNG 的完整程序配置不宜直接互相覆盖。服务器分享格式可能可以交换，但分应用代理、系统代理、TUN 接管与本地目录属于各自环境。迁移时先导入服务器，再按目标平台重新配置接入和路由。安卓端后台策略也应重新检查，避免把源设备的稳定表现直接套到新设备上。

订阅地址失效时，区分授权过期、地址被更换和临时网络错误。授权问题应从原来源获取有效地址，再在原分组内替换；网络超时则先检查当前连接与更新路径。不建议把失效地址持续放在自动更新队列中。更换地址后清理旧记录和含凭据的截图，避免旧链接继续散落在同步笔记、剪贴板历史或公开问题记录里。

切换网络后，应先测试主用服务器，再测试备用来源，而不是立即重装客户端。若两个来源都在同一阶段失败，可能是本机端口、DNS 或接管问题；若只有一个来源失败，则优先检查该来源参数。启动日志出现监听地址被占用时，可阅读本地端口冲突定位方法，避免通过删除全部订阅处理无关故障。

自定义出站与配置验证

出站描述内核如何把连接送往下一跳，路由通过标签选择出站。常见的直连、阻断与代理，是不同出口行为，而不是不同订阅分组。客户端通常会为选中的服务器生成代理出站，同时生成辅助出站。只有界面无法表达所需结构时，才考虑自定义配置；日常更换服务器或添加域名例外，优先使用现有服务器和路由界面。

标签与路由引用

tag 是配置内部引用标识，必须与规则里的 outboundTag 一致。标签名称本身没有固定魔法含义，写成 direct 不会自动变成直连，真正行为由协议与参数决定。排错时同时检查标签是否存在、是否重复、协议是否正确。名称拼写不同可能造成规则找不到目标，客户端日志通常会提供相应线索。

下面是 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": {
    "domainStrategy": "AsIs",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["local-socks"],
        "outboundTag": "direct"
      }
    ]
  }
}

示例把监听地址限制为回环地址，是为了不把未认证的本地代理开放到其他设备。改成所有接口监听，会改变访问边界，可能让同一网络的设备使用该端口。确实需要局域网共享时，应单独设计访问控制、认证和防火墙规则，不能只修改监听地址。端口是否可用，也必须以本机实际占用情况为准。

客户端生成与自定义文件

通过图形界面管理的服务器，运行配置通常由客户端生成，直接编辑临时生成文件容易在重载或切换服务器后被覆盖。需要长期保留的规则应写在客户端支持的自定义入口；使用完整自定义配置时，则要明确哪些功能不再由普通服务器设置接管。不要同时修改生成结果和界面字段，再期待两者长期保持同步。

创建代理出站时，地址、端口、用户凭据、传输方式和安全参数必须来自有效配置，不能通过猜测补齐。协议名称相同，也不代表传输路径、服务名称或证书相关参数相同。应先在普通服务器配置中验证连接可用，再考虑迁移到自定义结构。这样可以把连接参数问题与多出站引用问题分开处理，减少排错范围。

多出站不代表自动串联。让某条规则选择备用出站，是按条件选出口；让一个代理出站通过另一个出站连接，则属于链式连接，依赖特定内核的对应能力与字段。两者不能通过简单排列出站数组互相替代。链式连接还会增加启动依赖、延迟与故障点，应先分别验证每一跳，再检查是否出现循环引用。

默认出口也不能忽略。部分配置结构在没有规则命中时使用首个出站，其他运行组件可能有显式的最终出口字段。把新出站插入列表前，必须确认未匹配流量会去哪里。示例用入站标签明确指定出口，正是为了避免靠列表位置推断。实际迁移时应检查客户端生成规则与自定义规则的先后关系，防止后面的规则永远无法命中。

分层测试与恢复基线

验证顺序是先看配置能否加载，再看本地入站能否监听，然后看出站能否建立连接，最后看业务是否命中正确路由。语法正确只解决第一层的一部分问题：未知字段、缺少规则库和不存在的标签，都可能在启动阶段暴露。日志出现错误时先保留错误原文和对应配置位置，不要凭一条泛化提示同时改动多个参数。

本地端口可连接而业务失败时，检查当前出站是否真的被选中，再看 DNS、远端连接和应用协议。通过代理进行测试时，测试工具也必须明确指向正确的本地协议与端口。不要把 HTTP 代理端口当成 SOCKS 端口；客户端版本与运行模式可能改变监听结构，应以状态栏和当前设置为准，而不是凭旧教程中的端口组合判断。

临时增加日志详细程度有助于判断出站选择，但日志也可能包含目标域名、服务器地址和使用习惯。定位完成后恢复日常日志级别，分享前删除敏感字段。若配置持续无法稳定运行，先回到已验证的普通服务器、默认路由与基础 DNS，确认连接恢复，再逐项引入自定义内容。备份应保存能启动的基线，而不只是最近一次编辑结果。