JICHANG AIR · 2026机场推荐 | 梯子推荐与机场梯子评测

外观

开了代理却有的网站打不开、有的应用不走代理、国内网站反而变慢，通常只需要回答两个问题：这个应用的流量有没有被客户端接管（系统代理、TUN 还是应用内代理），以及它命中了哪条分流规则。结论先说：日常用规则模式 + 系统代理；命令行、游戏等不读取系统代理的程序，再单独设置代理环境变量或开启 TUN；全局模式只在排查时临时使用；规则从上到下匹配，第一条命中的生效。

本页适合已经能连上节点、但对接管方式和分流规则拿不准的读者，按「一条连接怎么走 → 谁来接管 → 规则怎么匹配 → 走哪个节点 → DNS → 出问题怎么查」的顺序讲解，并给出四个典型场景的设置方案。配置示例以 Clash / Mihomo 类客户端的写法为主，具体字段以所用客户端的官方文档为准。

核心结论 ​

核心结论

  • 接管方式决定「谁会走代理」：系统代理只影响愿意读取它的应用；TUN 模式能接管几乎所有应用。
  • 规则决定「走不走代理」：规则模式按域名、IP、应用等条件从上到下逐条匹配，第一个命中的规则生效。
  • 策略组决定「走哪个节点」：手动选择、自动测速、故障转移等策略组把多个节点组织起来。
  • 日常用规则模式：国内直连、境外代理，兼顾速度、流量和账号安全。
  • HTTP / SOCKS5 是本地入口：它们描述应用如何连到客户端，与机场节点用什么协议无关。
  • DNS 是分流的一部分：解析结果会影响 IP 类规则的判断，也会影响访问速度。
  • 排查从外到内：先确认应用有没有被接管，再看命中了哪条规则，最后看节点本身。

代理与分流速查表 ​

你想解决的问题先记住的结论本页章节
哪些应用会走代理系统代理只影响愿意读取它的应用；TUN 能接管几乎所有应用「系统代理、TUN 和应用内代理有什么区别」
某个网站走不走代理规则从上到下逐条匹配，第一条命中的生效「流量什么时候直连、什么时候走代理」
走哪个节点由命中规则指向的策略组决定「策略组怎么决定走哪个节点」
规则模式还是全局模式日常用规则模式，全局只临时用来排查「规则模式和全局模式该用哪个」
终端、Git 不走代理设置代理环境变量或 Git 代理，工具太多再开 TUN「HTTP、SOCKS5 和本地端口是什么」
规则模式下某网站打不开、全局就好多是该域名被分到了直连，查命中的规则「分流出问题按什么顺序排查」
关闭客户端后上不了网多是系统代理设置残留代理冲突

一条连接从应用到节点要经过哪几步 ​

理解代理与分流，最好的办法是跟着一条连接走一遍：它先被客户端「接住」，再由规则决定去向，最后由策略组选出具体节点。下面是简化后的示意：

text
应用发起连接
  │
  ├─①接管：系统代理 / TUN / 应用内代理 ──> 没被接管：直接走本地网络，客户端完全不知情
  │
  ▼
代理客户端
  ├─②规则匹配：从上到下比对，命中第一条
  │     ├─ DIRECT ──> 直连目标网站
  │     ├─ REJECT ──> 拦截
  │     └─ 策略组 ──> ③选出节点 ──> 机场节点 ──> 目标网站

几个术语的一句话定义：

  • 代理客户端：安装在你设备上的软件，负责导入订阅、接管流量、按规则分流并连接节点；
  • 入站：应用把流量交给客户端的入口，例如本地 HTTP 端口、SOCKS5 端口或 TUN 虚拟网卡；
  • 规则：判断一个连接去向的条件列表；
  • 出站 / 策略：连接最终的去向，可以是直连、拒绝、某个节点或某个策略组；
  • 策略组：把多个节点组织在一起，并按某种方式（手动、自动测速、故障转移）选出当前使用的节点。

这三步分别对应三类问题：①没被接管，表现为「某个应用完全不走代理」；②规则分错，表现为「某个网站该代理却直连了」或反之；③节点问题，表现为「走了代理但很慢或超时」。后文的排查流程就按这个顺序展开。

