Docker 中 n8n 的代理负载均衡：修复 DNS 错误

Docker 中 n8n 的容错代理负载均衡：修复 DNS 超时和访问错误

通过单一代理运行 n8n 是一种架构漏洞。如果 IP 被封锁或代理服务器故障，所有工作流都会停摆。唯一可靠的解决方案是部署代理池，支持自动故障转移和轮询负载均衡。本指南将指导你使用 Docker 栈设置 3proxy，解决关键的 DNS 错误和权限问题，并验证整个链路的可靠性。

容错代理池架构

与其让 n8n 直接连接 Telegram 或其他外部 API，不如插入一个本地 3proxy 容器作为网关。它在 3128 端口处理来自 n8n 的 HTTP/HTTPS 请求，并将它们分发到预定义的外部 SOCKS5 代理列表。主要优势：

• 自动故障转移：如果一个节点宕机，流量立即切换到下一个可用代理。
• 对 n8n 透明：无需修改工作流，只需在环境变量中设置单一代理地址即可。
• IP 泄漏防护：如果所有外部代理失效，连接将被强制断开，避免流量通过服务器真实 IP 泄漏。

该设置使用 docker-compose，n8n 和 3proxy 服务均位于自定义网络中。这确保了稳定的内部路由，而无需在主机上暴露端口。

设置 docker-compose.yml 和 3proxy 配置文件

从这个基础栈开始。注意 user: "0:0" 参数——这是 3proxy 在容器内正常运行的必需条件，因为进程需要权限绑定网络端口并从卷中读取配置。

version: '3.8'

services:
  n8n:
    image: docker.n8n.io/n8nio/n8n:latest
    container_name: n8n
    environment:
      - HTTP_PROXY=http://3proxy:3128
      - HTTPS_PROXY=http://3proxy:3128
      - http_proxy=http://3proxy:3128
      - https_proxy=http://3proxy:3128
    networks:
      - n8n_net

  3proxy:
    image: ghcr.io/z3apa3a/3proxy:latest
    container_name: 3proxy
    restart: always
    user: "0:0"
    volumes:
      - ./3proxy.cfg:/etc/3proxy/3proxy.cfg
    networks:
      - n8n_net

networks:
  n8n_net:
    name: n8n_net

核心负载均衡逻辑放在 3proxy.cfg 中。这里是一个带注释的最小工作配置：

daemon
log /var/log/3proxy.log D
logformat "L%t.%. %N.%p %E %U %C:%c %R:%r %O %I %h %T"

# Use Docker's DNS resolver, not an external one (e.g., 8.8.8.8)
nserver 127.0.0.11
nscache 65536
timeouts 1 5 30 60 180 1800 15 60

# Enable ACL — without this, parent chains are ignored
auth iponly

# Allow must come BEFORE declaring parent
allow *

# Pool of external proxies (round-robin)
parent 1000 socks5 IP_PROXY_1 PORT_1 LOGIN_1 PASS_1
parent 1000 socks5 IP_PROXY_2 PORT_2 LOGIN_2 PASS_2
parent 1000 socks5 IP_PROXY_3 PORT_3 LOGIN_3 PASS_3

# Deny direct outbound if all proxies are unavailable
deny * * 0.0.0.0/0

# Launch HTTP proxy on port 3128
proxy -p3128 -a
flush

诊断和修复常见错误

首次启动时，你会遇到三种典型问题。解决它们是实现稳定系统的关键。

错误 1：DNS 超时（每个请求 26 秒）

症状：n8n 在每个请求上挂起整整 26 秒，然后要么收到响应，要么超时。

原因：配置指向外部 DNS 服务器（例如 nserver 8.8.8.8），但 3proxy 容器无法通过 Docker 自定义网络访问外部互联网。DNS 查询无处可去，只能等待超时。

修复：切换到 Docker 内部解析器，使用 nserver 127.0.0.11。此地址在任何容器中始终可用，并将查询转发到主机系统。

错误 2：容器启动时权限被拒

症状：3proxy 容器启动后立即崩溃，日志显示无法绑定端口或读取配置。

原因：官方 3proxy 镜像默认以非特权用户运行，无法绑定低于 1024 的端口或访问挂载卷。

修复：在 docker-compose 的 3proxy 服务中明确设置 user: "0:0"。这会在容器的隔离命名空间中以 root 身份运行进程——由于网络受限，这是安全的。

错误 3：流量绕过代理池

症状：n8n 正常工作，但出站 IP 检查显示服务器真实地址，而非代理。负载均衡器忽略 parent 指令。

原因及修复：

• 指令顺序错误：allow * 必须严格位于第一个 parent 之前，否则解析器会抛出 Chaining error 并禁用链路。
• ACL 被禁用：auth none 会完全禁用访问控制，破坏转发逻辑。改用 auth iponly。
• 缺少回退防护：没有 deny 0.0.0.0/0，如果整个代理池失效，系统可能泄漏直连流量。此行确保连接断开，而不是回退到默认路由。

验证系统功能

设置完成后，确认流量通过负载均衡器和代理池流动。使用以下两个检查：

• 检查 3proxy 日志：

```

docker compose logs --tail 20 3proxy

```

查找类似 [NNN] CONNECT ... 的条目——它们确认请求被接受并转发。如果看到 Permission denied，重新检查 user: "0:0" 设置。

• 从 n8n 进行端到端测试：

```

docker compose exec n8n curl -Ivx http://3proxy:3128 https://api.telegram.org

```

预期返回 HTTP 200 OK 和头部信息。如果挂起，则是 DNS 问题（nserver）。如果 Connection refused，确保 3proxy 正在运行且 3128 端口开放。

可选地，在 3proxy 配置中添加 logrotate 1000000 5，以实现基于大小的日志轮转，避免填满磁盘。

关键要点

• Docker DNS 必须始终指向 127.0.0.11，否则会出现 26 秒超时。
• 容器用户权限至关重要：没有 user: "0:0"，3proxy 无法绑定 3128 端口。
• 3proxy 配置中的指令顺序很重要：allow * 在 parent 之前，auth iponly 而非 none。
• IP 泄漏防护必不可少：deny 0.0.0.0/0 在代理池完全失效时阻止直连流量。
• 轮询负载均衡内置于 3proxy——无需额外工具或脚本。

此设置即使在部分基础设施故障时，也能让 n8n 顺畅运行。更改对工作流透明——只需一次指向本地代理，路由会自动处理其余部分。

— Editorial Team