OpenClash Mux 不兼容性修复 - 2026年1月15日¶

状态: ✅ 已解决
日期: 2026-01-15 19:10 CST
持续时间: 约1小时调试

问题概述¶

所有 OpenClash 代理 (LA-VMess, LA-VLESS, HK-VMess, HK-VLESS) 显示 alive=false, 健康检查失败。路由器和 WiFi 客户端无法通过代理访问 GitHub, YouTube 或任何国际站点。

症状¶

❌ 路由器测试: curl https://api.github.com → TLS 握手错误
❌ WiFi 客户端测试: curl https://ipinfo.io/ip → 超时
❌ 所有代理健康检查: "alive":false, "delay":0
❌ 直接测试: curl -x http://127.0.0.1:7890 https://google.com → SSL_ERROR_SYSCALL

错误模式¶

TLS connect error: error:00000000:lib(0)::reason(0)
OpenSSL SSL_connect: SSL_ERROR_SYSCALL

根本原因¶

Xray mux 协议在使用 SOCKS5 后端时与 Clash 客户端不兼容

代理链是:

Clash 客户端 (OpenWrt 路由器)
    ↓ VMess/VLESS over WebSocket/TLS
Xray 服务器 (VPS)
    ↓ 已启用 MUX ← 问题在这里
SOCKS5 代理 (StarVPN)
    ↓
互联网

技术细节¶

Xray 日志在每个连接上都显示此错误模式:

[Info] accepted tcp:github.com:443 [vmess-in -> starvpn-out]
[Info] common/mux: dispatching request to tcp:github.com:443
[Info] transport/internet/tcp: dialing TCP to tcp:proxy.starzone.io:51313
[Info] common/mux: failed to fetch all input > io: read/write on closed pipe
[Info] app/proxyman/inbound: connection ends > proxy/vmess/inbound: connection ends > EOF

问题: mux 多路复用层在连接到 SOCKS5 后端后立即关闭管道。连接会接受, 尝试多路复用, 连接到 StarVPN, 然后立即关闭并显示 "read/write on closed pipe"。

诊断过程¶

1. 协议测试¶

测试所有 4 个配置的代理以隔离是否是协议特定问题: - LA-VMess: ❌ TLS 错误 - LA-VLESS: ❌ TLS 错误
- HK-VMess: ❌ TLS 错误 - HK-VLESS: ❌ TLS 错误

结论: 不是协议特定的, 影响 VMess 和 VLESS。

2. 客户端测试¶

路由器发起的流量: ❌ 失败
WiFi 客户端流量 (192.168.188.10): ❌ 超时

结论: 不是客户端特定的, 影响通过代理的所有流量。

3. VPS 服务验证¶

# LA VPS 检查
curl https://vmiss.ata.lol
# ✅ 返回: "Hello from vmiss.ata.lol"

# SSL 证书检查
openssl s_client -connect vmiss.ata.lol:443
# ✅ 有效的 ZeroSSL 证书

# StarVPN 检查 (直接从 VPS)
curl --socks5 proxy.starzone.io:51313 https://ipinfo.io/ip
# ✅ 返回: 168.148.92.254

结论: VPS 服务健康, StarVPN 后端工作正常, 问题在中间层。

4. OpenClash 日志分析¶

tail -200 /tmp/openclash.log

日志显示: - ✅ 流量被正确拦截 - ✅ 规则匹配正常: match DstPort(443) using Proxy[LA-VMess] - ✅ 无错误消息(仅 info 级别) - ❌ 但连接默默失败

结论: OpenClash 路由工作正常, 问题在 VPS 下游。

5. Xray 日志分析 (关键发现)¶

docker compose logs --tail=50 xray

发现确凿证据:

common/mux: failed to fetch all input > io: read/write on closed pipe

每个连接在接受后立即显示此模式。mux 层是故障点。

解决方案¶

步骤 1: 在 LA VPS 上禁用 Mux¶

文件: /root/proxy-stack/xray/config.json

更改前:

"outbounds": [{
  "protocol": "socks",
  "tag": "starvpn-out",
  "settings": {
    "servers": [{"address": "proxy.starzone.io", "port": 51313}]
  },
  "mux": {
    "enabled": true,    ← 移除
    "concurrency": 8    ← 移除
  }
}]

更改后:

"outbounds": [{
  "protocol": "socks",
  "tag": "starvpn-out",
  "settings": {
    "servers": [{"address": "proxy.starzone.io", "port": 51313}]
  },
  "mux": {
    "enabled": false
  }
}]

重启:

cd /root/proxy-stack
docker compose restart xray

步骤 2: 在 HK VPS 上重复¶

在 vmisshk.ata.lol 上进行相同的配置更改:

cd /root/proxy-stack
docker-compose restart xray  # 注意: HK 使用较旧的 docker-compose

步骤 3: 验证修复¶

# 从路由器测试
curl https://api.github.com
# ✅ 成功 - 返回 GitHub API 响应

# 检查外部 IP
curl https://ipinfo.io/ip
# ✅ 返回: 168.148.92.254 (StarVPN LA 出口 IP)

# 检查代理健康状态
curl -s http://127.0.0.1:9090/proxies/LA-VMess | grep "alive"
# ✅ "alive":true

结果¶

修复前¶

所有代理: alive=false
路由器出口 IP: 36.112.15.125 (天津, 中国 - 直连)
GitHub/YouTube: 访问被拒绝
Ping 测试: 到百度 94ms (本地中国连接)

修复后¶