系统代理、TUN 和应用内代理有什么区别 ​

接管方式决定了哪些应用的流量会进入客户端；常见的有系统代理、TUN 模式和应用内代理三种，可以单独使用，也可以组合使用。

系统代理 ​

客户端在操作系统的网络设置中登记一个本地代理地址（例如 127.0.0.1 加上某个端口）。浏览器等主动读取系统代理设置的应用会把请求发给这个地址。

  • 优点：设置简单，不需要额外权限，对系统影响小；
  • 缺点：不读取系统代理的应用（很多命令行工具、部分游戏和客户端软件）不会走代理。

TUN 模式（虚拟网卡） ​

TUN 模式指客户端创建一块虚拟网卡，并调整系统路由，让流量在网络层先经过这块网卡，再由客户端按规则处理。

  • 优点：几乎所有应用都会被接管，不依赖应用自身是否支持代理；
  • 缺点：通常需要管理员权限或安装系统组件；与其他 VPN、安全软件、虚拟机网络可能冲突。

以 Mihomo（Clash Meta 内核）为例，其官方文档中 TUN 相关的几个常见选项是：stack 选择协议栈实现（如 system、gvisor、mixed），auto-route 自动把全局流量路由进虚拟网卡，auto-detect-interface 自动选择出口网卡，dns-hijack 把匹配的 DNS 请求劫持到内置 DNS 模块，strict-route 用更严格的路由防止 DNS 泄露。普通用户通常只需在图形界面里打开 TUN 开关，这些选项由客户端预设，具体含义和取值以官方文档为准。

应用内代理 ​

在某个应用自己的设置里填写代理地址，只对该应用生效。适合只想让单个软件走代理的场景。

方式接管范围需要权限适合场景
系统代理读取系统代理的应用一般不需要日常浏览，新手首选
TUN 模式几乎所有应用通常需要管理员权限命令行工具、游戏、不支持代理的应用
应用内代理单个应用不需要只让某个软件走代理

该怎么选 ​

  1. 刚开始使用：只开系统代理，确认浏览器能正常访问；
  2. 终端、开发工具或某些软件不走代理：先尝试为它们单独设置代理（见后文），不方便时再开 TUN；
  3. 游戏、通讯软件等需要 UDP 的场景：TUN 模式通常更合适；
  4. 开 TUN 后出现异常：先关闭其他 VPN、加速器和安全软件的网络防护，仍有问题就退回系统代理。

各平台怎么接管流量、怎么检查是否生效 ​

不同操作系统对代理的支持方式不同，桌面系统以系统代理和 TUN 为主，手机系统则以 VPN 接口为主。下表是概览，具体菜单名称以系统版本和客户端为准：

平台常见接管方式系统代理设置位置（概括）备注
Windows系统代理、TUN设置中的「网络和 Internet」→「代理」部分系统服务使用独立的 WinHTTP 代理设置
macOS系统代理、TUN（增强模式）系统设置中的网络 → 对应网络服务的代理设置每个网络服务（Wi-Fi、有线）单独设置
Linux 桌面系统代理、TUN、环境变量桌面环境的网络设置很多程序只认环境变量
AndroidVPN 接口客户端首次开启时请求 VPN 授权效果接近 TUN，部分客户端支持按应用分流
iOS / iPadOSVPN 接口客户端首次开启时请求添加 VPN 配置效果接近 TUN

手机上的情况

Android 和 iOS 上的代理客户端通常以系统 VPN 接口的方式工作，效果接近 TUN 模式，所以首次开启时系统会请求添加 VPN 配置的授权。同一时间系统一般只允许一个 VPN 处于连接状态。

用命令检查系统代理是否生效 ​

  • macOS：在终端运行 scutil --proxy，可以看到当前生效的系统代理配置，例如 HTTP、HTTPS、SOCKS 是否启用以及地址端口；
  • Windows：系统代理（用户代理）在设置界面里查看；部分后台服务使用的 WinHTTP 代理是另一套设置，可以用 netsh winhttp show proxy 查看。这两套设置互相独立，浏览器能用不代表后台服务也走代理；
  • Linux / macOS 终端：运行 env | grep -i proxy，查看当前终端是否设置了代理环境变量。
