客户现场有一套自建的 Kafka，用 Docker Swarm 部署，单节点 KRaft 模式，全公司好几个业务系统都挂在上面收发消息。某天接到反馈：有一个应用一直连不上 Kafka，其他应用全都好好的。

这种”别人都没事，就它不行”的故障是最容易把人带沟里的。第一反应几乎必然是——是不是这个应用自己的配置写错了？是不是它跑的那台机器网络有问题？

最后的结论确实和 Kafka 配置有关，但根因不在那个应用身上，也不在其他任何一个应用身上，而在一个大多数人都配过、却很少有人真正理解其语义的参数：KAFKA_ADVERTISED_LISTENERS。

更准确地说：这个参数配错的故障表现，天生就是”选择性的“——它不会打死所有人，只会打死那些网络路径和它不匹配的客户端。这也正是它最迷惑人的地方。

一、故障现象

先交代一下环境拓扑，这是后面所有推理的基础：

• Kafka 跑在客户的 Swarm 集群里，通过一个统一的对外入口访问，下文把这个入口的域名脱敏为 pfscene.example.com（真实域名保留在客户环境里）。
• 大部分业务应用部署在内网，和 Kafka 处在可以互通的网段。
• 出问题的那个应用部署在另外一台独立机器上，它连不到 Kafka 的内网地址，只能走 pfscene.example.com 这个对外入口。

故障表现的形态很典型。应用启动之后日志里反复刷：

1
2
3

[Producer clientId=producer-1] Connection to node 1 (192.168.0.196/192.168.0.196:9092) could not be established. Broker may not be available.
...
org.apache.kafka.common.errors.TimeoutException: Topic order-events not present in metadata after 60000 ms.

Python 客户端那边是另一个长相，但本质一样：

1
2
3

kafka.errors.NoBrokersAvailable: NoBrokersAvailable
# 或者卡很久之后
kafka.errors.KafkaTimeoutError: KafkaTimeoutError: Failed to update metadata after 60.0 secs

这里有个细节值得先圈出来：报错里的地址是 192.168.0.196:9092，一个内网地址。而那个应用配置里写的连接地址明明是 pfscene.example.com。它从来没主动连过 192.168.0.196，这个地址是Kafka 主动告诉它的。

当时没人注意到这个细节，包括我在内。

二、第一轮排查：先证明它到底能不能连上

面对”连不上”的报障，第一步永远是把”连不上”这三个字拆开——是网络层不通，还是连上了但用不了？这两者的排查方向完全相反。

先从那台故障机器上做最朴素的端口探测：

1
2

# 从故障机器探测对外入口，看四层是否可达
nc -zv pfscene.example.com 19092

结果：通。

再让用户确认防火墙、安全组、出网策略，也都没有拦。也就是说：

网络是通的，应用能建立到 Kafka 的 TCP 连接，但它依然起不来。

这一步排除掉了一大半可能性（路由、ACL、防火墙、DNS 解析失败），同时把问题压缩到了一个很窄的范围里：连接建立得起来，但会话建立不起来。在 Kafka 的语境下，这几乎等价于一句话——客户端拿到的集群信息是错的。

同时，另一个事实也在反复敲打我们：其他应用全都正常。如果 Kafka 本身配置有问题，为什么它们没事？

说实话，到这里我的直觉也是偏向”那个应用自己的问题”——毕竟其他应用都正常这个反证太强了。这恰恰是这次排查里最大的思维陷阱：”其他人都正常”只能证明故障不是全局的，不能证明故障不在被怀疑的服务端。

三、关键一击：让 Kafka 自己交代它广播了什么

既然是”连上了但用不了”，那就要看客户端在握手之后拿到了什么。Kafka 的元数据是可以用命令行直接问出来的，这也是这次排查里最快的一击：

1
2

# 站在故障机器的视角，向对外入口要一份集群元数据
kcat -b pfscene.example.com:19092 -L

输出大意如下（已脱敏）：

1
2
3
4

Metadata for all topics (from broker -1: pfscene.example.com:19092/bootstrap):
 1 brokers:
  broker 1 at 192.168.0.196:9092 (controller)
 0 topics:

真相就在这里，一行字：

• from broker -1: pfscene.example.com:19092/bootstrap——这一行是我主动连的地址，也就是 bootstrap 地址，Kafka 标记为 broker -1，意思是”还没分配身份的入口”。
• broker 1 at 192.168.0.196:9092——这一行是 Kafka 告诉我”你应该来这儿找我” 的地址。

于是整个故障链条一下子闭合了：

1. 应用连 pfscene.example.com:19092 → 成功（所以 nc 是通的）。
2. Kafka 回了一句”我这个 broker 在 192.168.0.196:9092“。
3. 应用老老实实去连 192.168.0.196:9092 → 那台独立机器根本不在这个内网里，路由不可达 → 超时、重试、再超时。

补一刀验证这个推断：

1
2
3

# 从故障机器分别探测两个地址，对比结果
nc -zv pfscene.example.com 19092   # 通
nc -zv 192.168.0.196 9092          # 超时

再回到 broker 侧确认配置本身：

1
2
3
4
5

# Swarm 下容器名形如 <stack>_kafka.1.<hash>，没有固定名字，按服务名过滤取容器
docker exec "$(docker ps -q -f name=kafka | head -n1)" env | grep -i ADVERTISED

# 输出：
# KAFKA_ADVERTISED_LISTENERS=PLAINTEXT://192.168.0.196:9092

现场的 compose 片段（缩进已整理）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

services:
  kafka:
    image: apache/kafka:4.1.1
    container_name: broker
    environment:
      # broker 实际监听的地址：0.0.0.0:9092，容器内外都能进来
      KAFKA_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093
      # ↓↓↓ 问题就在这一行：广播出去的是宿主机内网 IP
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://192.168.0.196:9092
      KAFKA_CONTROLLER_QUORUM_VOTERS: 1@kafka:9093
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: broker,controller
      KAFKA_CONTROLLER_LISTENER_NAMES: CONTROLLER
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: CONTROLLER:PLAINTEXT,PLAINTEXT:PLAINTEXT
    ports:
      - target: 9092
        published: 9092
        protocol: tcp
        mode: host
    networks:
      - net

