Clash 进阶配置手册

策略组类型与分流实战

先分清规则、策略组与节点

规则决定连接交给谁，策略组决定下一步选择哪个出口，节点负责建立实际代理连接。三者不是同一层设置。把运行模式切到规则模式后，连接先按规则顺序匹配，再进入目标策略组；策略组还可能引用其他组，最终才落到节点或内置的 DIRECT、REJECT。因此，看到规则命中 PROXY，不代表连接已经走某个具体节点，还要展开策略链检查最后的选择。

配置中的名称按字符串引用，大小写、空格和标点都需要一致。将一个组从“自动选择”改名为“自动”，引用它的规则和其他组也要同步修改。遇到 proxy not found 一类错误，先找缺失名称，而不是反复更新订阅。某些界面会保留上一次手动选择；修改组结构后，旧选择不一定仍然有效，应在重载后重新确认当前出口。

手动选择、自动选择与故障转移

select 适合需要明确控制出口的业务；选择结果由用户决定，通常不会因探测结果自动切换。url-test 对候选项执行连通性测试，在满足容差等条件时选择测试表现合适的候选项。fallback 更看重候选项的配置顺序，前面的可用就优先使用。load-balance 则按指定策略分配连接，不是把一个文件传输自动拆分成多条线路。

下面是策略组结构片段，假定现有 proxies 或节点提供器中已经存在“节点-A”和“节点-B”。这两个名称只是示例节点名，使用时应改成运行配置中的真实名称。测试地址是连通性探测目标，不代表真实业务站点；如果该地址被网络环境单独限制，自动选择结果也会失真。先确认手动选择能用，再引入自动选择，更容易判断问题在哪一层。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - 自动选择
      - 节点-A
      - 节点-B
  - name: 自动选择
    type: url-test
    proxies:
      - 节点-A
      - 节点-B
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

稳定出口比频繁切换更重要

interval 控制测试间隔，单位是秒；tolerance 为自动选择提供一定切换容差，避免轻微波动就换出口；lazy 可减少未使用组的无谓测试。不要把所有组的间隔都设得很短。节点提供器还可能有自己的健康检查，两层探测同时密集运行，只会增加请求量和移动端后台负担，不能保证网页更快打开。

登录服务、支付页面和长期会话通常更适合固定策略。自动切换可能让同一账号在短时间内使用不同出口，触发服务端风控。按业务建立单独的手动组，再让相关域名规则指向该组，比全局关闭自动选择更精确。若采用负载均衡，应理解所选分配策略与会话保持的关系，并接受不同连接可能经由不同出口这一事实。

验证时先在连接页面找到目标域名，记录匹配规则、策略组和最终节点，再手动选择另一个已确认可用的节点，关闭旧连接后重新访问。已建立的 TCP 连接一般不会因为切换组而自动迁移。若连接仍显示旧出口，先区分连接复用与配置未生效；若显示新出口仍失败，再检查目标服务、节点可达性与 DNS，避免把所有失败都归因于策略组。

规则集订阅化管理

规则顺序比规则数量更重要

mihomo 的普通规则列表通常从上到下匹配，命中后交给指定策略。精确例外应该放在宽泛规则之前，MATCH 放在最后作为兜底。给某个域名单独设置代理时，如果它上方已有更宽泛的直连规则，该例外就没有机会生效。排查应从连接详情中的实际命中规则入手，先确认请求携带的域名或目标 IP，再找规则顺序，不要只在文件里搜索网站名称。

DOMAIN 匹配完整域名；DOMAIN-SUFFIX 匹配指定后缀及其子域名；DOMAIN-KEYWORD 只看字符串是否包含关键词，容易扩大范围。针对已知服务，优先使用完整域名或明确后缀。一个网页可能同时访问登录、静态资源和接口域名，只处理首页域名不一定覆盖整个流程。应结合连接记录补齐实际依赖，而不是直接把所有连接都切到全局模式。

把规则内容与规则入口分开

rule-providers 负责声明规则内容来源，RULE-SET 决定在什么位置引用它，并指定处理策略。这样可以让规则文件单独更新，主配置只保留清晰的执行顺序。下例使用本地文件，适合先验证结构。将规则文件保存在客户端配置工作目录下的 rules/local-direct.yaml；若客户端将运行目录放在沙盒中，应使用其支持的文件管理入口确认实际位置。

