Clash Verge 与 Shadowrocket 小火箭订阅导入常见问题与排错手册

在使用 Clash Verge Rev（Windows / macOS / Linux） 与 Shadowrocket（小火箭，iOS / iPadOS） 等主流客户端配置网络加速服务时，订阅导入与节点连通性排错是每一位用户都会频繁接触的核心技术环节。

许多用户在日常配置中经常会遇到以下令人头疼的典型故障：

• 复制订阅链接粘贴到客户端后，点击更新直接弹出 Network Error: fetch failed、Status 502 / 504 或 Invalid YAML format；
• 订阅明明显示导入成功，节点列表也能刷出来，但点击测速却显示 所有节点全部超时（Timeout / 9999ms），无法访问任何外部网页；
• 开启系统代理后，微信、QQ 等国内应用能正常收发消息，但浏览器打开任何网页均报错 ERR_PROXY_CONNECTION_FAILED 或 DNS_PROBE_FINISHED_NO_INTERNET；
• 开启 TUN 虚拟网卡模式时，客户端报错 Failed to start TUN interface: adapter in use，或者导致本地内网打印机与局域网共享彻底瘫痪；
• 客户端启动时提示 listen tcp 127.0.0.1:7890: bind: address already in use 端口冲突错误。

这些故障绝大多数并非服务商节点瘫痪，而是由系统时间误差（NTP 偏移）、TLS 证书校验失败、本地端口被其他进程占用、Wintun / TAP 虚拟网卡驱动冲突、Fake-IP DNS 缓存污染或 iOS 内存限制所引起的。本文将构建一套系统化的故障诊断决策树，从底层网络协议栈到操作系统内核驱动，全面剖析常见问题的成因，并提供立竿见影的实战解决步骤。

---

一、全平台客户端与订阅解析机制底层全景图

要高效排查订阅导入与节点连接故障，首先必须理清订阅链接从“远程服务器”到“本地客户端内核”的完整数据流与解析过程。

flowchart TD
    subgraph Phase1 ["第一阶段: 订阅获取与格式解析 (API / HTTP 层)"]
        A["用户填入订阅 URL"] --> B["客户端发起 HTTP/HTTPS GET 请求"]
        B --> C{"网络与 TLS 握手状态"}
        C -- NTP 时间偏差 / SSL 证书过期 --> Err1["报错: Certificate Verify Failed / Fetch Failed"]
        C -- 格式正常 (Base64 / YAML / JSON) --> D["解析为本地 Profile 配置或节点列表"]
    end

    subgraph Phase2 ["第二阶段: 节点连通与核心握手 (传输 / 内核层)"]
        D --> E["Mihomo / Xray 内核启动核心监听 (Port 7890)"]
        E --> F{"端口与虚拟网卡绑定"}
        F -- 端口 7890 被占用 --> Err2["报错: address already in use"]
        F -- TUN 驱动冲突 --> Err3["报错: Failed to start TUN interface"]
        F -- 启动正常 --> G["向目标节点发起 TCP / TLS / VLESS 握手"]
    end

    subgraph Phase3 ["第三阶段: 数据路由与 DNS 调度 (应用 / 分流层)"]
        G --> H{"健康检查与延迟探测 (generate_204)"}
        H -- 真实丢包 / 节点不可用 --> Err4["显示: Timeout / 9999ms"]
        H -- 响应正常 (返回 204 No Content) --> I["显示绿色毫秒延迟 (如 28ms)"]
        I --> J["根据 Rule 分流规则转发应用层流量"]
    end

1. 订阅协议与文件格式的本质区别

不同的客户端对订阅内容的数据格式要求存在本质差异：

• Clash / Clash Verge Rev / Mihomo：要求获取标准结构化的 YAML 格式配置文件。文件内部必须包含 proxies（节点定义）、proxy-groups（策略组逻辑）与 rules（路由分流规则）三大核心对象。若订阅链接返回的是纯 Base64 节点字符串，旧版内核在反序列化时会直接抛出 Invalid YAML format: mapping values are not allowed here；
• Shadowrocket（小火箭）：支持极具弹性的混合解析模式。它不仅能直接解析 Clash YAML，还能直接识别以 ss://、vmess://、vless://、trojan://、hysteria2:// 开头的标准 URI 节点列表，以及经过 Base64 编码的单行或多行节点文本；
• Sing-box（新一代通用格式）：采用严格结构化的 JSON 语法格式，强调零内存拷贝与轻量路由，但由于其 JSON 配置嵌套复杂，通常由服务端自动转换下发；
• SubConverter 订阅转换中间件：当客户端与服务端格式不兼容时，通常需要借助订阅转换器将通用节点列表转译为目标客户端专用的完整 YAML 文件。

2. Base64 节点 URI 编码与 YAML 序列化机制

在分布式网络加速系统中，单节点 URI 链接通常采用标准 URL Safe Base64 编码：

• 例如一个标准的 VLESS 节点链接格式为：vless://uuid@server:port?type=tcp&security=tls#NodeName；
• 订阅服务器下发纯文本时，会将数百个此类链接合并后进行全局 Base64 编码。Shadowrocket 下载该字符串后，在本地内存中逐行 Base64 解码，提取出服务器地址、端口与加密参数；
• 而 Clash Verge Rev 则需要将其映射进由 Go 语言解析器处理的 YAML 树形结构中。如果在 YAML 文件中错误使用了制表符（Tab键）而非两个半角空格（Space），或者包含了未转义的特殊字符（如冒号后未加空格），就会直接触发语法解析崩溃。

3. Mihomo（Clash.Meta）内核高级语法与 GeoData 匹配模式

作为新一代 Clash 开源内核，Mihomo 引入了大量高级网络调度特性与地理数据库解析引擎：