bash
# macOS：查看当前系统代理配置
scutil --proxy

# macOS / Linux：查看当前终端的代理环境变量
env | grep -i proxy
powershell
# Windows：查看 WinHTTP 代理（与系统设置里的用户代理是两套设置）
netsh winhttp show proxy

各平台客户端的安装与设置，见 Windows 客户端、macOS 客户端、Android 客户端 和 iOS 客户端。

流量什么时候直连、什么时候走代理 ​

规则是一张从上到下的列表，客户端拿每个连接依次比对，命中第一条就停止；这条「首个命中」原则是理解所有分流问题的关键。

连接的几种去向 ​

  • DIRECT（直连）：不经过节点，直接访问目标；
  • 代理 / 策略组：交给某个节点或一组节点（例如「自动选择」「香港」）处理；
  • REJECT（拒绝）：直接拦截，常用于屏蔽广告或追踪域名。

规则如何匹配 ​

最后通常有一条兜底规则处理所有未命中的连接。下面以常见的 Clash 类规则写法为例，仅用于说明结构：

yaml
rules:
  - DOMAIN-SUFFIX,example.cn,DIRECT    # 某个域名及其子域名直连
  - DOMAIN-KEYWORD,example,代理         # 域名包含关键字时走代理
  - IP-CIDR,192.168.0.0/16,DIRECT      # 局域网地址直连
  - GEOIP,CN,DIRECT                    # 目标 IP 属于中国大陆时直连
  - MATCH,代理                          # 兜底：其他全部走代理
常见规则类型匹配依据用途
DOMAIN完整域名精确匹配单个域名
DOMAIN-SUFFIX域名后缀（含子域名）最常用的分流依据
DOMAIN-KEYWORD域名中包含的关键字覆盖面广，但容易误伤
GEOSITE预置的域名分类列表按服务或地区批量匹配域名
IP-CIDR / IP-CIDR6目标 IP 地址范围局域网、特定服务器
GEOIP目标 IP 所属国家或地区国内外大方向分流
PROCESS-NAME发起连接的程序名按应用分流（部分平台支持）
RULE-SET引用外部维护的规则集让规则保持更新、配置更简洁
MATCH所有未命中的连接兜底，决定「默认去哪」

上表的规则名称来自 Mihomo 官方文档，它还支持端口、网络类型、逻辑组合（AND / OR / NOT）等更多类型。其他客户端（如 sing-box、Surge 等）的写法不同，概念大致相通，具体语法以各自官方文档为准。

域名规则和 IP 规则的区别 ​

域名规则直接看你访问的域名，不需要解析就能判断；IP 类规则（IP-CIDR、GEOIP）需要知道目标 IP，如果连接只带域名，客户端可能要先做一次 DNS 解析才能匹配。Mihomo 为 IP 类规则提供了 no-resolve 参数，用于跳过这一步解析：带了它的 IP 规则只匹配本来就是 IP 的连接。

这带来两个实际影响：

  • 把域名规则放在 IP 规则之前，能让大部分连接在不解析的情况下就完成匹配，速度更快；
  • IP 规则依赖解析结果，解析得不准，GEOIP 判断也会跟着出错，这就是 DNS 需要分流的原因之一。

顺序很重要

规则写得再多，顺序错了也会出问题。例如把「GEOIP 中国直连」放在某个境外服务的域名规则之前，而该服务恰好在国内有节点 IP，就可能被误判为直连。各客户端的具体语法以其官方文档为准。

一份合理的规则顺序 ​

从上到下，一般按「越具体越靠前」排列：

  1. 局域网和保留地址直连（路由器后台、内网服务）；
  2. 拦截规则（广告、追踪，可选）；
  3. 你自己添加的少量自定义规则（例如某个服务固定走某个策略组）；
  4. 各服务的域名规则或规则集（AI、流媒体、常用境外服务走代理，常用国内服务直连）；
  5. GEOIP 中国直连；
  6. 兜底规则。

规则集与订阅自带规则 ​

规则集是由他人维护、可以远程引用的一组规则，例如「常见国内服务域名」「常见境外服务域名」。订阅自带的规则通常已经引用了若干规则集，客户端会按设定的间隔自动更新。它的好处是新出现的域名能及时被覆盖，不需要你手动维护；代价是你把一部分分流决定交给了规则集的维护者。