rule-providers:
  local-direct:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - DOMAIN,example.com,DIRECT
  - RULE-SET,local-direct,DIRECT
  - MATCH,PROXY

上述主配置片段中的 PROXY 必须已经定义。下面是对应本地规则文件的内容，example.org 用于演示后缀语法，实际维护时填写需要直连的域名。域名型规则集不是普通规则列表，不应把策略名称写进每条内容。先让这个小规则集正确命中，再迁移大量规则，能把路径错误、格式错误与内容错误分开处理。

payload:
  - '+.example.org'
  - 'example.net'

选择正确的 behavior 与更新方式

behavior: domain 用于域名集合，ipcidr 用于地址段集合，classical 可表达带规则类型的经典规则内容。规则提供器的 format 还要与文件格式对应，不能仅凭文件扩展名判断内容。将 DOMAIN-SUFFIX,example.org 直接放进域名型集合，或把带策略名称的整行规则塞入经典集合，都可能造成解析失败或与预期不同的匹配结果。

远程维护时，将提供器设为 type: http，再填写可信规则源实际提供的 url、独立的 path 与合理的 interval。不要让多个提供器共用一个缓存文件，否则一次更新可能覆盖另一个规则集。规则源变更应先抽查内容，确认没有从域名列表变成网页或错误提示，再在客户端执行提供器更新；只重载配置不一定意味着所有远程文件都重新下载。

按命中路径排查规则集问题

出现规则未生效时，先确认运行模式为规则模式，再看提供器是否加载、名称是否与 RULE-SET 引用一致、规则是否被上方条目提前命中。对于地址规则，no-resolve 可避免为了该条 IP 规则主动解析域名，但它不会把域名规则变成地址规则，也不意味着系统完全停止 DNS 查询。已经有目标 IP 的连接仍可参与地址匹配，应按具体连接信息理解结果。

GEOIP 依赖相应的地理数据库，规则集文件正常不代表数据库也正常。遇到 GeoIP 相关错误，先看日志中的文件路径与下载失败原因，使用客户端提供的数据库更新入口；不要反复删除全部配置目录。对“规则越来越多却更难定位”的情况，先收敛为本地例外、业务分组、公共规则、最终兜底四层，再逐层验证。基础概念可对照术语表，具体故障入口见帮助中心。

DNS 配置优化与解析路径

先画清谁向谁查询

DNS 排查首先要区分应用、操作系统、mihomo 与上游解析器。浏览器可能启用了自己的安全 DNS，系统可能保留手动填写的服务器，TUN 也可能接管部分 DNS 请求。修改 nameserver 以后网页没有变化，不一定是字段无效，可能请求根本没有经过 mihomo。先在客户端日志中观察目标域名的查询，再决定是否调整系统 DNS、浏览器设置或接管方式。

域名形式的加密 DNS 上游还需要先解析其服务器地址，这一步属于引导解析。default-nameserver 用于相关引导过程，不能简单理解成所有业务查询的第一顺位。节点服务器若使用域名，还应关注 proxy-server-nameserver，避免“必须先连代理才能解析节点、又必须先解析节点才能连代理”的循环。代理能否启动与业务域名是否解析正确，应分开验证。

从少量明确的解析器开始

下面是 DNS 段示例，展示引导解析、业务解析与节点域名解析的分工。它不是适合所有网络的统一答案：公共解析器是否可达、是否支持当前网络，都需要实际测试。示例没有设置本地监听地址；如果需要让系统或其他设备主动访问 mihomo DNS，应另行配置 listen，同时检查端口占用、权限和防火墙，不要仅添加一个监听字段就向局域网开放。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'

dns.ipv6: false 影响该 DNS 模块对 AAAA 查询的处理，不等于操作系统已经关闭 IPv6，更不保证所有 IPv6 流量都被接管。若系统仍有 IPv6 路由，应用也可能通过缓存或其他解析途径使用 IPv6。应同时查看运行配置顶层的 IPv6 设置、TUN 路由和连接记录，避免用一个 DNS 开关解释整个网络栈的行为。

按域名设置策略，不堆叠回退

nameserver-policy 可以把特定域名交给指定解析器，适用于企业内部域名或有明确解析要求的服务。企业内网解析器通常只有接入办公网络后才能访问；把它设为所有域名的上游，离开办公网络就可能全面超时。更稳妥的做法是限定内部域名范围，并确认查询路径仍经过正确的网卡。相关域名是否同时需要直连规则，应根据目标地址的可达性单独决定。