KAFKA_LISTENERS 里写 PLAINTEXT://:9092（即绑 0.0.0.0:9092）不是问题的根源——它决定了 broker 在哪张网卡上接客，是服务端视角的配置。真正捅娄子的是 KAFKA_ADVERTISED_LISTENERS，它是客户端视角的配置，含义是：

“客户端你好，请你用这个地址回来找我。”

而这个地址，被硬编码成了一个外部客户端永远够不着的内网 IP。

四、原理：bootstrap 只是”敲门砖”

如果要问 Kafka 网络配置里最容易踩、后果最隐蔽的一个坑是什么，我会毫不犹豫投给 advertised.listeners。它隐蔽的根本原因在于：Kafka 客户端不是只连一个地址，而是连两次。

一次完整的客户端接入过程是这样的：

1
2
3
4
5
6
7
8

外部应用                    pfscene 入口              Kafka Broker
   |                            |                        |
   |--- ① 用 bootstrap 连接 --->|--- 转发 -------------> |   成功（所以 nc 通）
   |                            |                        |
   |<-- ② Metadata 响应：      --------------------------|   返回「我在
   |     "broker 1 在 192.168.0.196:9092"                |    192.168.0.196:9092」
   |                            |                        |
   |--- ③ 改用 ② 给出的地址直连 -----------------------✗ |   路由不可达 → 超时

• 第一阶段（bootstrap）：客户端拿 bootstrap.servers 里的地址，随便挑一个连上去。这个地址的作用仅仅是敲门——它只要能带着客户端进入集群即可，可以是任何一个 broker。
• 第二阶段（metadata）：连上之后客户端会请求一份集群元数据。broker 在响应里给出”分区 leader 在哪台 broker 上”，而这些 broker 的地址，就是它们各自 advertised.listeners 里配的值，由 broker 原样广播出去。
• 第三阶段（真正干活）：客户端丢弃 bootstrap 地址，改用 metadata 里返回的地址去连真正的 leader 收发消息。

关键点在于：Kafka 完全不关心它广播出去的地址对客户端是否可达。 它只是如实转述配置里写的东西。地址能不能通，是配置者的责任。

所以现场的现象不是巧合，而是必然：

这张表就是”其他应用都正常、只有它不行”的全部答案：同一个 broker、同一份配置，对不同网络路径的客户端产生了不同的结果。advertised 配错的故障面不是”全体下线”，而是”走到不可达路径的那部分客户端”——这就是它被称为选择性故障的原因。

顺带说一句，如果 advertised.listeners 干脆不配会怎样？Kafka 会退而使用 listeners 的值；而如果 listeners 里的 host 部分留空（就像上面那样写成 PLAINTEXT://:9092），Kafka 会拿 java.net.InetAddress.getCanonicalHostName() 去猜——在容器里通常得到的是容器主机名或容器 IP，那是一个比内网 IP 更不可达的地址。所以这个参数不但要配，还必须配对。

五、为什么”把那一行改掉”不是正确答案

知道了根因，最直觉的修复是：把广播地址改成对外入口不就行了？

1
2

# 看似能治病的改法
KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://pfscene.example.com:19092

这个改法确实能让那台独立机器连上。但它会顺手打死另一批客户端。

别忘了，同一套服务里还躺着一个内部组件——Kafdrop（Kafka 的 Web 管理界面），它就在同一个 Swarm 网络里：

1
2
3
4

kafdrop:
  image: obsidiandynamics/kafdrop:latest
  environment:
    KAFKA_BROKERCONNECT: "kafka:9092"   # 它走的是内部服务名

改完之后会发生什么？

1. Kafdrop 用 kafka:9092 做 bootstrap → 依然连得上。
2. broker 回它一句”broker 1 在 pfscene.example.com:19092“。
3. Kafdrop 转身去连 pfscene.example.com → 如果容器内的 DNS 解析不到这个名字，或者解析出来但回程路由不通（对外入口多半做了 NAT 甚至反向代理），它照样挂。

于是就成了按下葫芦浮起瓢：修好了外部的，打死了内部的。

问题的本质在于：advertised.listeners 是按 listener 广播的，而当时只有一个 listener，所以全天下所有客户端只能听到同一个地址。可现实里客户端来自两条不同的网络路径，一条走内部服务名，一条走对外入口。一个地址伺候不了两条路径。

六、正确解法：拆成内、外两个 listener

Kafka 早就为这种场景准备好了机制——多 listener：broker 在不同网卡/端口上监听，并针对每类客户端广播各自可达的地址。

改造后的完整 compose（Swarm stack 文件，可直接 docker stack deploy）：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76

version: '3.8'

