适用场景
Mihomo 已经在用，或准备接入。入口、规则和 DNS 继续交给 Mihomo，WARP 只负责出口。
为什么要用 WARP
WARP 在这里的作用很简单，提供一个默认出口。维护对象集中在本地 SOCKS5 入口和固定链路，配置简单，排错路径也清楚。
统一出口
需要出站的流量汇到同一个上游，不用为不同应用分别设置网络出口。
规则留在 Mihomo
分流、DNS、TUN 和应用入口继续由 Mihomo 管理，现有配置方式可以保留。
维护成本更低
只维护本地 SOCKS5 入口和固定链路，少一层系统代理，少一层网络接管。
排错更直接
链路固定为 Client -> Mihomo -> WARP -> Internet，端口、日志和请求都能单独验证。
使用边界。
多地区出口、固定 IP、复杂节点切换和大规模代理池属于其他场景。这里的 WARP 角色是统一出口。
这套方案怎么工作
链路分成两层。WARP 负责出口，Mihomo 负责控制。WARP 在本机提供 SOCKS5 入口，Mihomo 负责接入、分流、DNS 和规则。
链路图
客户端先进入 Mihomo，再由 Mihomo 转给 WARP。
链路分解
-
1WARP
在本机打开一个 SOCKS5 入口，监听127.0.0.1:40000 -
2Mihomo
把这个本地入口注册为上游节点WARP -
3Rules
让需要出站的流量经策略组汇入WARP，其余流量继续按规则处理
关键约束。
启动 Mihomo 前，先确认
127.0.0.1:40000 已经监听。当前写法不启用 WARP 和 Mihomo 的双重全局接管。
使用前先确认
先看环境，再看端口。很多问题在这一步就能排掉。
适用场景
- macOS 或 Windows Git Bash
- 已经在用或准备使用 Mihomo
- 希望继续让 Mihomo 管理入口、规则和 DNS
- 希望把 WARP 接入现有分流链路，而不是单独接管整个系统网络
前置环境
- macOS 需要
brew、curl和 Bash - Windows 需要
Git Bash、winget.exe和curl - 本机未被占用的端口
40000、7890、1053 - 可以执行
warp-cli和mihomo
warp-cli --version
mihomo -v先安装好 WARP 和 Mihomo
安装脚本如下。install_mihomo_warp.sh 负责安装 WARP，并把 Mihomo 下载到指定路径。
macOS
curl -fsSLO https://clash-static-20260324.pages.dev/install_mihomo_warp.sh
bash install_mihomo_warp.sh --path "$HOME/.local/mihomo-warp/bin"
export PATH="$HOME/.local/mihomo-warp/bin:$PATH"
WARP 通过 Homebrew cask 安装。
Windows Git Bash
curl -fsSLO https://clash-static-20260324.pages.dev/install_mihomo_warp.sh
bash install_mihomo_warp.sh --path "$HOME/.local/mihomo-warp/bin"
export PATH="$HOME/.local/mihomo-warp/bin:$PATH"
WARP 通过
winget.exe 安装。
| 脚本参数 | --path、--skip-warp、--skip-mihomo |
|---|---|
| WARP 安装位置 | 由系统安装器决定，不受 --path 控制 |
| Mihomo 安装位置 | 安装到 --path 指定目录 |
| 版本策略 | 默认拉取 MetaCubeX 官方最新 stable release |
配置关键点
配置只看四个点：入口端口、DNS 监听、WARP 上游、规则去向。
应用连接 Mihomo 的入口端口。浏览器和客户端通常连接该端口，不直接连接 WARP。
让 DNS 解析也留在 Mihomo 体系里，避免流量分流和域名解析分成两套逻辑。
这是 WARP 在本机打开的 SOCKS5 入口。Mihomo 把它当成上游节点来使用。
私有地址和中国大陆流量直连，其余需要出站的流量经策略组汇入 WARP。
mixed-port: 7890
dns:
listen: 127.0.0.1:1053
proxies:
- name: WARP
type: socks5
server: 127.0.0.1
port: 40000按这个顺序启动
启动顺序固定。先起 WARP，再测配置，最后起 Mihomo。顺序固定以后，报错位置也固定。
01
进入配置目录
将终端切到 Mihomo 配置目录，后续命令从该目录执行。
cd /path/to/your/clash-config02
准备 WARP 本地入口
固定监听端口为 40000，确保它与当前 Mihomo 配置保持一致。
warp-cli mode proxy
warp-cli proxy port 40000
warp-cli connect
warp-cli status03
检查 Mihomo 配置
先确认配置文件语法正确，再真正启动 Mihomo。
mihomo -t -f mihomo.yaml04
启动 Mihomo
前台和后台都可以。第一次排错时，前台输出更直接。
mihomo -f mihomo.yaml
# 后台运行
nohup mihomo -f mihomo.yaml > mihomo.log 2>&1 &启动后怎么验证
验证分三步：看端口，看日志，看请求。
检查 WARP 监听端口
先确认 WARP 已经把本地出口打开。
lsof -nP -iTCP:40000 -sTCP:LISTEN检查 Mihomo 监听端口
再确认客户端要连接的端口已经被 Mihomo 接住。
lsof -nP -iTCP:7890 -sTCP:LISTEN查看后台日志
后台运行时，日志是第一排查入口。
tail -f mihomo.log验证出口请求
真正发一个经过 Mihomo 的请求，确认整条链路通了。
curl --proxy socks5h://127.0.0.1:7890 \
https://www.cloudflare.com/cdn-cgi/trace
正常现象。
ruleset/ 初始为空并不代表配置错误。Mihomo 首次成功启动后会自动下载 rule-providers 对应的规则文件。
出问题时先看哪里
排错按层走。先查 WARP，再查 Mihomo，最后查客户端。
WARP 显示已连接，但 Mihomo 不通
先检查 warp-cli status 是否仍保持已连接状态，再确认 127.0.0.1:40000 是否真的在监听。
40000 端口被占用
更改 WARP 端口后，必须同步修改 mihomo.yaml 中上游节点的端口，否则链路会断在 Mihomo 到 WARP 这一段。
Mihomo 已启动，但流量没有走 WARP
按顺序检查规则选择、WARP 端口、Mihomo 日志，以及客户端是否真的连到了 127.0.0.1:7890。
需要停用整套链路
停用顺序为：先停 Mihomo，再执行 warp-cli disconnect。反向顺序会让 Mihomo 持续报上游不可用。
最短启动命令
常用命令如下。
cd /path/to/your/clash-config
warp-cli mode proxy
warp-cli proxy port 40000
warp-cli connect
mihomo -t -f mihomo.yaml
mihomo -f mihomo.yaml
保持
40000 与当前配置一致。