Docker에서 n8n을 위한 프록시 밸런싱: DNS 오류 수정

# # Docker에서 n8n을 위한 장애 내성 프록시 로드 밸런싱: DNS 타임아웃 및 액세스 오류 수정

단일 프록시를 통해 n8n을 실행하는 것은 아키텍처 취약점입니다. IP가 차단되거나 프록시 서버가 실패하면 모든 워크플로가 완전히 멈춥니다. 유일한 안정적인 해결책은 자동 페일오버와 라운드-로빈 밸런싱을 지원하는 프록시 풀을 배포하는 것입니다. 이 가이드는 Docker 스택에서 3proxy를 설정하고, 치명적인 DNS 오류와 권한 문제를 해결하며, 전체 체인의 안정성을 확인하는 과정을 안내합니다.

장애 내성 프록시 풀 아키텍처

n8n을 Telegram이나 다른 외부 API에 직접 연결하는 대신, 로컬 3proxy 컨테이너를 게이트웨이로 삽입합니다. 이 컨테이너는 n8n의 HTTP/HTTPS 요청을 3128 포트에서 처리하고, 미리 정의된 외부 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 쿼리가 아무데도 가지 않고 타임아웃을 기다립니다.

수정: nserver 127.0.0.11로 Docker 내부 리졸버로 전환하세요. 이 주소는 모든 컨테이너에서 항상 사용 가능하며 쿼리를 호스트 시스템으로 전달합니다.

오류 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 설정 지시어 순서가 중요: parent 전에 allow *, none 대신 auth iponly.
• IP 유출 방지가 필수: 전체 프록시 실패 시 직접 트래픽 차단을 위한 deny 0.0.0.0/0.
• 라운드-로빈 밸런싱은 3proxy에 내장—추가 도구나 스크립트 불필요.

이 설정은 부분적인 인프라 실패 시에도 n8n을 원활하게 유지합니다. 워크플로에 변경 없이 로컬 프록시를 한 번만 가리키면 나머지는 자동으로 라우팅됩니다.

— Editorial Team