services:
  kafka:
    image: apache/kafka:4.1.1
    container_name: broker          # 注：Swarm 模式下该字段不生效，容器名形如 <stack>_kafka.1.<hash>
    environment:
      # ---------- 监听器：内部 9092 / 外部 19092 / controller 9093 ----------
      KAFKA_LISTENERS: INTERNAL://:9092,EXTERNAL://:19092,CONTROLLER://:9093

      # ---------- 广播地址：每类客户端只听到自己那条路径上可达的地址 ----------
      # INTERNAL 用 Swarm 服务名，不写死宿主机 IP，换节点/换机器都不用改配置
      # EXTERNAL 用对外入口的域名和端口
      KAFKA_ADVERTISED_LISTENERS: INTERNAL://kafka:9092,EXTERNAL://pfscene.example.com:19092

      # 所有 listener 都必须在这里登记，漏一个 broker 就起不来
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: INTERNAL:PLAINTEXT,EXTERNAL:PLAINTEXT,CONTROLLER:PLAINTEXT

      # 多 listener 场景必须显式指定集群内部走哪个 listener，否则启动即报配置异常
      KAFKA_INTER_BROKER_LISTENER_NAME: INTERNAL

      # ---------- KRaft 单节点 ----------
      KAFKA_NODE_ID: 1
      KAFKA_PROCESS_ROLES: broker,controller
      KAFKA_CONTROLLER_LISTENER_NAMES: CONTROLLER
      KAFKA_CONTROLLER_QUORUM_VOTERS: 1@kafka:9093

      # ---------- 单副本兜底 ----------
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_REPLICATION_FACTOR: 1
      KAFKA_TRANSACTION_STATE_LOG_MIN_ISR: 1
      KAFKA_GROUP_INITIAL_REBALANCE_DELAY_MS: 0
      KAFKA_NUM_PARTITIONS: 1

    ports:
      # 内部端口：主要是给宿主机侧的 kcat / nc 排查用，不需要对外暴露
      - target: 9092
        published: 9092
        protocol: tcp
        mode: host
      # 外部端口：pfscene 入口最终要指向这里
      - target: 19092
        published: 19092
        protocol: tcp
        mode: host

    deploy:
      replicas: 1
      restart_policy:
        condition: on-failure

    networks:
      - net

  # 内部客户端的代表：它连 kafka:9092，拿到的也必须是内部可达的地址
  kafdrop:
    image: obsidiandynamics/kafdrop:latest
    container_name: kafdrop
    environment:
      KAFKA_BROKERCONNECT: "kafka:9092"
      JVM_OPTS: "-Xms256M -Xmx1024M"
      SERVER_PORT: 9000
    ports:
      - target: 9000
        published: 19000
        protocol: tcp
        mode: host
    depends_on:
      - kafka          # 注：Swarm 模式下 depends_on 同样不生效，这里只表达启动顺序意图
    networks:
      - net

networks:
  net:
    external:
      name: sf_net

和现场原配置逐项对比，实质改动其实只有四处：

其余（KRaft 单节点、副本因子、mode: host、外部网络 sf_net）都保持原样。顺带说明两处”看着像配置、实际不生效”的字段：container_name 和 depends_on 在 Swarm 模式下都会被忽略，前者由 <stack>_<service>.<序号>.<hash> 规则生成容器名，后者只剩语义表达——它们不影响功能，但排查时别拿容器名去 docker exec（下一节验证时会用到这一点）。

几个容易忽略的细节：

• KAFKA_INTER_BROKER_LISTENER_NAME 不能省。 单 listener 时它无所谓，一旦配了多个 listener，broker 就不知道集群内部通信该走哪一个，启动时会直接抛配置异常。这里指定 INTERNAL，因为 broker 之间（当前是单节点自连）走内部网络最稳。
• advertised 的端口允许和实际监听端口不一致。 上面 EXTERNAL://pfscene.example.com:19092 里的 19092 是”告诉客户端来连这个端口”，broker 自身则在 EXTERNAL://:19092 上监听。这是网关/NAT 场景下的合法用法（早年很多”端口映射后客户端连不上”的问题，根源就在于此）——代价是所有外部客户端都必须真的能从那个地址和端口进来。
• 内部地址用服务名而不是宿主内网 IP。 原来写 192.168.0.196 的问题是：集群迁到别的节点、宿主机换 IP，配置全废。改成 Swarm 服务名 kafka:9092 之后，内部客户端解析的是集群 DNS，跟宿主机 IP 解耦。
• mode: host 发布端口时，端口落在运行容器的那个节点上，不经过 Swarm 的 routing mesh。所以 pfscene 入口必须指向实际跑着 broker 的那个节点，别指望随便指一个节点都能转发。

改完 advertised.listeners 属于静态配置，必须重启 broker 才生效，不能靠动态配置下发：

1
2

# 滚动重启该服务（单副本，会有秒级中断）
docker service update --force <stack>_kafka

七、验证：用两个视角各问一次

修复之后不要急着宣告成功，用同一个命令从两条路径分别验证一次，比什么都直观：

1
2
3
4
5
6
7

# 视角一：内部（在 Swarm 网络内的任意容器里执行）
kcat -b kafka:9092 -L
# 期望看到：broker 1 at kafka:9092

# 视角二：外部（在故障机器上执行）
kcat -b pfscene.example.com:19092 -L
# 期望看到：broker 1 at pfscene.example.com:19092

这里有一条可以刻进肌肉记忆的判据：

kcat -L 输出里 broker N at ... 那一行的地址，必须和你的 bootstrap 地址属于同一条可达路径。
如果两者一个是内网 IP、一个是对外域名，那这个客户端迟早要出事——出事的时刻，就是它真正开始收发消息的时候。

顺带提醒两个行为：

• 修改生效后，客户端可能还抱着旧的 metadata 缓存不放。Java 客户端的 metadata.max.age.ms 默认 5 分钟，急的话直接重启客户端验证。
• 如果客户端报的是 Topic xxx not present in metadata，别急着去查 topic 存不存在。这个报错的真实含义往往是”我连不上任何 leader”，元数据获取失败和 topic 不存在，在这里是同一个症状。

八、经验固化

这次故障的技术含量其实不高，但很值得记下来，因为它踩中了好几个经典的认知陷阱。

一、”其他人都正常”证明不了”服务端没问题”。
这个反证只能说明故障不是全局的。凡是”部分客户端异常”的故障，都要先问一句：这部分客户端有什么共同点？ 这次答案是”它们在另一条网络路径上”——而这句话直接指向了 advertised 配置。

二、报错里出现的陌生 IP，是服务端主动告诉客户端的。
应用配置里明明写的是 pfscene.example.com，日志里却在连 192.168.0.196。这种”身份不明的地址”不要放过，它八成来自服务端的元数据广播，而不是客户端配置。Kafka 的这个地址就是 advertised.listeners。

三、”端口通”不等于”能连上”。
nc -zv 通只验证了四层可达，Kafka 的会话能不能建立，还要看第二阶段拿到的地址对不对。凡是”端口通、应用不通”的中间件故障，都该往元数据/协商层去想。