使用时可以遵循三条原则：优先使用订阅或客户端默认引用的规则集；自己添加的规则只写真正需要的少数几条，并放在规则集之前；如果某个规则集长时间没有更新、频繁误判，就停用它而不是在后面不断打补丁。

策略组怎么决定走哪个节点 ​

策略组把多个节点组织起来，并决定当前用哪一个；规则只负责把连接交给某个策略组，具体节点由策略组选出。Mihomo 官方文档列出的主要策略组类型如下：

类型选择方式适合场景注意事项
select手动选择AI 工具、需要固定出口的服务节点失效时不会自动切换
url-test按健康检查结果自动选择响应最快的节点日常浏览出口可能频繁变化
fallback按顺序使用第一个可用节点，不可用时切到下一个希望稳定又能自动容灾列表顺序决定优先级
load-balance把流量分散到多个节点大量并发连接同一服务可能从不同出口访问，💡 进阶升级方案对地区敏感的服务
relay让流量依次经过多个节点特殊需求延迟增加，普通用户很少需要

多数订阅已经预设了策略组，例如「节点选择」「自动选择」「故障转移」以及按地区划分的分组。你通常只需要在客户端界面里为每个分组选好节点，不需要改配置。

节点名称中的倍率也要看

自动选择类策略组只看延迟，不看流量倍率。如果你对流量敏感，可以留意自动选中的节点是否是高倍率，相关计费规则见 流量与计费入门。

规则模式和全局模式该用哪个 ​

规则模式是日常使用的默认选择，全局模式只适合临时排查；大多数客户端提供三种出站模式：

模式行为优点缺点
规则模式按规则列表决定直连或代理国内快、省流量、不易触发国内应用异地提醒规则不完善时个别网站可能分错
全局模式所有流量都走选定的节点简单粗暴，排查时有用国内访问变慢，消耗更多流量，可能触发风控
直连模式所有流量都不走代理临时关闭代理但保留客户端运行等同于没开代理

在 Mihomo 中，这三种模式对应配置项 mode 的取值 rule、global、direct，默认是 rule。

什么时候用全局模式 ​

  • 排查问题：怀疑某个网站被规则分错时，临时切到全局看能否访问；
  • 规则未覆盖的新服务：临时使用，之后应补充规则而不是长期开全局。

规则模式也有「分错」的时候

如果在规则模式下某个境外网站打不开，切到全局能打开，说明这个域名被规则分成了直连。可以在客户端的连接日志里查看它命中的规则，再为它添加一条代理规则。添加方法见 配置与规则。

全局模式下的流量全部计入机场流量，详见 流量与计费入门。

直连模式的用途 ​

直连模式常被忽略，但在排查时很有用：客户端保持运行、系统代理保持开启，只是所有连接都不走节点。如果切到直连模式后问题依旧（例如某个国内网站仍然打不开），说明问题与节点和规则无关，应检查本地网络或客户端的接管设置；如果切到直连后恢复正常，再回到规则模式逐条检查规则。

全局模式不等于「更安全」 ​

有人认为全局模式让所有流量都经过节点，因此更隐私、更安全。实际上，代理节点同样能看到你连接了哪些域名，把国内银行、支付、工作软件的流量也送到境外节点，反而可能触发这些服务的异地登录提醒或风控。按用途分流，让国内服务保持直连，通常是更稳妥的做法。

HTTP、SOCKS5 和本地端口是什么 ​

这里的 HTTP 和 SOCKS5 指的是本地应用连接到代理客户端时使用的协议，和机场节点使用的传输协议是两层不同的东西：

text
应用 ──HTTP / SOCKS5──> 本地客户端 ──节点协议（由订阅决定）──> 机场节点 ──> 目标网站
对比项HTTP 代理SOCKS5 代理
工作层面应用层，理解 HTTP 请求会话层，只负责转发连接
支持流量HTTP；HTTPS 通过 CONNECT 方法建立隧道任意 TCP 连接，并定义了 UDP 转发
常见使用者浏览器、系统代理、多数命令行工具需要通用代理的软件、部分游戏和通讯工具
地址写法示例http://127.0.0.1:端口socks5://127.0.0.1:端口