解析器写得越多，并不必然越可靠。fallback 与过滤条件共同影响结果选择，不能只看列表顺序就推断“第一个失败才问第二个”。如果使用 respect-rules 让 DNS 连接遵循路由规则，还必须考虑节点域名解析与规则依赖，保留独立可用的节点解析路径。没有明确需求时，先使用少量可达上游，稳定后再增加按域名策略，减少难以解释的交叉依赖。

把 DNS 错误与连接错误分开

排查时按“是否收到查询、是否返回结果、目标是否可连接”三步进行。查询超时优先检查解析器连通性；已经得到地址但 TCP 连接超时，应继续检查策略、出口和路由；只有某个浏览器失败，则检查该浏览器的独立 DNS、代理设置与缓存。Fake-IP 模式下看到保留地址属于设计行为，不应直接认定为 DNS 污染，也不要据此手动把业务域名固定到这个地址。

改动后先关闭目标应用的旧连接，再按客户端支持的方式清理 DNS 与 Fake-IP 缓存；必要时清理系统缓存，但不要每次都重置整个系统网络。证书错误也不能直接靠更换 DNS 解决：应先核对系统时间、证书签发者与访问域名，保持浏览器证书验证开启。若问题只出现在某个出口，固定同一域名分别测试直连与该出口，记录差异后再决定调整方向。

TUN 模式与 Fake-IP 协同

接管流量和返回地址是两件事

TUN 通过虚拟网络接口与路由安排接收流量，适合不遵循系统代理设置的应用；Fake-IP 是 DNS 返回与域名映射机制，用保留地址帮助内核关联后续连接的域名。两者经常同时使用，但并不互相等同。系统代理能用而某个应用不能用，可能是应用绕过代理；TUN 开启后仍失败，也可能是权限、路由冲突或应用自己的联网方式，而不是必须更换 DNS 模式。

启用前先确认当前 Clash 客户端是否提供 TUN 支持，以及是否需要服务模式或管理员权限。Windows 通常需要相应服务或提升权限；macOS 涉及系统授权与客户端实现；Linux 需要创建虚拟接口和管理路由的权限。Android 一般通过系统 VPN 接口接管，不能把桌面端服务模式步骤照搬过去。安装与授权入口以客户端实际界面为准，缺少功能时先回到下载中心核对客户端选择。

先用基础配置建立可回退路径

下面是桌面环境下的 TUN 片段，DNS 部分应与上一章的设置一起检查。auto-route 请求自动配置相关路由；auto-detect-interface 用于识别出口接口；dns-hijack 接管匹配的 DNS 流量。any:53 不代表所有加密 DNS 都能被识别，应用发往 HTTPS 端口的独立 DoH 请求并不等于普通的 53 端口查询。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

stack 可用选项与运行环境、内核能力相关，常见值包括 system、gvisor 和 mixed。不要同时更换网络栈、调整 MTU、启用严格路由，再根据一次访问结果判断哪个改动有效。先使用客户端推荐值，确认网页、下载和局域网访问都正常；只有遇到可重复的问题，再单独比较网络栈，并保留相同的节点、规则与测试应用。

处理 Fake-IP 兼容性与局域网访问

某些设备发现、局域网服务或直接依赖真实地址的应用，可能不适合 Fake-IP 返回值。此时可把明确的域名加入 fake-ip-filter，让它们走真实解析路径，而不是把整个 DNS 模式切换掉。过滤规则只影响相关 DNS 行为，不会自动建立直连路由；内网服务需要直连时，还要检查规则、系统路由和所用网卡。域名能解析为私有地址，也不代表该地址从当前网络可达。

不要把所有域名都加入过滤列表，否则会失去 Fake-IP 的主要作用，并让实际行为更难解释。切换 Fake-IP 模式、地址范围或过滤规则后，旧缓存可能继续让应用连接之前的保留地址。应关闭相关应用连接，清理对应缓存再测试。若企业 VPN、容器网络或实验环境已经使用与 Fake-IP 范围重叠的地址段，需要重新规划范围并同步清理缓存，不能只修改一条路由掩盖冲突。

按权限、路由、DNS、连接逐层定位