所有代理: alive=true ✅
路由器出口 IP: 168.148.92.254 (洛杉矶, 美国 - 通过代理) ✅
GitHub/YouTube: 完全可访问 ✅
控制面板: 显示正常运行 ✅
OpenWrt Web UI: 正确的连接状态 ✅

技术解释¶

为什么 Mux 失败¶

Mux (多路复用) 是一种允许多个流共享单个连接的协议。它适用于: - 减少连接开销 - 绕过连接限制 - 在某些情况下提高性能

然而, 在这个特定的代理链中:

Clash → Xray (启用 mux) → SOCKS5 → 互联网

mux 协议层期望控制整个连接生命周期。当 Xray 尝试通过 SOCKS5 后端多路复用连接时:

Clash 向 Xray 发送连接请求
Xray 的 mux 层接受并包装在 mux 协议中
Mux 尝试建立到 SOCKS5 的多路复用连接
SOCKS5 协议期望标准 TCP, 而不是 mux 包装
协议不匹配导致 "closed pipe" 错误
连接立即终止

为什么没有 Mux 时可以工作¶

Clash → Xray (无 mux) → SOCKS5 → 互联网

没有 mux: 1. Clash 向 Xray 发送连接请求 2. Xray 作为标准 TCP/WebSocket 接受 3. Xray 作为标准 SOCKS5 请求转发 4. SOCKS5 后端正常处理 5. 连接保持打开, 数据正常流动

经验教训¶

1. Mux 兼容性矩阵¶

场景	可行?	备注
Clash → Xray (mux) → 直连	✅ 是	标准用例
Clash → Xray (mux) → HTTP 代理	✅ 是	HTTP 协议兼容
Clash → Xray (mux) → SOCKS5	❌ 否	协议不匹配
Clash → Xray (无 mux) → SOCKS5	✅ 是	标准代理

2. 调试原则¶

调试代理链时: 1. 独立测试每个段 (Clash ✓, VPS ✓, 后端 ✓) 2. 检查每一层的日志 (在 Xray 日志中发现问题, 而不是 Clash) 3. 不要假设协议兼容 (Mux + SOCKS5 = 不兼容) 4. 查找错误模式 (每个连接都有 "closed pipe" = 协议问题)

3. 配置最佳实践¶

对于 Xray 中间跳配置: - ✅ 当 Xray → 直连到互联网时使用 mux - ✅ 当 Xray → HTTP/HTTPS 代理时使用 mux - ❌ 当 Xray → SOCKS5 代理时不要使用 mux - ❌ 当协议兼容性未知时不要使用 mux

修改的文件¶

LA VPS (vmiss.ata.lol)¶

/root/proxy-stack/xray/config.json
- 更改前: "mux": {"enabled": true, "concurrency": 8}
- 更改后: "mux": {"enabled": false}

HK VPS (vmisshk.ata.lol)¶

/root/proxy-stack/xray/config.json
- 更改前: "mux": {"enabled": true, "concurrency": 8}
- 更改后: "mux": {"enabled": false}

gc.ata.lol (192.168.192.88)¶

/home/xueyao/OPENCLASH_SYSTEM_REFERENCE.md
- 更新: 实施历史部分
- 更新: 协议部分 (标记 mux 为禁用)
- 更新: 系统架构图
- 添加: Mux 故障排除部分

路由器 (192.168.192.77)¶

/root/maintenance_log
- 添加: 完整的诊断和解决日志
- 时间戳: 2026-01-15 19:10 CST

命令参考¶

使用的诊断命令¶

# 检查代理健康状态
curl -s http://127.0.0.1:9090/proxies/LA-VMess

# 测试代理连接
curl -m 10 https://api.github.com

# 检查外部 IP
curl https://ipinfo.io/ip

# 检查 Xray 日志 (在这里发现问题)
ssh -p 22222 root@vmiss.ata.lol "cd /root/proxy-stack && docker compose logs --tail=100 xray"

# 监控 OpenClash 日志
tail -200 /tmp/openclash.log

修复命令¶

# LA VPS - 禁用 mux
ssh -p 22222 root@vmiss.ata.lol
cd /root/proxy-stack/xray
vi config.json  # 将 mux.enabled 更改为 false
cd /root/proxy-stack
docker compose restart xray

# HK VPS - 禁用 mux
ssh -p 22222 root@vmisshk.ata.lol
cd /root/proxy-stack/xray
vi config.json  # 将 mux.enabled 更改为 false
cd /root/proxy-stack
docker-compose restart xray

验证命令¶

# 检查修复是否有效
curl https://api.github.com
curl https://ipinfo.io/ip

# 验证代理健康状态
curl -s http://127.0.0.1:9090/proxies/LA-VMess | grep "alive"

预防措施¶

对于未来的 VPS 部署¶

在创建具有 SOCKS5 后端的新 Xray 配置时, 使用此模板:

{
  "outbounds": [
    {
      "protocol": "socks",
      "tag": "socks-backend",
      "settings": {
        "servers": [
          {
            "address": "backend.proxy.example",
            "port": 1080
          }
        ]
      },
      "mux": {
        "enabled": false  // ← 关键: 对于 SOCKS5 后端始终为 false
      }
    }
  ]
}

监控¶

将此添加到每周维护检查清单:

# 检查所有代理是否存活
ssh root@192.168.192.77 "curl -s http://127.0.0.1:9090/proxies | jq '.proxies[] | {name, alive}'"

# 预期输出: 所有应显示 "alive": true