四、配置来源要区分”服务端视角”和”客户端视角”。
listeners 是服务端绑在哪里，advertised.listeners 是告诉客户端去哪里。混为一谈就会写出一个”服务端自己觉得没问题、客户端全都连不上”的配置。类似的还有 Redis 的 cluster announce、Elasticsearch 的 publish_address，套路如出一辙。

五、动手前先问一句”这个改动会打死谁”。
把 broadcast 地址改成对外域名，能救外部客户端，但会顺手打死内部客户端（比如 Kafdrop）。在只有一个 listener 的前提下，任何单点修改都是在两类客户端之间二选一——正确的动作不是选边，而是把 listener 拆开。

最后一句话收尾：这个参数的正确写法从来没有绝对答案，它取决于你的客户端从哪里来。想清楚有哪些网络路径，就配几个 listener，让每条路径上的客户端都听到自己够得着的地址——这才是 advertised.listeners 的正确打开方式。

玩软路由的朋友或多或少都经历过——机场跑路、节点失联、线路绕路、晚高峰爆炸。单靠一家机场，稳定性永远是个玄学问题。

多订阅聚合的核心思路很简单：把你的几个机场订阅合在一起，配合自动测速切换策略，死一个订阅其他依旧能用。

但 OpenClash 默认订阅面板只支持单链接。想实现多机场聚合 + 精细化分流，需要手动编辑 config.yaml，用上 proxy-providers 和 rule-providers 两个高级功能。

这篇文章以两个机场为例，从零讲清楚如何配置，直接对着改就行。

整体架构一览

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39

┌──────────────────────────────────┐
│         proxy-providers          │
│  ┌────────────┐ ┌────────────┐  │
│  │   机场A    │ │   机场B    │  │
│  └─────┬──────┘ └─────┬──────┘  │
│        │               │         │
│        └───────┬───────┘         │
│                │                 │
│                ▼                 │
│  ┌─────────────────────┐        │
│  │  ♻️ 自动选择        │        │
│  │  (url-test)         │        │
│  └─────────┬───────────┘        │
│            │                    │
│            ▼                    │
│  ┌─────────────────────┐        │
│  │  🌍 国外兜底        │        │
│  │  (select)           │        │
│  └─────────┬───────────┘        │
│            │                    │
│            ▼                    │
│  ┌─────────────────────┐        │
│  │  🚀 手动选择        │        │
│  │  (select)           │        │
│  └─────────────────────┘        │
└──────────────────────────────────┘
                  │
                  ▼
      ┌─────────────────────┐
      │   rule-providers    │
      │  ┌─────────────────┐│
      │  │ OpenAI 规则集    ││
      │  │ Proxy 规则集     ││
      │  └─────────────────┘│
      └─────────────────────┘
                  │
                  ▼
            分流规则引擎
     (GEOIP → DIRECT / MATCH → 国外兜底)

三层策略：

1. proxy-providers — 聚合多个机场的节点
2. proxy-groups — 按策略组织节点（手动选 / 自动测速 / 兜底故障转移）
3. rule-providers + rules — 精细控制哪些流量走代理、哪些直连

第一步：proxy-providers — 聚合多个机场

OpenClash 中，proxy-providers 相当于”动态节点来源”。把你的机场订阅链接填进去，Clash 会定期拉取并合并所有节点。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

proxy-providers:
  机场A:
    type: http
    url: https://你的机场A订阅链接
    interval: 3600        # 每小时更新一次
    proxy: DIRECT         # 订阅请求走直连（不走代理）
    path: ./providers/机场A.yaml
    exclude-filter: (?i)(距离下次重置)|(到期)|(流量)|(套餐)|(官网)
    health-check:
      enable: true
      url: https://cp.cloudflare.com/generate_204
      interval: 300       # 每5分钟检测节点可用性
    override:
      skip-cert-verify: false

  机场B:
    type: http
    url: https://你的机场B订阅链接
    interval: 3600
    proxy: DIRECT
    path: ./providers/机场B.yaml
    exclude-filter: (?i)(距离下次重置)|(到期)|(流量)|(套餐)|(官网)
    health-check:
      enable: true
      url: https://cp.cloudflare.com/generate_204
      interval: 300
    override:
      skip-cert-verify: true   # 如果机场证书有问题就设为true

关键参数说明

exclude-filter — 排除杂项节点

机场订阅里常常混入一堆无用信息节点——“剩余流量”、”到期时间”、”官网链接”。不去掉的话会在面板里显示成假节点。

用正则一键过滤：

1

exclude-filter: (?i)(距离下次重置)|(到期)|(流量)|(套餐)|(官网)

(?i) 表示不区分大小写。你也可以按自己机场的实际命名加减关键词。

第二步：proxy-groups — 策略组设计

三个策略组，各司其职：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

proxy-groups:
  # 第一层：手动主控
  - name: 🚀 手动选择
    type: select
    use:
      - 机场A
      - 机场B
    proxies:
      - ♻️ 自动选择
      - 🌍 国外兜底
      - DIRECT

  # 第二层：自动测速选优
  - name: ♻️ 自动选择
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300        # 每5分钟重新测速
    tolerance: 50        # 延迟差在50ms以内不切换
    use:
      - 机场A
      - 机场B

  # 第三层：兜底保底
  - name: 🌍 国外兜底
    type: select
    use:
      - 机场A
      - 机场B
    proxies:
      - ♻️ 自动选择
      - DIRECT

策略组职责

url-test 的工作方式

url-test 策略组每隔 interval 秒向所有节点发送一次 HTTP 请求，测量延迟，然后自动把流量切到延迟最低的那个节点。

tolerance: 50 意味着：当前节点延迟 200ms，另一个节点 160ms——差距超过 50ms，就切换过去。避免”因为 2ms 的微小差异就频繁跳切”。

为什么国外兜底要包含 DIRECT？

如果所有机场同时挂掉（虽然概率不大但玩路由久了就知道什么妖魔鬼怪都有），🌍 国外兜底 可以手动切到 DIRECT，至少保证国内网站正常访问，不会整个网络瘫痪。

第三步：rule-providers — 规则集