TUN 开启失败先看日志是否出现权限不足、设备创建失败或路由添加失败，再处理对应系统层问题。开启成功但无法访问时，先排除其他 VPN 或加速工具同时接管默认路由；确认当前网络出口没有被错误识别，再检查 DNS 查询能否进入内核。不要把所有安全软件和系统防火墙一并关闭，优先检查明确的进程、接口与规则，保留最小必要授权。

如果网页正常但游戏、语音或其他 UDP 应用失败，应确认节点与上游链路支持相关 UDP 转发，再检查规则是否把它送到了正确出口。TUN 接收到 UDP 不等于远端必然能处理。若只有大响应或特定传输失败，再考虑 MTU 与路径问题，使用相同场景做前后对照。最终以连接记录和应用结果共同判断：界面显示 TUN 已开启，只说明接管功能被启用，不说明所有应用都已经按预期分流。

域名嗅探与规则命中修正

哪些连接需要补充域名信息

域名规则需要连接携带可用的域名信息。应用若直接连接 IP、使用自己的解析途径，或者 DNS 查询没有经过 mihomo，连接列表中可能只显示目标地址。域名嗅探尝试从部分协议握手信息中提取域名，再供后续处理使用。它能补齐一部分上下文，但不是修复所有 DNS 问题的总开关，也不能保证任何应用的连接都能还原出域名。

HTTP 的主机信息、TLS 握手中的服务器名称，以及部分 QUIC 握手信息，可能成为识别依据。TLS 嗅探并不等于解密 HTTPS 正文，不需要为此安装抓包根证书，也不能据此读取加密内容。使用加密客户端问候等机制时，可见的域名信息可能受到限制。遇到此类连接，应接受识别能力的边界，改用已知地址范围、应用规则或可靠 DNS 路径，而不是继续扩大嗅探范围。

从明确端口与受限覆盖开始

下面展示常见协议的嗅探段。HTTP 与 TLS 的端口范围用于限定尝试识别的流量，避免对所有端口无差别操作。示例把 override-destination 设为关闭，先观察域名识别是否改善，不立即改变目标地址的处理方式。不同客户端可能通过图形开关生成同一段字段，启用前先确认订阅中是否已有 sniffer，避免本地修改被另一层覆盖。

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443

parse-pure-ip 允许尝试处理纯 IP 连接，不代表这些连接一定包含域名。force-dns-mapping 与 DNS 映射相关场景的处理有关，不能替代正确的 DNS 设置。override-destination 涉及是否采用嗅探所得域名覆盖目标处理，需要结合业务验证；若同时存在按协议设置的覆盖选项，也要检查最终生效值，不能只看顶层开关推断所有连接行为。

识别域名与改变出口要分开验证

先挑一个原本只显示 IP、能够稳定复现的请求，开启嗅探后重新建立连接，观察连接详情是否出现域名，以及匹配规则有没有改变。若识别到了域名却仍然走直连，应检查规则顺序和策略组选择；若仍然没有域名，应检查目标协议、端口与握手是否属于可识别范围。不要因为一条连接没有变化，就认定整个配置没有加载；同一页面的不同资源可能使用不同协议。

嗅探得到的域名也不应被视作毫无条件的事实。有些应用会把不同业务复用在同一连接上，有些连接使用 IP 访问但附带另一名称。启用目标覆盖后如果只有特定服务失败，可以先关闭覆盖进行对照，保留嗅探本身；若证明确实存在兼容性问题，再对明确域名使用 skip-domain 等排除设置。例外应保持可解释，不要加入大量未经验证的服务名称。

兼容性、隐私与性能边界

嗅探会对连接初始数据增加识别处理，收益取决于当前 DNS 路径和业务类型。如果大多数连接已经通过 Fake-IP 正确关联域名，继续扩大识别范围未必有必要。对于服务端长连接或自定义协议，应优先保持原有目标语义；不要为了让日志中的域名更完整，牺牲原本正常的连接。排查结束后应关闭临时调试日志，避免长期保存不必要的域名与访问路径信息。

遇到证书警告时，先核对证书是否属于访问站点，再比较启用与关闭目标覆盖的结果。嗅探不是忽略证书警告的理由，更不能通过允许不安全连接来“验证修复”。若目标域名识别正确、规则也正确，但只在某个节点失败，应转向出口与远端服务排查。对完全无法识别的协议，回到应用自己的代理支持、DNS 解析和 IP 规则设计，通常比继续堆叠嗅探字段更有效。