• geodata-mode: true 与 geosite.dat / geoip.dat：内核在启动时将二进制地理数据库加载入内存，通过构建 Trie 树索引实现高并发毫秒级域名分类匹配，大幅降低多规则匹配时的 CPU 消耗；
• unified-delay: true：统一延迟计算模型，去除底层握手额外偏差，更真实反映实际业务请求往返耗时；
• tcp-concurrent: true：针对双栈或多 IP 节点开启 TCP 并发握手，自动选择最快建立连接的 IP 通道；
• find-process-mode: strict：严格进程匹配模式，配合 TUN 虚拟网卡能够精准识别发起网络请求的本地程序名（如 chrome.exe 或 steam.exe），实现基于应用进程的智能分流；
• global-client-fingerprint: chrome：底层 uTLS 模拟真实 Chrome 浏览器的 TLS ClientHello 握手特征，有效防范 GFW 与目标网站针对代理客户端的指纹识别拦截。

---

二、订阅导入与更新失败核心成因及深度排查

订阅更新失败是新手用户遇到频率最高的首要障碍。以下是四种最底层的技术诱因与排查逻辑。

flowchart TD
    Start["订阅更新报错 (Network Error / Fetch Failed)"] --> Step1{"检查本地系统时间与网络"}
    Step1 -- 本地时间偏差 > 60秒 --> Fix1["同步 Windows / Mac 互联网时间 (NTP)"]
    Step1 -- 本地时间精准 --> Step2{"在浏览器中直接打开订阅链接"}
    Step2 -- 浏览器显示一串 Base64 字符或 YAML --> Fix2["客户端开启【跳过证书检查 (Allow Insecure)】"]
    Step2 -- 浏览器显示 502 / 504 / 无法访问 --> Step3{"检查是否受到本地 DNS 污染阻断"}
    Step3 -- 修改本地 DNS 为 223.5.5.5 / 119.29.29.29 --> Fix3["再次尝试更新订阅"]
    Step3 -- 域名被阻断 --> Fix4["使用飞鸟云用户中心提供的备用订阅分发域名"]

1. 系统时间误差（NTP 偏移）引发的 TLS 握手拒绝

现代 HTTPS 加密通信对客户端与服务端的时间同步有着极其严苛的要求。

• 底层机制：SSL/TLS 证书在签名时具有严格的有效起始时间（Not Before）与失效时间（Not After）。如果 Windows 电脑的主板电池老化、长期离线导致系统本地时间比标准北京时间快或慢了 60 秒以上，客户端在与订阅服务器进行 TLS 握手时，安全协议栈会直接判定“证书尚未生效”或“证书已过期”，从而在传输层主动掐断连接，报错 SSL Handshake Failed 或 Certificate validation failed；
• 解决验证：在 Windows【设置】->【时间和语言】-> 点击【立即同步】；在 macOS【系统设置】->【通用】->【日期与时间】中勾选【自动设置时间】。

2. 企业级内网 DPI 审查与 SSL Pinning 证书劫持

在企业办公网络或高校校园网环境下，网关可能部署了深信服（Sangfor）或奇安信等安全审计设备，对 HTTPS 流量执行自签名证书解密审计：

• 故障特征：客户端在拉取订阅时报错 x509: certificate signed by unknown authority；
• 解决对策：在订阅配置中临时勾选【跳过证书验证（Skip Cert Verify / Allow Insecure）】，或在手机上使用 4G/5G 蜂窝数据热点完成初次订阅导入。

3. HTTP 响应状态码深度解读与对应排障

当客户端尝试通过 HTTP GET 请求获取订阅时，返回的状态码直接揭示了故障发生的层级：

• HTTP 401 / 403 Forbidden：订阅密钥 Token 错误、用户套餐已到期或流量配额已被耗尽。此时应登录飞鸟云控制台检查套餐状态并重新复制最新链接；
• HTTP 502 Bad Gateway：通常代表服务端的订阅转换中间件（SubConverter）进程发生异常崩溃或内存溢出，无法连接后端节点数据库；
• HTTP 504 Gateway Timeout：网关在等待上游服务器响应时发生超时，通常由于订阅分发服务器遭遇网络拥塞或 DNS 解析缓慢导致。

4. User-Agent 请求头识别过滤机制

部分企业级订阅服务器为了防止爬虫恶意抓取，会对 HTTP 请求头中的 User-Agent 进行白名单校验：

• 如果使用通用下载工具（如迅雷或未设置 UA 的 cURL）直接请求，服务器会返回 403 阻断；
• Clash Verge Rev 与 Shadowrocket 会在发包时自动附带专属的标识头（如 ClashMeta/1.18.0 或 Shadowrocket/2.2.0），确保安全下发。

5. 本地 DNS 污染与订阅域名解析失败

部分地区的本地运营商（ISP）会将知名网络服务的分发域名解析至虚假的国内 IP 地址。

• 排查方法：在终端执行 ping sub.domain.com，若返回的 IP 地址为 127.0.0.1、0.0.0.0 或某个未知的国内骨干节点，证明订阅域名遭遇了本地 DNS 投毒；
• 解决对策：将本地网卡的 DNS 手动修改为国内公共防污染 DNS（阿里 DNS 223.5.5.5、腾讯 DNS 119.29.29.29），或在飞鸟云官网用户后台获取抗污染的专用备用订阅链接。

---

三、节点测速全部超时（Timeout / 9999ms）全链路深度诊断

很多用户在成功下载节点列表后，点击“延迟测试”却发现全线节点一片飘红、全部显示 Timeout，即便切换了多个国家也无法恢复。请按照以下“由浅入深”的顺序逐一排查。

1. 延迟测速机制的本质：为什么测速地址至关重要？

Clash Verge Rev 与 Shadowrocket 在进行延迟测试时，并不是向目标节点发送简单的 ICMP ping，而是通过代理节点向预设的 健康检查 URL（Health Check URL） 发起一个真实的 HTTP GET 请求，并统计从发送请求到收到响应头的时间差。