许多客户端提供「混合端口」，同一个端口同时接受 HTTP 和 SOCKS5 连接（在 Mihomo 中对应 mixed-port，另有单独的 port 与 socks-port）。具体端口号以客户端设置界面显示为准。

给命令行工具设置代理 ​

很多命令行工具会读取代理环境变量。以 macOS / Linux 的 shell 为例，临时对当前终端生效：

bash
export http_proxy=http://127.0.0.1:端口
export https_proxy=http://127.0.0.1:端口
export all_proxy=socks5://127.0.0.1:端口
export no_proxy=localhost,127.0.0.1

把「端口」替换为客户端显示的本地端口。no_proxy 列出不走代理的地址，避免访问本机服务时绕到代理上。并非所有工具都读取这些变量，读取哪个变量、大小写是否敏感也因工具而异：例如 curl 官方文档说明，http_proxy 只接受小写形式，其他变量大小写均可。不行时可以改用 TUN 模式。

Windows PowerShell 中对当前窗口临时生效的写法是：

powershell
$env:HTTP_PROXY = "http://127.0.0.1:端口"
$env:HTTPS_PROXY = "http://127.0.0.1:端口"

本地端口常见问题 ​

本地端口是应用与客户端之间的约定，端口不对，应用的请求就到不了客户端。常见情况有：

  • 端口被占用：另一个程序（包括另一个代理工具）占用了同一端口，客户端启动失败或系统代理指向了错误的程序。换一个端口，或关闭占用它的程序；
  • 端口改了但应用没改：在客户端里修改端口后，系统代理通常会自动更新，但你手动填写过的环境变量、应用内代理、浏览器扩展不会，需要逐一改过来；
  • 协议填错：把 SOCKS5 端口当作 HTTP 代理填写（或反之），应用会连接失败。使用混合端口可以避免这个问题；
  • 只监听本机：默认情况下本地端口只接受本机连接，局域网里其他设备连不上是正常的，需要的话再按下文的安全提醒开启局域网连接。

单独为 Git 设置代理 ​

Git 通过 HTTPS 访问远程仓库时，会读取上述环境变量；也可以用 http.proxy 配置项单独设置，Git 官方文档说明该配置会覆盖环境变量：

bash
# 示例：只为 Git 设置代理
git config --global http.proxy http://127.0.0.1:端口

# 取消设置
git config --global --unset http.proxy

通过 SSH 地址（形如 git@...）克隆的仓库不走这个配置，需要另外处理或改用 TUN。命令行 AI 工具的代理注意事项见 Claude Code 使用指南 和 API 使用指南。

节点协议在哪里看

节点使用的传输协议由机场订阅决定，客户端会自动处理，普通用户无需手动选择。只需确认你的客户端支持订阅中使用的协议，见 客户端下载。

怎样按域名、应用和目标地区分流 ​

好的分流规则应该让「该直连的直连、该代理的代理，并且代理到合适的地区」。可以从三个维度来设计：

按域名分流 ​

最常用、最精确。把常用的境外服务域名指向代理策略组，国内常用服务指向直连。大多数订阅自带的规则已经覆盖主流网站，你只需补充少量自己常用但未覆盖的域名。

按应用分流 ​

部分平台的客户端支持按进程名匹配，例如让某个下载工具始终直连、让某个开发工具始终走代理。适合「某个软件整体该走哪里」很明确的场景。Android 上的不少客户端还提供「分应用代理」开关，可以直接勾选哪些应用走 VPN。

按目标地区分流 ​

不同服务对出口地区有不同要求，可以为它们建立专门的策略组：

场景分流思路
AI 工具单独建一个策略组，固定使用该服务支持地区的稳定节点，避免频繁切换出口
流媒体按想观看内容的地区分组，例如「日本流媒体」「美国流媒体」
日常浏览使用「自动选择」策略组，按延迟自动挑选
国内服务直连
局域网、路由器后台直连

下面是一个示例片段，展示如何为 AI 服务单独建组并让相关域名走这个组。域名用 example 占位，策略组和节点名称需替换为你订阅中的实际名称，完整写法以客户端官方文档为准：