规则集决定了哪些流量走代理，哪些直连。OpenClash 自带大量规则集，你也可以自定义。

1
2
3
4
5
6
7
8
9
10
11
12

rule-providers:
  OpenAI:
    type: file
    behavior: classical
    path: ./rule_provider/OpenAI
    interval: 86400      # 每天更新一次

  Proxy:
    type: file
    behavior: classical
    path: ./rule_provider/Proxy
    interval: 86400

• OpenAI 规则集 — 包含 OpenAI / ChatGPT 相关域名，保证 AI 服务走代理
• Proxy 规则集 — 包含所有需要代理的常见域名（Google / YouTube / Twitter 等）

behavior: classical 表示经典域名匹配模式。一般用 classical 就够了，性能最好。

内置规则集位置

OpenClash 预置了很多规则集文件，通常在 /etc/openclash/rule_provider/ 下。你也可以从 Loyalsoldier/clash-rules 下载自定义规则集。

第四步：rules — 分流规则

最后一步，把所有策略串起来：

1
2
3
4
5
6
7
8
9
10
11
12

rules:
  # OpenAI 相关流量 → 手动选择策略组
  - RULE-SET,OpenAI,🚀 手动选择

  # 需要代理的常见域名 → 手动选择策略组
  - RULE-SET,Proxy,🚀 手动选择

  # 中国大陆 IP → 直连
  - GEOIP,CN,DIRECT

  # 以上都没命中 → 国外兜底
  - MATCH,🌍 国外兜底

规则匹配顺序（从上到下，命中即停止）

1
2
3
4
5
6
7

请求进入
    │
    ▼
┌─ RULE-SET,OpenAI ──→ 🚀 手动选择（命中则走代理）
├─ RULE-SET,Proxy  ──→ 🚀 手动选择（命中则走代理）
├─ GEOIP,CN         ──→ DIRECT（国内 IP 直连）
└─ MATCH            ──→ 🌍 国外兜底（兜底走代理）

设计原则：白名单思维——明确知道需要代理的走代理（OpenAI + Proxy 规则集），明确知道国内的走直连（GEOIP），剩下的也走代理兜底。比”黑名单”更不容易漏网，也更安全。

第五步：在 OpenClash 中加载配置

方法一：直接替换配置文件

1. 将上述配置合并成完整的 YAML 文件
2. 放置到 /etc/openclash/config/ 目录下
3. 在 OpenClash 面板中切换到该配置

方法二：OpenClash 面板分段编辑

OpenClash 的 Luci 页面提供了配置文件管理界面，你可以在”配置文件订阅”中添加 proxy-provider 订阅，在”规则附加”中修改 rules。

但多订阅聚合建议直接用方法一——手动编辑 YAML 更灵活可控，不会被面板的模板语法限制。

完整的 config.yaml 骨架

为了方便你快速上手，这里给出一个可直接使用的完整配置。替换订阅链接即可。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82

port: 7890
socks-port: 7891
allow-lan: true
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

proxy-providers:
  机场A:
    type: http
    url: https://你的机场A订阅链接
    interval: 3600
    proxy: DIRECT
    path: ./providers/机场A.yaml
    exclude-filter: (?i)(距离下次重置)|(到期)|(流量)|(套餐)|(官网)
    health-check:
      enable: true
      url: https://cp.cloudflare.com/generate_204
      interval: 300
    override:
      skip-cert-verify: false

  机场B:
    type: http
    url: https://你的机场B订阅链接
    interval: 3600
    proxy: DIRECT
    path: ./providers/机场B.yaml
    exclude-filter: (?i)(距离下次重置)|(到期)|(流量)|(套餐)|(官网)
    health-check:
      enable: true
      url: https://cp.cloudflare.com/generate_204
      interval: 300
    override:
      skip-cert-verify: true

rule-providers:
  OpenAI:
    type: file
    behavior: classical
    path: ./rule_provider/OpenAI
    interval: 86400
  Proxy:
    type: file
    behavior: classical
    path: ./rule_provider/Proxy
    interval: 86400

proxy-groups:
  - name: 🚀 手动选择
    type: select
    use:
      - 机场A
      - 机场B
    proxies:
      - ♻️ 自动选择
      - 🌍 国外兜底
      - DIRECT

  - name: ♻️ 自动选择
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    use:
      - 机场A
      - 机场B

  - name: 🌍 国外兜底
    type: select
    use:
      - 机场A
      - 机场B
    proxies:
      - ♻️ 自动选择
      - DIRECT

rules:
  - RULE-SET,OpenAI,🚀 手动选择
  - RULE-SET,Proxy,🚀 手动选择
  - GEOIP,CN,DIRECT
  - MATCH,🌍 国外兜底

常见问题排查

1. 节点列表为空 / 订阅拉取失败

• 检查机场订阅链接是否有效（在浏览器里直接访问看能不能下载）
• 检查 proxy: DIRECT — 部分网络下拉取订阅本身可能需要走代理，换成 proxy: 🚀 手动选择 试试
• OpenClash 日志里看具体报错：log-level: debug

2. url-test 频繁跳切

• 调大 tolerance 值（比如 100-150ms），减少微小延迟波动导致的切换
• 加大 interval（比如 600 秒），降低测速频率

3. 规则不生效

• 确认 rule-providers 的 path 文件真实存在
• 确认 behavior 类型与规则集文件格式匹配
• 检查 OpenClash 面板中是否勾选了”禁用规则”

4. 部分机场节点证书报错

• 把对应 proxy-provider 的 override.skip-cert-verify 设为 true

总结

这套配置的核心优势：

• 高可用 — 多个机场节点池，自动测速选最优，一个挂了不影响全局
• 精细分流 — OpenAI 单独规则集，国内 IP 直连，国外流量走代理
• 低维护 — proxy-provider 每小时自动更新，rule-provider 每天更新，基本不用手动管
• 灵活切换 — 🚀 手动选择 → ♻️ 自动测速 → 🌍 兜底保底，三层故障转移

折腾完这一套，自此告别”机场又挂了”的烦恼。