• 默认测速 URL 的失效风险：若客户端默认配置的测速地址为 http://www.google.com/generate_204，当节点尚未连通或目标策略组存在阻断时，测速就会失败；若部分第三方测速地址失效或被墙，就会造成“节点实际可用但测速显示超时”的假象；
• 工业级优化方案：建议将测速 URL 修改为全球 Anycast 高可用地址：http://www.gstatic.com/generate_204 或 http://cp.cloudflare.com/generate_204。

2. 代理自循环死锁（Proxy Loop）引发的全部超时

这是复杂网络环境下极易发生的逻辑死锁：

• 成因机制：如果用户在分流规则（Rules）中，错误地将订阅分发域名或代理节点本身的服务器域名（如 hk01.feiniaoyuntizi.my）匹配进了代理规则组，客户端为了连接节点，会尝试通过该节点自身去解析并连接该域名，从而陷入无限自循环递归死锁。此时所有向外发起的探测请求均被卡死在本地，表现为节点全线超时且 CPU 占用率飙升至 100%；
• 解决对策：检查配置中的 rules，确保节点服务器域名或 IP 被设置为 DIRECT（直连），或者由本地 DNS 独立解析。

3. TCP 保活探测（Keep-Alive）与连接复用机制

Mihomo 内核在建立节点隧道时，会维护底层 TCP 连接池。当长连接遭遇运营商 NAT 网关老化超时（通常为 60 秒至 120 秒）时，若客户端未发送保活心跳，隧道会静默失效。在配置中显式开启 keep-alive-interval: 30 能够有效防止节点因空闲被网关阻断。

4. 本地防火墙或第三方杀毒软件的主动拦截

在 Windows 系统中，火绒安全、360 安全卫士或 Windows Defender 可能会在后台将 verge-mihomo.exe 或 clash-meta.exe 内核进程的对外入站/出站网络连接静默拦截。

• 排查操作：进入 Windows【高级安全 Windows Defender 防火墙】->【出站规则】与【入站规则】，检查是否存在针对 Clash Verge 相关进程的阻止规则；如有，请一键删除并添加信任白名单。

5. 命令行直接探测节点物理端口连通性

当测速全部超时时，可以通过命令行绕过客户端图形界面，直接探测节点服务器的物理端口是否开放：

# 在 Windows PowerShell 中直接探测飞鸟云节点服务器的 TCP 443 业务端口
Test-NetConnection -ComputerName hk01.feiniaoyuntizi.my -Port 443

# 输出判定:
# TcpTestSucceeded : True (代表物理网络通畅，问题必定出在客户端本地配置或加密证书上)
# TcpTestSucceeded : False (代表本地运营商网络对该节点入口发生物理阻断)

---

四、TUN 虚拟网卡模式与 Fake-IP DNS 深度解析与冲突排除

理解“系统代理（System Proxy）”与“TUN 虚拟网卡模式（TUN Mode）”的本质差异，以及 Fake-IP DNS 的工作机制，是解决各类复杂网络疑难杂症的关键所在。

flowchart TD
    subgraph FakeIP_Flow ["Fake-IP DNS 解析与数据转发全流程"]
        App["应用程序发起查询 (如 www.google.com)"] --> DNS["Mihomo 本地 DNS 模块 (127.0.0.1:1053)"]
        DNS --> Pool["Fake-IP 内存映射池 (198.18.0.0/16)"]
        Pool --> Synth["毫秒级返回虚拟 IP (如 198.18.0.25)"]
        Synth --> App
        App --> TCP["向 198.18.0.25 发起 TCP 连接"]
        TCP --> TUN["TUN 虚拟网卡捕获数据包"]
        TUN --> Match["Mihomo 查表还原域名为 www.google.com"]
        Match --> Proxy["加密封装发往 IEPL 专线出口"]
    end

1. Fake-IP 与 Redir-Host 模式的本质区别

• 传统 Redir-Host 模式：客户端在建立连接前必须先向远程服务器进行真实的 DNS 查询，不仅增加了一个完整的 DNS 往返时延（RTT），而且极易遭到本地运营商的 DNS 污染；
• 现代 Fake-IP 模式：Mihomo 内核在收到应用层 DNS 查询请求时，直接在 1 毫秒内从预设的 198.18.0.1/16 保留地址池中分配一个虚拟 IP 返回给应用程序。当应用程序向该虚拟 IP 发起 TCP 连接时，内核在底层将虚拟 IP 反查还原为真实域名并直接交给专线出口进行远端解析。这种设计彻底消除了本地 DNS 延迟与污染风险。

对比维度	系统代理模式 (System Proxy)	TUN 虚拟网卡模式 (TUN Mode)
工作层级	OSI Layer 7 (应用层 HTTP/SOCKS 代理)	OSI Layer 3 (网络层 IP 报文接管)
流量接管范围	仅接管主动遵循系统代理设置的浏览器及部分应用	强行接管操作系统全部 TCP / UDP / ICMP 流量
对非代理软件支持	❌ 无法接管命令行终端、Git、外服游戏、Docker	✅ 完美接管所有游戏、终端、IDE、后台服务
WebRTC 真实 IP 防泄漏	⚠️ 存在较高泄漏风险 (STUN 可绕过系统代理)	✅ 100% 免疫泄漏 (内核层接管全部 UDP 探测)
系统资源消耗	极低 (纯轻量级端口转发)	稍高 (需运行虚拟网卡内核路由调度)
典型故障场景	浏览器能上网但终端命令行无法使用	与 VMware / VirtualBox 虚拟网卡发生路由冲突