本地覆写与多订阅合并

先确定修改会在哪一步保留

订阅原文、本地配置副本、覆写规则与最终运行配置是不同对象。直接编辑订阅下载得到的文件，下一次更新时可能被替换；编辑最终运行配置，下一次重载时也可能重新生成。需要长期保留的规则，应放在客户端支持的本地覆写、扩展配置或脚本入口中。各 Clash 客户端的菜单名称和处理顺序不同，不能把某个客户端的脚本接口当作 mihomo 通用字段。

先在界面中确认当前配置来源，以及是否存在全局覆写与单订阅覆写。用一条容易辨认的规则做最小实验：保存、重载、查看运行配置、更新订阅、再次查看运行配置。只有这几个阶段都符合预期，才适合迁移大量定制。若更新后规则丢失，应先定位写入层，不要用更频繁地手动粘贴补救；那样会让配置来源越来越难追踪。

区分完整订阅与节点提供器

完整 Clash YAML 通常包含节点、策略组、规则和其他设置；节点订阅不一定包含这些结构，Base64 编码的节点列表也不能直接当作完整 YAML 使用。多订阅合并前，先确认输入属于哪种格式。需要理解结构差异时，可查阅订阅格式与转换说明。订阅地址中的访问凭据只保存在本机，不要发进公开日志、截图或在线转换页面。

如果已有内容符合 mihomo 节点提供器格式，可以用 proxy-providers 把节点来源与主配置分离。下面使用本地节点文件演示结构，文件应包含真实的 proxies 列表。它不是任意完整订阅的直接替代入口；若输入文件只有网页提示或编码文本，应先在可信的本地流程中处理成正确格式，再交给提供器读取。

proxy-providers:
  office:
    type: file
    path: ./providers/office.yaml
  travel:
    type: file
    path: ./providers/travel.yaml

proxy-groups:
  - name: PROXY
    type: select
    use:
      - office
      - travel

使用远程节点提供器时，应为每个来源分配独立的名称和缓存路径，再填写来源实际提供的地址与更新间隔。不要让节点文件和规则集文件共用路径。若客户端通过自己的导入机制管理订阅，也可以继续让界面负责更新，仅通过本地覆写引用生成后的节点，但必须确认这种引用在更新之后仍有效，不要依赖临时文件名或不稳定的内部目录。

数组、同名对象与优先级

合并最容易出错的是数组语义。把新的 rules 数组加入覆写，有的客户端会替换原数组，有的提供“前置”或“后置”操作，还有的要求脚本显式拼接。映射字段也不一定是递归合并。不要只凭界面上出现“合并”二字就假设所有内容都保留，必须查看生成后的完整配置。特别检查原有 MATCH 是否仍在末尾，本地例外是否真的位于公共规则之前。

多个订阅经常包含相同节点名和策略组名，直接拼接会造成引用歧义、重名冲突或导入失败。可在受控的合并流程中为节点加来源前缀，并同步更新组引用；如果使用提供器的筛选表达式，也要检查更名是否影响筛选结果。不要只修改显示名称，却保留旧的规则目标。合并完成后，应能够从任一规则追踪到存在的策略组，再追踪到有效节点或内置策略。

验证、回退与迁移

可以使用 mihomo 的配置测试模式做语法和引用检查。在已有该可执行文件的命令行环境中执行下面命令，config.yaml 指向待测试文件。相对路径资源依赖运行目录，图形客户端实际工作目录可能不同；命令行检查通过后，仍需在客户端中重载并查看提供器加载结果。语法正确只表示配置可解析，不保证订阅来源可达或所有节点能连接。

mihomo -t -f config.yaml

回退时优先停用本次新增覆写，恢复上一份可用配置，再重载验证。保留“修改目的、涉及字段、验证域名、回退位置”的简短记录，比保留多份无法辨认的配置副本更有用。迁移客户端时先迁移订阅，再迁移规则与 DNS，最后迁移界面层脚本；不同客户端的启动设置、TUN 授权和覆写接口通常需要重新配置，不能只复制一个 YAML 就认为迁移已经完成。

外部控制面板与局域网共享

代理入口与管理入口分别设置