yaml
# 示例：为 AI 服务建立手动选择的策略组
proxy-groups:
  - name: AI 服务
    type: select
    proxies:
      - 节点A        # 替换为订阅中支持该服务地区的稳定节点
      - 节点B

rules:
  - DOMAIN-SUFFIX,ai-example.com,AI 服务
  - DOMAIN-SUFFIX,ai-example-api.com,AI 服务
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

出口频繁变化可能触发风控

AI 工具、支付、社交账号等对登录地区较敏感。频繁切换不同国家的节点，或使用「自动选择」导致出口来回跳动，可能触发验证或风控。为这类服务固定一个地区更稳妥，参见 AI 工具使用指南 和 AI 机场推荐。

自定义规则会被订阅更新覆盖吗 ​

很多客户端在更新订阅时会用服务商的配置替换整份文件，直接改在订阅配置里的规则可能丢失。稳妥的做法是使用客户端提供的「覆写」「合并」「脚本」或「自定义规则」功能，让你的规则独立于订阅保存。具体功能名称因客户端而异，操作方法见 配置与规则 和 订阅导入通用教程。

典型场景该怎么设置接管与分流 ​

不同使用场景需要的接管方式和规则重点不同，先确定场景，再决定开不开 TUN、要不要单独建组，可以少走很多弯路。下面的场景均为示例场景，用来说明思路。

示例场景一：只用浏览器查资料和使用 AI 网页版 ​

  • 接管方式：系统代理即可，不需要 TUN；
  • 规则重点：保持订阅自带的规则模式，为常用的 AI 服务固定一个支持地区的节点；
  • 常见问题：AI 网页能打开但登录或验证失败，多是登录相关的某个域名被分成了直连，或者出口地区在不同请求之间发生了变化，按排查流程逐个检查域名即可。

示例场景二：开发者需要终端、包管理器和 Git 走代理 ​

  • 接管方式：浏览器用系统代理；终端优先设置环境变量，Git 可单独设置 http.proxy；如果工具太多、逐个配置太麻烦，再开 TUN；
  • 规则重点：公司内网、私有仓库、本地开发服务必须直连，记得写进 no_proxy 和直连规则；国内镜像源也应直连，既快又省流量；
  • 常见问题：设置了环境变量后访问本机服务失败，通常是 no_proxy 没有包含 localhost 和 127.0.0.1。

示例场景三：游戏或语音通话 ​

  • 接管方式：这类应用常用 UDP 且多半不读取系统代理，一般需要 TUN 或手机上的 VPN 接口；
  • 规则重点：确认所用节点和客户端支持 UDP 转发；为游戏进程或域名固定一个延迟稳定的节点，避免自动选择中途切换导致断线；
  • 常见问题：能登录却无法匹配或语音无声，多与 UDP 未被正确转发有关。请注意部分游戏和平台的条款对使用代理有限制，使用前请了解相关规定。

示例场景四：家里多台设备共用 ​

  • 接管方式：在路由器上运行代理客户端，或在一台常开的设备上开启局域网连接，让其他设备把它当作代理；
  • 规则重点：路由器后台、智能家居、局域网打印机等地址必须直连；电视盒子看流媒体可以单独建地区组；
  • 常见问题：家里所有设备都受影响，排查时先在单台设备上复现。是否允许多人共用由服务条款决定，设备数限制见 流量与计费入门，路由器方案见 路由器客户端。
场景推荐接管方式规则重点
浏览器为主系统代理订阅自带规则 + AI 固定节点
开发与命令行环境变量 / Git 配置，必要时 TUN内网、本地、镜像源直连
游戏与语音TUN / VPN 接口UDP 支持、固定低延迟节点
家庭多设备路由器或局域网共享局域网地址直连、按设备或地区分组

DNS 为什么也要分流 ​

DNS 是把域名翻译成 IP 地址的过程；在代理场景下，用哪个 DNS、在哪里解析，会直接影响规则判断是否准确和访问速度。

为什么 DNS 也要分流 ​

  • 境外域名用国内 DNS 解析，可能得到不准确或被污染的结果，导致连接失败或 GEOIP 误判；
  • 国内域名用境外 DNS 解析，可能被分配到距离较远的服务器，国内网站反而变慢；
  • 应用自己发出的 DNS 请求如果绕过了客户端，还可能出现所谓的「DNS 泄露」，即你访问了哪些域名被本地网络看到。