flowchart LR
    subgraph ModeA ["1. 系统代理模式 (System Proxy: 仅接管支持代理的浏览器)"]
        Browser["Chrome / Edge 浏览器"] -->|读取系统 127.0.0.1:7890 设置| CoreA["Clash 内核"]
        Game["外服电竞 / Git / 终端命令行"] -->|完全无视系统代理，直连本地网卡| Leak["暴露真实 IP / 连接被墙阻断"]
    end

    subgraph ModeB ["2. TUN 虚拟网卡模式 (TUN Mode: 系统内核级全量接管)"]
        AllApp["全部软件: 浏览器 + 终端 + 游戏 + Docker"] -->|操作系统底层路由重定向| Wintun["Wintun / utun 虚拟网卡驱动"]
        Wintun --> CoreB["Clash Verge Rev / Mihomo 内核"]
        CoreB --> Route["根据 Rule 规则分流 / 0 丢包专线出口"]
    end

2. Windows Wintun 驱动冲突与修复

在开启 TUN 模式时，Clash Verge Rev 会在系统内部创建一个名为 Mihomo 的虚拟网络适配器。

• 冲突成因：如果用户电脑上此前安装过旧版 Clash for Windows（CFW）、WireGuard、ZeroTier、Tailscale 或虚拟机软件（VMware / VirtualBox），残留的旧版 TAP-Windows 驱动或损坏的 Wintun.dll 文件会导致内核无法分配 IP 地址，报错 wintun create adapter failed；
• 彻底清理与重置方案：
  1. 打开 Windows【设备管理器】-> 展开【网络适配器】；
  2. 找到所有带有 TAP-Windows Adapter、Wintun 或 Clash 字样的虚拟网卡，右键选择【卸载设备】；
  3. 在 Clash Verge Rev【设置】->【服务模式】中，点击【卸载服务】，随后重新点击【安装服务】；
  4. 重启计算机后重新开启 TUN 模式即可完美恢复。

3. MTU 尺寸与分片优化（MSS Clamping）

在开启 TUN 模式时，虚拟网卡的 MTU（最大传输单元）配置对网络吞吐量具有决定性影响：

• MTU 冲突成因：如果本地物理宽带（如 PPPoE 拨号）的 MTU 为 1492，而 TUN 网卡的 MTU 默认被设为 1500，会导致发送的大数据包在网络层被强制分片（Fragmentation），引发部分网页加载缓慢或游戏丢包；
• 黄金配置：在 Mihomo 配置中将 TUN 网卡的 mtu 显式指定为 1400 或 1420，并开启 auto-detect-interface: true，确保全平台数据包无损直通。

4. 局域网内网穿透与游戏下载白名单配置

在 TUN 模式下，部分本地直连服务（如局域网打印机、NAS 共享、Steam 本地局域网传输）可能会被误吸入 TUN 网卡导致断连。

• 优化对策：在配置文件的 dns.fake-ip-filter 列表中加入局域网与游戏 CDN 过滤规则：

  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "localhost.ptlogin2.qq.com"
    - "*.steamcontent.com" # Steam 游戏下载 CDN 直连走本地宽带满速
    - "*.epicgames.com"

---

五、端口冲突（Address already in use）排查与抢占解决

当客户端在启动时弹出 listen tcp 127.0.0.1:7890: bind: address already in use 错误时，表明本机的 7890 端口已经被其他正在运行的后台软件抢先霸占。

1. Windows PowerShell 命令行定位与终止占用进程

在 Windows 搜索框输入 PowerShell，右键选择【以管理员身份运行】，依次执行以下诊断命令：

# 1. 查找霸占 7890 端口的进程 PID (Process ID)
netstat -ano | findstr ":7890"

# 2. 输出示例:
# TCP    127.0.0.1:7890         0.0.0.0:0              LISTENING       14820

# 3. 根据 PID 查询具体是哪一款软件在后台占用 (将 14820 替换为上方查询到的实际数字)
tasklist | findstr "14820"

# 4. 强制终止该占用进程 (释放端口)
taskkill /F /PID 14820

2. macOS / Linux 终端定位与释放端口命令

在 macOS Terminal 或 Linux 终端中执行以下命令：

# 1. 查看占用 7890 端口的进程与应用名称
lsof -i :7890

# 2. 输出示例:
# COMMAND   PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
# clash-cor 5824 user    3u  IPv4 0x6e789012345678      0t0  TCP localhost:7890 (LISTEN)

# 3. 强制杀死该进程释放端口
kill -9 5824

---

六、Shadowrocket 小火箭（iOS）专属故障与优化技巧

作为 iOS / iPadOS 平台最主流的网络工具，Shadowrocket（小火箭）受制于苹果 iOS 系统的沙盒机制与严格的后台内存管控，存在其特有的系统级特性。

flowchart TD
    subgraph iOS_Constraint ["iOS 系统沙盒与网络扩展 (NEPacketTunnelProvider)"]
        Sys["iOS 操作系统"] --> Limit1["严格内存配额限制: 最大 15MB (超限立即 Crash)"]
        Sys --> Limit2["后台冻结机制: 锁屏后网络扩展可能被系统挂起"]
        Sys --> Limit3["Wi-Fi / 蜂窝网络切换时的路由瞬断"]
    end

    subgraph Solutions ["小火箭生产级优化对策"]
        Limit1 --> Sol1["精简规则集: 禁用过大的第三方广告规则库"]
        Limit2 --> Sol2["开启【按需连接 (On Demand)】与心跳保活"]
        Limit3 --> Sol3["启用【本地 DNS 映射】与 Fake-IP 缓存优化"]
    end

1. 为什么后台经常断连？iOS 15MB 内存壁垒与规则瘦身

iOS 系统为所有基于 NetworkExtension 框架开发的 VPN/代理应用分配了严格的 15MB 物理内存上限。