在使用 Cloudflare Tunnel（cloudflared）进行内网穿透时，国内用户经常会遇到连接不稳定、延迟极高甚至完全无法访问的问题。这背后的根本原因是：

中国大陆部分运营商（如中国电信、中国联通、中国移动）对 UDP 流量（尤其是 443 端口的 UDP）存在极其严格的 QoS（服务质量）限制甚至直接丢包。

这就导致基于 UDP 的 HTTP/3 (QUIC) 协议在跨国连接时经常处于”半死不活”的状态。

而 Cloudflare Tunnel 默认会优先尝试使用 QUIC 协议 (HTTP/3) 来建立本地服务器到 Cloudflare 边缘节点的连接。如果遭遇运营商拦截，就会导致：

• 🔴 连接不断断开重连
• 🔴 延迟极高（数秒到十几秒）
• 🔴 部分请求超时
• 🔴 完全无法访问

解决方案核心思路

强制 cloudflared 在本地回源时使用基于 TCP 的 HTTP/2 协议，彻底绕过 UDP 限制。

根据你的部署方式（命令行、配置文件或 Docker），选择对应的修改方法。

🛠️ 方法一：命令行启动方式

如果你是通过命令行直接启动 Cloudflare Tunnel，只需在 cloudflared tunnel run 命令后面加上 --protocol http2 参数。

示例命令

1

cloudflared tunnel --protocol http2 run <你的隧道名称或ID>

完整示例

1
2

# 假设你的隧道名称是 my-tunnel
cloudflared tunnel --protocol http2 run my-tunnel

验证是否生效

启动后，观察输出日志中是否包含类似信息：

1

INFO Connection established protocol=http2

如果看到 protocol=http2，说明配置生效。

🛠️ 方法二：使用配置文件（推荐）

如果你使用配置文件管理 Cloudflare Tunnel，这是最推荐的方式，便于长期维护和版本控制。

配置文件位置

通常位于以下路径之一：

• Linux/macOS: ~/.cloudflared/config.yml
• Windows: %USERPROFILE%\.cloudflared\config.yml
• 自定义路径: 通过 --config 参数指定

配置示例

1
2
3
4
5
6
7
8
9
10
11
12
13

tunnel: <你的Tunnel-ID>
credentials-file: /root/.cloudflared/<Tunnel-ID>.json

# 🎯 核心配置：强制使用 http2 替代 quic
protocol: http2

ingress:
  - hostname: yoursite.com
    service: http://localhost:8080
  - hostname: api.yoursite.com
    service: http://localhost:3000
  # 捕获所有其他请求，返回 404
  - service: http_status:404

关键配置说明

修改后重启服务

如果你使用 systemd 管理服务：

1

sudo systemctl restart cloudflared

如果是手动启动：

1

cloudflared tunnel run

🛠️ 方法三：Systemd 服务托管方式

如果你是使用 systemctl 托管的 cloudflared 服务，只需要修改 Systemd 服务配置文件或其关联的环境配置文件即可。

1. 查找服务文件位置

通常，cloudflared 官方安装脚本会自动创建名为 cloudflared.service 的服务。你可以通过以下命令直接编辑：

1

sudo systemctl edit --full cloudflared.service

💡 提示：如果习惯使用 vim，也可以手动执行 sudo vim /etc/systemd/system/cloudflared.service

2. 修改配置（根据启动方式选择）

进入编辑界面后，根据你的具体服务内容选择对应的修改方式：

情况 A：通过 Token 启动的服务

如果你的服务文件里 ExecStart 后面跟着的是 --token，请直接在后面加上 --protocol http2。

修改前：

1
2

[Service]
ExecStart=/usr/local/bin/cloudflared tunnel run --token eyJ...

修改后：

1
2

[Service]
ExecStart=/usr/local/bin/cloudflared tunnel --protocol http2 run --token eyJ...

情况 B：通过配置文件（config.yml）启动的服务

如果你的服务文件里指定了 config.yml 的路径：

修改前：

1
2

[Service]
ExecStart=/usr/local/bin/cloudflared --config /etc/cloudflared/config.yml tunnel run

修改后：

1
2

[Service]
ExecStart=/usr/local/bin/cloudflared --config /etc/cloudflared/config.yml tunnel --protocol http2 run

💡 提示：如果是情况 B，你其实也可以不用动这个服务文件，直接去修改 /etc/cloudflared/config.yml，在里面加一行 protocol: http2，效果是完全一样的（推荐使用配置文件方式，更便于维护）。

3. 重新加载并重启服务

修改并保存服务文件后，必须刷新 Systemd 守护进程并重启服务才能生效：

1
2
3
4
5
6
7
8

# 1. 重新加载 Systemd 配置
sudo systemctl daemon-reload

# 2. 重启 cloudflared 服务
sudo systemctl restart cloudflared

# 3. 检查服务状态是否正常
sudo systemctl status cloudflared

4. 验证是否成功切换为 HTTP/2

重启后，查看 cloudflared 的实时日志，确认它是否已经成功使用了 http2 协议：

1

sudo journalctl -u cloudflared.service -n 50 -f

成功标志：

• 日志中出现 protocol=http2 或 Protocol: http2
• 连接端口变成了 7844（Cloudflare 的 HTTP/2 隧道专用端口）

失败标志：

• 依然在使用 443 端口并提示 quic
• 请检查上面的参数位置是否放错（--protocol http2 必须在 run 之前）

完整服务文件示例

以下是一个完整的 cloudflared.service 文件示例供参考：

1
2
3
4
5
6
7
8
9
10
11
12
13

[Unit]
Description=Cloudflare Tunnel
After=network.target

[Service]
Type=simple
User=root
ExecStart=/usr/local/bin/cloudflared tunnel --protocol http2 run --token eyJhIjoiY2xvdWRmbGFyZS10dW5uZWwiLCJ0IjoiZXhhbXBsZS10b2tlbi1oZXJlIn0
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target

🛠️ 方法四：Docker 部署方式