fake-ip 与 redir-host ​

以 Mihomo 为例，其 DNS 有两种增强模式：

模式做法特点
redir-host正常解析出真实 IP 再处理连接行为直观，兼容性较好
fake-ip先给域名分配一个虚拟 IP，连接时再按域名处理减少解析等待，域名规则匹配更直接；少数依赖真实 IP 的应用需要加入过滤名单

官方文档还提供了 nameserver-policy，可以指定某些域名交给特定的 DNS 服务器解析，以及 fake-ip-filter，用于让部分域名不分配虚拟 IP。普通用户一般使用订阅或客户端的默认设置即可，遇到个别应用异常时，再考虑把它加入过滤名单。

先排除浏览器的安全 DNS

部分浏览器开启了「安全 DNS」（DNS over HTTPS）后，会自己解析域名，可能与客户端的 DNS 设置产生不一致。排查解析问题时，可以先临时关闭浏览器的这项设置再测试。Android 系统的「私人 DNS」也可能影响客户端对 DNS 的接管。

遇到相关问题见 DNS 问题。

浏览器、系统和应用的代理设置是什么关系 ​

一个连接走不走代理，取决于多层设置叠加的结果；从应用到客户端依次是：

  1. 应用自身设置：如果应用内单独设置了代理或「不使用代理」，通常优先于系统设置；
  2. 浏览器扩展：代理切换类扩展会接管浏览器的代理设置，可能覆盖系统代理；
  3. 系统代理：应用选择「跟随系统」时读取这里；
  4. TUN / VPN 接口：在网络层接管，应用即使不走系统代理也会被导入；
  5. 客户端规则：流量进入客户端后，由规则决定直连还是代理。
现象可能原因处理思路
浏览器能用，终端不行终端工具不读取系统代理设置环境变量或开 TUN
某个浏览器不走代理浏览器扩展或浏览器内代理设置覆盖了系统设置检查扩展和浏览器网络设置
关闭客户端后无法上网客户端异常退出，系统代理未被清除手动关闭系统代理，或重新打开客户端再正常退出
开启 TUN 后部分功能异常与其他 VPN、安全软件、虚拟机网卡冲突关闭冲突软件，或改用系统代理
国内网站变慢处于全局模式，或规则把国内域名分成代理切回规则模式，检查规则
局域网设备、打印机访问异常局域网地址被分到代理确认局域网地址有直连规则
应用提示异地登录国内应用被分到境外节点为该应用的域名添加直连规则

浏览器扩展与 PAC ​

PAC（代理自动配置）是一个脚本文件，浏览器或系统按其中的函数逐个判断网址该直连还是走某个代理。有些客户端和浏览器扩展会使用 PAC 或自己的规则来决定浏览器流量去向，这相当于在客户端规则之前又加了一层分流。如果浏览器里的表现与客户端连接日志对不上，先检查是否有扩展或 PAC 在起作用；排查期间可以暂时停用扩展，让浏览器只跟随系统代理，问题定位后再决定是否保留。

不要同时开多个代理工具

同时运行多个代理客户端、VPN 或加速器，容易相互抢占系统代理和路由，导致连接异常且很难排查。排查前先只保留一个。更多情况见 代理冲突。

分流出问题按什么顺序排查 ​

分流问题应按「接管 → 规则 → 节点」的顺序从外到内排查，每一步都先确认再进入下一步，避免同时改多处设置。

第一步：确认流量有没有进入客户端 ​

  1. 打开客户端的「连接」或「日志」页面；
  2. 在出问题的应用里重新发起访问；
  3. 如果连接列表里看不到相关域名，说明应用没被接管：检查系统代理是否开启、应用是否读取系统代理，必要时设置环境变量或开 TUN。

第二步：确认命中了哪条规则 ​

  1. 在连接列表里找到相关域名，查看它命中的规则和最终去向；
  2. 如果去向是 DIRECT 而你希望走代理，为它添加代理规则，并放在会误命中的规则之前；
  3. 如果去向是代理而你希望直连（例如国内服务），添加直连规则；
  4. 一个网页往往涉及多个域名（主域名、图片、接口、登录），要逐个检查，而不只看地址栏里的那一个。