• 内存溢出闪退原理：如果用户在 Shadowrocket 中导入了过于庞大臃肿的第三方去广告规则列表（包含数十万条正则匹配规则），当并发网络请求涌入时，小火箭扩展进程的内存占用瞬间突破 15MB 警戒线，iOS 内核会直接触发 Jetsam 机制将其无预警强制闪退杀后台，表现为手机状态栏的 VPN 小图标突然消失；
• 优化对策：在小火箭【配置】中，尽量使用轻量精简的标准分流规则，避免无意义的超大黑名单规则堆砌。

2. “按需连接（On Demand）”与自动化重连配置

为了防止锁屏休眠或从 Wi-Fi 切换至蜂窝数据时网络断开，请在 Shadowrocket 中进行如下设置：

1. 点击已连接节点右侧的 (i) 信息图标，或进入【设置】；
2. 找到 【按需连接（On Demand）】 选项并将其勾选开启；
3. 系统会在网络环境发生切换时自动在毫秒级内拉起代理隧道，实现全天候无感稳定保活。

3. HTTPS 解密（MitM）引起的证书信任异常

部分进阶用户在小火箭中开启了【HTTPS 解密】用于抓包或脚本去广告：

• 故障陷阱：如果生成了根证书但未在 iOS【设置】->【通用】->【关于本机】->【证书信任设置】中勾选“针对根证书启用完全信任”，会导致苹果 App Store 无法下载应用、iCloud 无法同步或微信图片加载失败；
• 安全忠告：普通用户强烈建议关闭 HTTPS 解密功能，保持纯净的网络代理通道即可。

---

七、生产级 Clash Verge Rev 高可用规则配置模板（YAML 规范）

以下提供一份经过实战深度调优的 Clash Verge Rev / Mihomo 生产级配置模板，内置了自动化故障转移、Fake-IP 防污染 DNS 栈与精细化分流策略：

# ==============================================================================
# 飞鸟云 高可用订阅配置标准模板 (feiniaoyuntizi.my)
# ==============================================================================

port: 7890
socks-port: 7891
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false

# TUN 虚拟网卡高可用配置 (免除系统代理配置繁琐)
tun:
  enable: true
  stack: mixed
  mtu: 1400 # 优化 MTU 规避大包分片丢失
  dns-hijack:
    - "tcp://any:53"
    - "udp://any:53"
  auto-route: true
  auto-detect-interface: true

# 本地 Fake-IP 防污染 DNS 调度
dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "*.steamcontent.com"

# 策略组编排 (Proxy Groups)
proxy-groups:
  # 1. 主路由自动优选
  - name: 🚀 默认代理
    type: select
    proxies:
      - ⚡ 自动优选专线
      - 🇭🇰 香港 IEPL 01 - 2.5G
      - 🇯🇵 日本 IEPL 01 - 2.5G
      - 🇸🇬 新加坡 IEPL 01 - 2.5G
      - 🇺🇸 美国 IEPL 01 - 原生住宅IP

  # 2. 自动化延迟测速组
  - name: ⚡ 自动优选专线
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies:
      - 🇭🇰 香港 IEPL 01 - 2.5G
      - 🇯🇵 日本 IEPL 01 - 2.5G
      - 🇸🇬 新加坡 IEPL 01 - 2.5G
      - 🇺🇸 美国 IEPL 01 - 原生住宅IP

  # 3. 故障平滑降级组
  - name: 🛡️ 故障转移
    type: fallback
    url: http://www.gstatic.com/generate_204
    interval: 60
    proxies:
      - 🇭🇰 香港 IEPL 01 - 2.5G
      - 🇯🇵 日本 IEPL 01 - 2.5G
      - 🇸🇬 新加坡 IEPL 01 - 2.5G
      - 🇺🇸 美国 IEPL 01 - 原生住宅IP

# 核心路由规则链
rules:
  - DOMAIN-SUFFIX,openai.com,🚀 默认代理
  - DOMAIN-SUFFIX,claude.ai,🚀 默认代理
  - DOMAIN-SUFFIX,github.com,🚀 默认代理
  - DOMAIN-SUFFIX,youtube.com,🚀 默认代理
  - DOMAIN-SUFFIX,netflix.com,🚀 默认代理
  - GEOIP,CN,DIRECT
  - MATCH,🛡️ 故障转移

---

八、常见客户端跨平台技术选型与特性对比矩阵

为了让用户在不同操作系统上做出最优的客户端选型决策，以下表格横向对比了主流客户端的核心技术指标：

评估指标	Clash Verge Rev	Shadowrocket (小火箭)	Clash Nyanpasu	Surge (iOS/Mac)	Loon (iOS)
支持平台	Windows / macOS / Linux	iOS / iPadOS	Windows / macOS	iOS / macOS	iOS / iPadOS
底层核心	Mihomo (Clash.Meta)	自研高性能内核	Mihomo (Clash.Meta)	自研独立引擎	自研独立引擎
TUN 虚拟网卡	✅ 原生支持 (Wintun)	✅ 原生支持 (NetworkExt)	✅ 原生支持	✅ 工业级 TUN	✅ 原生支持
内存占用	约 60MB – 120MB	< 15MB (受系统限制)	约 80MB – 150MB	约 30MB – 60MB	约 20MB – 40MB
配置上手难度	⭐⭐ (开箱即用)	⭐ (极简傻瓜式)	⭐⭐ (开箱即用)	⭐⭐⭐⭐⭐ (专家级配置)	⭐⭐⭐ (中等难度)
开源状态	完全开源免费	商业闭源软件 ($2.99)	完全开源免费	商业闭源 (高价订阅)	商业闭源 ($5.99)
推荐适用人群	PC / Mac / 极客办公	iPhone / iPad 全体用户	追求现代 UI 的 PC 用户	专业网络工程师 / 开发者	喜欢折腾脚本的进阶玩家

各平台生态深度选型解析：