如果你通过 Docker 容器运行 Cloudflare Tunnel，需要在启动命令中加入 --protocol http2 参数。

Docker Run 方式

1
2
3
4
5
6

docker run -d \
  --name cloudflared \
  --restart unless-stopped \
  -v ~/.cloudflared:/etc/cloudflared \
  cloudflare/cloudflared:latest \
  tunnel --protocol http2 run --token <你的TUNNEL_TOKEN>

Docker Compose 方式（推荐）

创建 docker-compose.yml 文件：

1
2
3
4
5
6
7
8
9
10
11

version: '3'
services:
  cloudflared:
    image: cloudflare/cloudflared:latest
    container_name: cloudflared
    restart: unless-stopped
    command: tunnel --protocol http2 run --token <你的TUNNEL_TOKEN>
    # 如果使用配置文件方式，可以挂载配置文件
    # volumes:
    #   - ./config.yml:/etc/cloudflared/config.yml
    #   - ./tunnel-credentials.json:/etc/cloudflared/tunnel-credentials.json

启动容器

1

docker-compose up -d

查看日志验证

1

docker logs -f cloudflared

确认日志中包含 protocol=http2 字样。

💡 原理解析：为什么这样就能解决问题？

默认状态（使用 QUIC，问题状态）

1
2

cloudflared ──(UDP/443)──> 运营商 QoS 限制（拦截/丢包） ──✗──> Cloudflare 节点
                                    ❌ 连接不稳定/失败

优化后状态（使用 HTTP/2，正常状态）

1
2

cloudflared ──(TCP/7844 或 443)──> 运营商放行 ──✓──> Cloudflare 节点
                                    ✅ 稳定连接

关键点说明

1. QUIC 基于 UDP：HTTP/3 使用 QUIC 协议，底层是 UDP。国内运营商对 UDP（尤其是 443 端口）有严格限制。

2. HTTP/2 基于 TCP：当指定 protocol: http2 后，Cloudflare Tunnel 会改用标准的 TCP 协议（通常是 7844 端口或 443 端口的 TCP）与 Cloudflare 边缘节点建立长连接。

3. TCP 优先级更高：TCP 协议在国内跨国网络中的优先级和稳定性远高于 UDP，从而彻底避免了因 QUIC 被墙或被限制导致的无法访问问题。

🎯 进阶优化：配合优选 IP 效果更佳

仅仅修改为 http2 只能保证你的内网服务器到 Cloudflare 节点这一段是稳定的。

但中国用户到 Cloudflare 节点这一段（即公网访问段），依然可能会因为 Cloudflare 默认分配的 Anycast IP 在国内被限速。

优化建议

1. 在 Cloudflare 后台关闭 HTTP/3 (QUIC)

这样可以确保国内用户访问你的网站时，浏览器也会强制降级到 HTTP/2 (TCP) 访问，进一步提升稳定性。

操作步骤：

1. 登录 Cloudflare 仪表盘
2. 选择你的域名
3. 进入 网络 (Network) 菜单
4. 找到 HTTP/3 (with QUIC) 开关，将其关闭

2. 使用 Cloudflare 优选 IP（SaaS 域名重定向）

配合市面上的 Cloudflare 优选 IP 脚本，将国内用户的流量解析到国内延迟较低的 Cloudflare 边缘 IP 上。

实现方式：

• 使用 DNS 智能解析（如 Cloudflare Workers 或第三方 DNS 服务）
• 针对国内 IP 返回优选的 Cloudflare IP
• 针对海外 IP 返回默认的 Anycast IP

优选 IP 工具推荐：

• CloudflareSpeedTest
• better-cloudflare-ip

3. 启用 Argo Smart Routing（付费功能）

Cloudflare Argo 可以智能选择最优路由路径，进一步提升跨国访问速度和稳定性。

价格：$5/月 + $0.10/GB 流量费

对于高流量或对稳定性要求极高的业务，Argo 是值得考虑的选项。

📋 常见问题 FAQ

Q1: 修改为 HTTP/2 会影响性能吗？

A: 理论上 QUIC (HTTP/3) 比 HTTP/2 性能更好，但在国内网络环境下，由于 UDP 被限制，QUIC 反而会导致极差的体验。使用 HTTP/2 后，虽然理论性能略低，但实际体验会大幅提升，因为稳定性是第一位的。

Q2: 我的 cloudflared 版本较老，支持 --protocol 参数吗？

A: --protocol 参数在较新版本中引入，建议升级到最新版本：

1
2
3
4
5
6

# Linux/macOS
cloudflared update

# 或重新下载安装
wget -q https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared-linux-amd64.deb

Q3: 如何验证当前使用的协议？

A: 查看 cloudflared 的日志输出，搜索 protocol 关键字：

1
2
3
4
5

# 查看 systemd 日志
sudo journalctl -u cloudflared -f | grep protocol

# 查看 Docker 日志
docker logs -f cloudflared | grep protocol

正常情况下应该看到 protocol=http2。

Q4: 配置后仍然不稳定怎么办？

A: 依次检查以下几点：

1. 确认配置已生效（查看日志中的 protocol=http2）
2. 检查是否在 Cloudflare 后台关闭了 HTTP/3
3. 尝试使用优选 IP
4. 检查本地网络是否稳定（排除本地网络问题）
5. 尝试更换 Cloudflare Tunnel 的边缘节点（重启服务会自动重新连接）

🎉 总结

通过强制 Cloudflare Tunnel 使用 HTTP/2 协议，可以有效解决国内运营商对 UDP/QUIC 的限制问题，大幅提升连接稳定性和访问速度。

核心要点

✅ 必做：在 cloudflared 配置中添加 protocol: http2
✅ 推荐：在 Cloudflare 后台关闭 HTTP/3 (QUIC)
✅ 进阶：配合优选 IP 进一步提升国内访问速度

希望这篇教程能帮助你彻底解决 Cloudflare Tunnel 在国内的连接问题！

参考资料

• Cloudflare Tunnel 官方文档
• cloudflared GitHub 仓库
• QUIC 协议详解