代理端口承接应用流量，控制接口负责读取状态、切换策略与管理连接。把代理共享给同一网络里的设备，并不需要同时开放控制接口。mixed-port 是 HTTP 与 SOCKS 共用的代理监听端口；external-controller 是管理 API 地址。两者用途、权限和风险不同，排查“手机连接不上电脑代理”时，不应通过开放管理端口来解决。

单机使用先让控制接口只监听回环地址。下面是本机管理片段，示例口令是明确的教学假值，实际启用前须在本机生成独立的长随机口令，不要沿用示例。secret 用于控制接口认证，与节点密码、订阅凭据不是同一个字段。若客户端已经管理控制接口参数，应在其设置入口修改，避免手写值被启动过程重新生成。

mixed-port: 7890
allow-lan: false
external-controller: 127.0.0.1:9090
secret: "your-password"

连接面板之前先验证监听与认证

面板通常需要填写控制接口地址和口令。只有控制接口已启动、地址可达、认证通过，界面才能读取策略组和连接。面板打不开与面板能打开却无法连接内核，是两种问题：前者检查面板资源，后者检查 API 地址、端口、认证与浏览器网络限制。若日志出现 address already in use，先找占用该端口的进程，不要把所有监听地址改为全网卡碰运气。

需要本地托管面板时，可把已取得且可信的静态面板文件放进配置工作目录的独立目录，再通过 external-ui 指定路径。不要把整个用户目录作为静态资源目录，避免不相关文件被暴露。通过浏览器访问时还要考虑页面协议：HTTPS 页面请求普通 HTTP 接口，可能受到混合内容限制；跨来源请求也可能需要相应的允许来源设置，这些都不是订阅失效。

面板拥有操作内核的能力，不只是一个只读仪表盘。不要把控制口令放在公开链接的查询参数、公开截图或共享书签中，也不要为了省去认证而清空口令。如果确需远程管理，优先让管理请求经过受控的专用网络或安全隧道，并限制访问来源；反向代理、访问认证和 TLS 都需要独立正确配置，不能靠一个复杂口令代替网络边界。

局域网共享只开放必要代理入口

共享时先确认两台设备处于可互访网络，电脑当前局域网地址稳定，且路由器没有启用客户端隔离。然后在 Clash 客户端开启“允许局域网连接”，检查实际监听地址与系统防火墙，只允许需要的可信网段访问代理端口。手机中填写的是电脑的局域网地址，不是 127.0.0.1；后者在手机上指向手机自身，不会自动指向电脑。

下面是代理共享片段，控制接口仍保持回环监听。bind-address 只在相关允许局域网设置下按其语义生效，应结合实际监听结果检查。示例认证值仍是教学假值，实际使用需替换成本机独立凭据。部分设备的系统代理界面不支持认证，遇到这种情况应评估设备能力与受控网络范围，而不是直接把代理端口暴露给不可信网络。

mixed-port: 7890
allow-lan: true
bind-address: '*'
authentication:
  - "lan-user:your-password"
external-controller: 127.0.0.1:9090
secret: "your-password"

手机 Wi-Fi 中的 HTTP 代理设置通常只影响遵循该设置的应用，不等于所有应用与 UDP 流量都已接管。电脑自身开启 TUN，也不意味着电脑会自动成为手机的透明网关。若目标是整台设备的网络接管，需要明确的网关、路由与 DNS 设计；不要混用“允许局域网连接”和“共享 TUN”两个概念。普通家庭环境先使用应用支持的显式代理，更容易控制范围与定位故障。

用最小测试完成交接

验证共享时先在电脑本机确认代理能访问，再在第二台设备上确认到电脑地址的连通性，最后配置代理并观察电脑连接列表。完全没有新连接，应检查地址、端口、认证与防火墙；出现连接却访问失败，再看命中规则、最终节点和 DNS。若只有部分应用有效，先确认应用是否遵循系统代理，不要继续修改控制接口。公共 Wi-Fi 与访客网络可能隔离终端，即使网络名称相同也不保证能互访。

完成配置后关闭临时开放的端口和调试日志，确认控制接口仍只对预期范围可见，订阅更新没有覆盖本地安全设置。为长期使用保留简短交接记录：代理端口、监听范围、凭据保存位置、覆写入口及恢复方法，记录中不要直接抄入口令。需要重新走基础流程时返回使用文档；遇到导入失败、系统代理残留等日常问题，先查帮助中心，不必把整份进阶配置重新叠加一遍。