• 桌面端（Windows / macOS / Linux）首选 Clash Verge Rev：依托活跃的开源社区与强大的 Mihomo 内核，它不仅支持现代化的 WebUI 界面，还深度集成了内核服务模式与 Wintun 驱动，在日常使用中资源占用低、切换顺畅，是办公与开发环境的绝对主力；
• iOS 平台首选 Shadowrocket：虽然 App Store 存在 Surge、Loon、Quantumult X 等竞品，但小火箭凭借仅 $2.99 的亲民定价、对全协议格式的超强容错解析以及傻瓜式的交互设计，成为苹果移动设备上装机量最高的基础工具；
• Android 平台推荐 Clash Meta for Android / Sing-box：在安卓生态中，必须在系统设置中关闭对代理客户端的【电池激进优化（Doze Mode）】，并将应用锁定在后台运行白名单中，以防系统在锁屏时杀死 VPNService 进程。

---

九、真实高频疑难排错案例库

以下选取八个在用户日常技术支持中复现率最高的问题案例，深度还原从故障排查到彻底解决的全过程。

---

案例 1：Windows 11 更新订阅提示 “Network Error: fetch failed” 深度排查

问题现象

用户在 Windows 11 上安装 Clash Verge Rev 后，将飞鸟云订阅链接粘贴至【订阅】页面点击【导入】，界面右下角持续报错红色弹窗：Network Error: fetch failed，无法加载出任何配置。

环境信息

• 操作系统：Windows 11 23H2
• 软件版本：Clash Verge Rev 1.6.0 (Mihomo 内核)
• 本地网络：中国电信 1000M 家庭宽带

初步判断与排查路径

1. 在浏览器中直接打开该订阅链接，网页能瞬间下载包含节点信息的 YAML 文件，排除了订阅服务器故障；
2. 检查 Windows 系统的当前本地时间，发现系统时钟为 14:22:10，而标准北京时间为 14:25:35，存在 3 分 25 秒的显著 NTP 偏移；
3. 关键证据截获：由于本地时间严重滞后，系统底层安全组件在对订阅服务器的 HTTPS 证书执行时间有效性比对时直接拒绝握手，导致网络请求在传输层被斩断。

执行步骤与修复

1. 打开 Windows【设置】->【时间和语言】->【日期和时间】；
2. 确保开启【自动设置时间】，并点击【立即同步】按钮，校准系统时间至毫秒级同步；
3. 回到 Clash Verge Rev 界面，重新点击订阅旁边的【刷新】按钮。

结果验证

点击刷新后 1 秒内成功下载配置文件，节点列表全部完整呈现，延迟测试全部正常。

---

案例 2：开启系统代理后浏览器报错 “DNS_PROBE_FINISHED_NO_INTERNET”

问题现象

用户在开启 Clash Verge Rev 系统代理后，微信可以正常聊天，但 Chrome 浏览器打开 Google、百度等任何网站均报错 DNS_PROBE_FINISHED_NO_INTERNET，关闭代理后恢复正常。

环境信息

• 操作系统：Windows 10 专业版
• 浏览器：Google Chrome 122

初步判断与排查路径

1. 打开终端执行 curl -x 127.0.0.1:7890 https://www.google.com，能够正常返回网页源码，证明代理内核运行完好；
2. 检查 Chrome 浏览器内部设置，发现用户此前开启了 Chrome 自带的 【使用安全 DNS（Secure DNS / DoH）】 功能；
3. 技术机理复盘：Chrome 自带的 DoH 会绕过系统代理直接向 Google 或 Cloudflare 443 端口发送 DNS 查询，该查询在本地被运营商 GFW 阻断，导致浏览器因无法解析域名而报错。

执行步骤与修复

1. 打开 Chrome【设置】->【隐私和安全】->【安全】；
2. 找到【使用安全 DNS】，将其开关彻底关闭（由 Clash Verge Rev 的 Fake-IP DNS 统一接管全局解析）；
3. 打开命令行执行 ipconfig /flushdns 清空系统 DNS 缓存。

结果验证

重新打开 Chrome 浏览器，所有境内外网页均实现秒开，DNS 解析故障彻底排除。

---

案例 3：开启 TUN 模式报错 “Failed to start TUN interface: adapter is in use”

问题现象

用户在 Clash Verge Rev 中点击开启【TUN 模式】开关，软件弹出错误提示：Failed to start TUN interface: adapter is in use，TUN 模式无法激活。

环境信息

• 操作系统：Windows 11
• 辅助软件：电脑上同时安装了 VMware Workstation 与旧版 VPN 软件

初步判断与排查路径

1. 打开【设备管理器】->【网络适配器】，发现列表中残留了多个名为 TAP-Windows Adapter V9 与 Wintun Userspace Tunnel 的失效虚拟网卡设备；
2. 由于前次软件非正常关机，旧的虚拟网卡资源未被操作系统内核正常释放，导致 Mihomo 无法创建同名网络适配器。

执行步骤与修复

1. 在【设备管理器】中将所有残留的 TAP 与 Wintun 虚拟网卡逐一右键【卸载设备】；
2. 以管理员身份运行 PowerShell，执行以下命令重启网络核心堆栈：

   netsh winsock reset
   netsh int ip reset

3. 在 Clash Verge Rev【设置】->【服务模式】中重新安装服务并重启电脑。

结果验证

电脑重启后再次打开 Clash Verge Rev，开启 TUN 模式瞬间成功，系统托盘显示虚拟网卡正常运行。

---

案例 4：Shadowrocket 小火箭导入订阅后节点列表全空

问题现象

用户在 iPhone 上的 Shadowrocket 中点击右上角 + 号添加订阅 URL，保存后返回首页，节点列表空空如也，没有任何节点显示。

环境信息

• 设备：iPhone 14 Pro (iOS 17.4)
• 软件：Shadowrocket 最新官方正版

初步判断与排查路径

1. 进入 Shadowrocket【配置】页面，发现当前的默认配置被误设为不可用的本地空白文件；
2. 检查订阅添加方式，发现用户在添加订阅时将【类型（Type）】误选为了 Shadowsocks 单节点，而非 Subscribe（订阅） 模式。