第三步：确认节点本身是否正常 ​

  1. 在策略组里换一个同地区节点，看问题是否消失；
  2. 换一个其他地区节点，判断是不是该地区被目标服务限制；
  3. 所有节点都超时，参考 节点全部超时排查；
  4. 能连但很慢，参考 速度慢与断流。

症状速查 ​

症状最可能出问题的环节去哪里看
某个应用完全不走代理接管本页「系统代理、TUN 和应用内代理有什么区别」
规则模式打不开、全局能打开规则本页「流量什么时候直连、什么时候走代理」
网站能打开但图片或登录失败规则（部分域名分错）连接日志逐个检查域名
解析失败、偶发打不开DNSDNS 问题
提示证书或 TLS 错误时间、证书或中间设备TLS 与证书问题
所有网站都很慢节点或本地网络速度慢与断流

使用代理与分流要注意哪些安全与合规问题 ​

代理客户端掌握着你设备上大部分网络流量的去向，配置时要遵循「最小开放、来源可信」两条原则。

  • 谨慎开启局域网连接：Mihomo 的 allow-lan 等选项允许局域网内其他设备通过你的代理端口上网。只在确实需要时开启，并限制允许的地址范围，不要在公共 Wi-Fi 下开启；
  • 控制面板不要暴露：部分客户端提供网页控制面板或外部控制接口，如果监听在所有网卡上且没有设置密钥，同一网络里的他人可能修改你的配置；
  • 规则来源要可信：远程规则集和覆写脚本会直接改变流量去向，只使用来源清楚、持续维护的规则；
  • 订阅链接是凭证：分享配置截图或文件前，先去掉订阅地址和节点信息；
  • 客户端从官方渠道获取：下载渠道见 客户端下载。

请在所在地法律法规允许的范围内使用代理工具，并遵守所用服务的条款。

常见问题 ​

系统代理和 TUN 模式有什么区别？

系统代理是在操作系统里登记一个代理地址，只有主动读取这个设置的应用才会走代理；TUN 模式通过虚拟网卡在网络层接管流量，大多数应用不需要自己支持代理也会被接管。

规则模式和全局模式该用哪个？

日常建议使用规则模式：国内网站直连、境外网站走代理，速度快也省流量。全局模式只适合临时排查问题，或者确实需要所有流量都走代理的场景。

为什么开了代理，终端或某些软件还是连不上？

很多命令行工具和部分应用不读取系统代理设置。可以为它们单独配置代理环境变量或应用内代理，也可以开启客户端的 TUN 模式统一接管。

HTTP 代理和 SOCKS5 代理有什么不同？

两者都是本地应用连接代理客户端的方式。HTTP 代理主要面向网页类流量，兼容性广；SOCKS5 更通用，可以转发任意 TCP 连接，也支持 UDP。许多客户端同时提供两种端口。

分流规则是怎么匹配的？

客户端把每个连接与规则列表从上到下依次比对，命中第一条就停止并按该规则处理，最后一条兜底规则负责所有未命中的连接。所以规则的顺序和内容同样重要。

关闭代理客户端后上不了网怎么办？

通常是客户端异常退出后系统代理没有被清除，系统仍把请求发往一个已不存在的本地地址。到系统网络设置里关闭代理，或重新打开客户端再正常退出即可。

为什么规则模式下有的境外网站打不开，切全局就好了？

说明这个网站的某个域名被规则分成了直连。在客户端连接日志里找到它命中的规则，为该域名添加一条走代理的规则，再切回规则模式。

AI 工具和流媒体为什么建议单独建策略组？

这类服务对出口地区和稳定性比较敏感。单独建组并固定使用支持地区的稳定节点，可以避免自动选择导致出口来回切换而触发验证或风控。

延伸阅读 ​

更新记录 ​

日期变更
2026-10-07首次发布完整内容
2026-10-07扩写为深度指南
2026-10-08按搜索结果页结构调整：开头直接回答、增加速查表、二级标题改为问题式

本专题文章 ​

暂无文章，敬请期待。