WSL2 的 Linux 发行版数据存储在 Windows 宿主机的一个 .vhdx 虚拟磁盘文件中（通常位于 D:\WSL\<发行版名>\ext4.vhdx）。即使 WSL2 默认使用稀疏文件（Sparse VHDX），这个文件依然存在一个很”坑”的特性：

虚拟磁盘只会动态增长，不会自动缩小。

举个例子：你在 Ubuntu 里编译了一个大项目，产生了 20G 的临时文件，ext4.vhdx 膨胀到了 25G。之后你把那些临时文件删了，Ubuntu 里 df -h 显示只用了 5G，但在 Windows 文件资源管理器里，ext4.vhdx 依然占据 25G 的硬盘空间。

为什么会这样？

WSL2 的虚拟磁盘本质上是一个稀疏分配的 VHDX 文件。稀疏分配（Sparse）意味着文件实际大小 = 实际写入过的数据量，而不是虚拟磁盘的容量上限。

但问题在于：WSL2 只做了”标记空间为可用”这件事，并没有通知 Windows 宿主机回收这部分空闲区域。 对于宿主机来说，那些曾经被写入过、后来被 Linux 标记为”已删除”的区块，仍然是”有效数据”。

解决思路也很直接：用工具对虚拟磁盘执行一次 Compact（压缩） 操作，把内部已标记为空闲的区块真正释放回宿主机。

准备工作

⚠️ 操作前请确保 WSL 中的重要工作已经保存。

第一步：彻底关闭 WSL

压缩操作要求虚拟磁盘文件不被任何进程占用，因此必须先关闭所有 WSL 实例。

打开 Windows PowerShell（建议以管理员身份运行），执行：

1

wsl --shutdown

确认所有实例已停止：

1

wsl --list --verbose

输出中所有发行版的 STATE 都应为 Stopped。

核心步骤：diskpart 压缩

diskpart 是 Windows 自带的磁盘管理命令行工具，无需安装任何第三方软件。

在 PowerShell 中输入 diskpart 进入交互模式：

1

diskpart

你会看到提示符变为 DISKPART>，然后按顺序执行以下命令：

1. 选择虚拟磁盘文件

1

DISKPART> select vdisk file="D:\WSL\Ubuntu2404\ext4.vhdx"

路径请替换为你自己的实际路径。如果不确定路径，可以用 wsl --list --verbose 查看发行版名称，然后去对应的安装目录下找 .vhdx 文件。

选择成功后，diskpart 会提示已选择虚拟磁盘文件。

2. 以只读模式挂载

1

DISKPART> attach vdisk readonly

只读挂载是压缩前的必要步骤，它让 diskpart 能够读取磁盘内部的空闲空间信息，同时又不会修改任何数据。

3. 执行压缩

1

DISKPART> compact vdisk

这是核心步骤——diskpart 会分析虚拟磁盘内部哪些区块是真正被占用的、哪些是空闲的，然后把空闲区块从宿主机文件中释放。执行时间取决于虚拟磁盘大小和硬盘速度，通常在几秒到几分钟之间。

压缩进度和结果会直接显示在当前窗口中。

4. 分离并退出

1
2

DISKPART> detach vdisk
DISKPART> exit

至此，压缩完成！

验证结果

回到 .vhdx 文件所在的目录查看大小：

1

Get-ChildItem "D:\WSL\Ubuntu2404\ext4.vhdx" | Select-Object Name, @{Name="Size(GB)";Expression={[math]::Round($_.Length/1GB,2)}}

或者在文件资源管理器中右键查看属性，你会发现文件大小已经有了明显缩水，硬盘空间真正被释放了。

一键脚本

如果你不想每次都手动输入 diskpart 命令，可以把上述步骤写成一个批处理脚本 compact-wsl.ps1：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

# compact-wsl.ps1
# 使用前请先保存 WSL 中的工作，然后以管理员身份运行

param(
    [string]$VhdxPath = "D:\WSL\Ubuntu2404\ext4.vhdx"
)

Write-Host "正在关闭 WSL..." -ForegroundColor Yellow
wsl --shutdown
Start-Sleep -Seconds 3

Write-Host "开始压缩虚拟磁盘: $VhdxPath" -ForegroundColor Yellow

$script = @"
select vdisk file="$VhdxPath"
attach vdisk readonly
compact vdisk
detach vdisk
exit
"@

$script | diskpart

Write-Host "压缩完成！" -ForegroundColor Green

# 显示压缩后大小
Get-ChildItem $VhdxPath | ForEach-Object {
    $sizeGB = [math]::Round($_.Length / 1GB, 2)
    Write-Host "当前虚拟磁盘大小: ${sizeGB} GB" -ForegroundColor Green
}

以后只需要右键以管理员身份运行这个脚本即可。

常见问题

Q: 压缩会影响 WSL 里的数据吗？

不会。compact vdisk 只是释放已经被 Linux 标记为空闲的空间，不会触碰任何有效数据。而且我们是以 readonly 模式挂载的，对原数据零风险。

Q: 需要多久操作一次？

不需要固定周期。当你发现 WSL 里删了大量文件但 Windows 硬盘空间没有明显释放时，做一次压缩就好。

Q: 操作失败提示”文件被占用”？

确保执行了 wsl --shutdown。如果仍然提示被占用，重启一次 Windows 后再试。

Q: 能不能让 WSL2 自动回收空间？

目前 WSL2 本身没有内置的自动压缩机制。不过微软在较新的 WSL 版本中加入了 [wsl2] sparseVhd=true 的 .wslconfig 配置项（默认已启用），这只是保证新数据稀疏写入，并不能回收已膨胀的空间。手动 compact 仍是唯一可靠的方式。

小结

WSL2 虚拟磁盘膨胀是个老生常谈的问题，好在解决起来非常简单：

1. wsl --shutdown 关闭 WSL
2. diskpart → compact vdisk 压缩虚拟磁盘
3. 硬盘空间回来了 🎉

建议收藏本文或把上面的 PowerShell 脚本存下来，以备不时之需。