执行步骤与修复

1. 打开 Shadowrocket 首页，向左滑动删除刚刚添加的错误条目；
2. 点击右上角 + 号，在第一行【类型】中务必选择 【Subscribe】；
3. 在【URL】一栏重新粘贴飞鸟云订阅链接，点击右上角【保存】；
4. 首页下拉列表，手动执行一次强制同步更新。

结果验证

首页瞬间加载出包括香港、台湾、日本、新加坡、美国在内的全系 IEPL 专线节点列表，测速全部通畅。

---

案例 5：电脑关机重启后无法上网（必须打开代理软件才能上网）

问题现象

用户在关闭 Clash Verge Rev 并关机后，第二天开机发现电脑彻底断网，无法打开任何网页；只有重新打开 Clash 软件并连接后才能正常上网。

环境信息

• 操作系统：Windows 11
• 客户端：Clash Verge Rev

初步判断与排查路径

1. 打开 Windows【设置】->【网络和 Internet】->【代理】；
2. 发现【使用代理服务器】开关处于开启状态，且代理 IP 设置为 127.0.0.1:7890；
3. 技术机理复盘：用户在电脑关机前未正常关闭客户端的【系统代理】开关，直接强行关机或软件崩溃，导致操作系统注册表中的代理设置未能及时复原。开机后，由于后台没有代理软件监听 7890 端口，浏览器发出的所有请求均被丢入死循环。

执行步骤与修复

1. 打开 Windows 代理设置页面，手动将【使用代理服务器】开关关闭并保存；
2. 为了从根本上杜绝该问题，在 Clash Verge Rev【设置】中勾选 【退出时自动清理系统代理】；
3. 或直接开启 【TUN 模式】 代替传统的系统代理模式。

结果验证

修改后即使彻底退出 Clash 软件，本地宽带依然能正常直连上网，系统代理残留故障彻底根除。

---

案例 6：WSL2 / Docker 容器在 Windows 环境下无法通过 TUN 模式联网

问题现象

开发者在 Windows 11 上启动 WSL2（Ubuntu 22.04）或 Docker Desktop 后，宿主机开启 Clash Verge Rev TUN 模式可以正常加速，但 WSL2 终端执行 curl https://google.com 或 docker pull 持续报错 Connection timed out。

环境信息

• 操作系统：Windows 11 专业版
• 虚拟化环境：WSL2 + Docker Desktop 4.28

初步判断与排查路径

1. WSL2 默认采用 Hyper-V 内部 NAT 虚拟交换机，具有独立的虚拟网卡与 IP 子网；
2. Wintun 虚拟网卡在接管流量时，未将 Hyper-V 虚拟子网的路由包纳入自动路由表。

执行步骤与修复

1. 在 Windows 用户主目录（C:\Users\<YourUsername>\）下新建或编辑 .wslconfig 配置文件；
2. 写入以下镜像网络配置启用原生镜像模式：

   [wsl2]
   networkingMode=mirrored
   dnsTunneling=true
   firewall=true
   autoProxy=true

3. 在 PowerShell 中执行 wsl --shutdown 重启 WSL2 虚拟机。

结果验证

重启 WSL2 后，Ubuntu 终端与 Docker 容器自动无缝继承宿主机 Clash Verge Rev 的 TUN 专线加速，docker pull 速度拉满至千兆。

---

案例 7：开发者工具 Git / npm / pip 报错 “Proxy CONNECT aborted”

问题现象

程序员在终端执行 git clone https://github.com/... 或 npm install 时，即便开启了系统代理，终端依然报错 Failed to connect to github.com port 443: Connection refused 或 Proxy CONNECT aborted。

环境信息

• 操作系统：macOS Sonoma / Windows 11
• 开发工具：Git 2.43 + Node.js 20

初步判断与排查路径

1. 终端命令行工具默认完全不读取 Windows/macOS 系统的图形化代理设置；
2. 用户此前在 Git 配置文件中硬编码了失效的旧代理端口（如 http.proxy=http://127.0.0.1:1080），与当前 Clash 的 7890 端口冲突。

执行步骤与修复

1. 在终端中重置并指定正确的局部代理端口：

   # 为 Git 显式指定 Clash 本地监听端口
   git config --global http.proxy http://127.0.0.1:7890
   git config --global https.proxy http://127.0.0.1:7890
   
   # 或在当前终端 Shell 会话中注入环境变量
   export http_proxy="http://127.0.0.1:7890"
   export https_proxy="http://127.0.0.1:7890"
   export all_proxy="socks5://127.0.0.1:7890"

2. 或在 Clash Verge Rev 中直接开启 【TUN 虚拟网卡模式】（无需对任何终端工具单独配置，全局自动无感接管）。

结果验证

执行 git clone 速度瞬间拉升至 30MB/s，GitHub 仓库毫秒级克隆完毕。

---

案例 8：Telegram 电脑客户端持续显示 “Connecting…” 卡死

问题现象

用户在电脑上打开 Telegram Desktop，浏览器访问网页一切正常，但 Telegram 左下角一直显示 Connecting...（连接中），消息无法收发。

环境信息

• 操作系统：Windows 11
• 客户端：Telegram Desktop 4.14
• 代理模式：系统代理模式（未开 TUN）

初步判断与排查路径

1. Telegram 属于使用私有 MTProto 协议的独立客户端，默认情况下不遵循 Windows 操作系统的系统代理；
2. 用户未在 Telegram 内置网络设置中手动指定代理端口。

执行步骤与修复

1. 打开 Telegram【Settings】->【Advanced】->【Connection type】；
2. 选择【Use custom proxy】-> 点击【Add proxy】；
3. 选择 【SOCKS5】 或 【HTTP】，主机填入 127.0.0.1，端口填入 7890，点击【Save】；
4. 或直接在 Clash Verge Rev 中开启 【TUN 模式】。

结果验证

设置完成后 Telegram 状态瞬间变为 Connected，频道与群聊消息秒级同步更新。

---

十、常见问题深度解答 (FAQ)

Q1：为什么导入订阅时提示 “Invalid YAML format” 或反序列化失败？

这通常是因为您复制的订阅链接不是标准 YAML 格式（例如复制成了单节点链接），或者订阅服务器在下发配置时遇到了临时网络波动返回了 HTML 错误页面。解决方法：登录飞鸟云用户中心，在仪表盘中点击【复制 Clash 订阅】，确保复制的是专为 Clash / Mihomo 定制的专用订阅链接，再粘贴至客户端更新。

Q2：节点测速时显示的毫秒延迟（如 28ms）代表实际下载速度吗？

不代表。延迟（Ping / RTT）代表的是您的设备向服务器发送探测包并收到确认的往返物理响应时间（单位为毫秒）。延迟越低代表网页打开的响应越快、游戏按键越灵敏；而实际下载大文件或看 4K 视频的快慢取决于节点的物理专线带宽大小（如飞鸟云 2.5Gbps）与丢包率（0.00%）。

Q3：Shadowrocket 小火箭提示 “VPN 无法连接或配置描述文件安装失败” 怎么解决？

在 iOS 系统中，首次启动 Shadowrocket 并开启连接时，系统会弹出权限弹窗要求添加 VPN 配置。如果用户误点了“取消”，后续将无法启动。解决方法：打开 iPhone【设置】->【通用】->【VPN 与设备管理】-> 找到 Shadowrocket 相关描述文件并删除，随后重新打开小火箭 App 重新点击连接开关，在弹出的系统提示中输入锁屏密码允许安装。

Q4：为什么开启代理后部分国内银行 App 或政务网站无法登录？

国内部分金融与政务网站部署了严格的反欺诈安全风控，会拒绝非大陆 IP 或带有代理特征的连接访问。解决方法：在客户端中务必保持开启 【规则模式（Rule）】，在本文第七章的规则链中已配置 GEOIP,CN,DIRECT，所有大陆本土网站均会自动走本地宽带直连，既不影响正常使用，又能确保安全性。

Q5：如何设置客户端让它在每天电脑开机时自动更新节点订阅？

在 Clash Verge Rev 中进入【订阅】页面，右键点击您的订阅卡片选择【编辑】，在【更新间隔】一栏中填入 1440（即每 24 小时自动更新一次）；同时在【设置】中开启【开机自启动】与【静默启动】，即可实现全自动化无感更新与运行。

Q6：全局模式（Global）与规则模式（Rule）有什么区别？日常应该用哪个？

• 全局模式（Global）：强制将电脑上的所有网络流量（包括访问百度、淘宝、微信）全部通过海外专线节点转发，极易导致国内应用变慢甚至触发安全风控；
• 规则模式（Rule - 强烈推荐）：系统根据内置的智能分流规则表进行毫秒级自动判断，海外受限网站走专线加速，国内应用走本地极速直连。日常使用强烈建议永久锁定为【规则模式】。

Q7：使用 Clash Verge Rev 会与迅雷、百度网盘等 P2P 下载软件冲突吗？

在【系统代理模式】下通常不会冲突，因为 P2P 软件默认走私有传输协议；但如果在开启【TUN 模式】时使用迅雷下载大型 BT 资源，可能会瞬间消耗大量专线套餐流量并占满连接数。建议：在进行大容量 P2P 下载时，暂时关闭代理软件或在客户端分流规则中将 BT 客户端加入白名单直连列表。

Q8：如果所有排错步骤都试过了依然无法上网，最后的终极解决手段是什么？

请按照以下“终极重置三步法”操作：

1. 重置操作系统网络堆栈：以管理员身份运行 CMD 执行 netsh winsock reset 并重启电脑；
2. 全新安装最新稳定版客户端：彻底卸载旧版软件，前往官网下载最新版 Clash Verge Rev 并重新安装；
3. 重新获取纯净订阅：登录飞鸟云控制台重新生成一份全新的订阅密钥并导入。

---

十一、总结与日常运维自检清单

面对复杂多变的网络配置问题，牢记以下四大核心排错法则与日常五步自检清单，即可在 3 分钟内化繁为简、秒级定位并消除问题根源：

1. 核心排错黄金四原则

• 先查基础环境：遇到订阅更新报错，首要检查系统时间（NTP）是否精准同步；
• 善用排除法定位：浏览器打不开网页时，先用命令行 curl 测试代理端口，快速区分是浏览器问题还是内核问题；
• 首选 TUN 模式：彻底告别系统代理与各类软件不兼容的烦恼，开启 TUN 虚拟网卡实现全局无缝接管；
• 保持规则精简：避免在手机端堆砌过于臃肿的第三方规则库，保障内存与连接稳定。

2. 日常健康维护五步自检表

• 第 1 步：核验订阅周期：每周检查一次订阅流量剩余额度与有效期限，避免套餐欠费中断业务；
• 第 2 步：定期更新内核与 GeoIP 库：在客户端设置中每月点击一次规则数据库更新，获取最新的国内外域名 IP 归属划分；
• 第 3 步：保持单一代理软件运行：严禁在同一台电脑上同时启动多款 VPN 或代理工具，防止虚拟网卡抢占导致死锁；
• 第 4 步：退出前还原系统代理：若不使用 TUN 模式，在关闭客户端前务必先在托盘菜单中关闭系统代理开关；
• 第 5 步：优选企业级高速 IEPL 专线：从底层选用骨干内网专线节点，彻底杜绝公网中继晚高峰的丢包拥塞困扰。

立即前往飞鸟云用户中心开通企业级 IEPL 专线 | 查看全平台客户端快速上手教程