당신은 n8n에서 워크플로우를 구성했으며, 그것은 두 주 동안 작동했지만 이후 403 Forbidden 오류로 지속적으로 중단되기 시작했습니다. 첫 번째 생각은 "사이트가 고장났다" 또는 "자격 증명이 만료되었다"입니다. 그러나 대부분의 경우 문제는 다른 곳에 있습니다: 대상 서버는 요청이 브라우저에서 온 것이 아니라 VPS의 데이터 센터 IP에서 작동하는 자동화에서 온 것임을 인식했습니다. n8n에는 내장된 프록시 메커니즘이 있지만 기본적으로 활성화되어 있지 않으며, 일부 설정은 사람들이 찾는 곳에 존재하지 않습니다.
단계별로 살펴보겠습니다: n8n에서 프록시가 설정되는 위치, self-hosted와 Cloud의 차이점, 그리고 시간을 가장 많이 소모하는 세 가지 함정에 대해 알아보겠습니다.
왜 n8n이 당신의 브라우저보다 더 자주 차단되는가
n8n은 가장 큰 오픈 소스 자동화 플랫폼입니다: GitHub에서 거의 198,000개의 별과 59,600개의 포크를 보유하고 있으며, 게시 시점의 최신 릴리스는 [email protected]입니다 (2026년 7월 24일). 인기도는 역효과를 가지고 있습니다: 안티봇 시스템은 n8n의 네트워크 서명을 잘 알고 있습니다.
세 가지 요인이 결합됩니다:
- User-Agent가 즉시 당신을 드러냅니다. 이것은 추측이 아니라 공식적으로 문서화된 행동입니다. n8n에는
N8N_ENFORCE_GLOBAL_USER_AGENT라는 변수가 있으며 (기본값은false), 문서에서는 이 변수의 목적을 명확히 설명합니다: "맨몸" User-Agent 문자열n8n을 RFC 호환 문자열Mozilla/5.0 (compatible; n8n/<version>; +https://n8n.io/)로 교체하여 웹 애플리케이션 방화벽에 의한 요청 차단을 방지합니다. 이 문제는 버그 리포트로 이어졌습니다: issue #28280 (2026년 4월 10일 개설, 종료됨)에서는 네이티브 노드가 bare-UAn8n을 반환하고 사이트가 "Bad User-Agent" 이유로 403 응답을 반환하는 방법을 설명합니다. HTTP Request 노드는 내부적으로 axios를 사용하며, 수동 헤더 없이 쉽게 인식됩니다. - 서버의 IP는 데이터 센터 IP입니다. n8n은 거의 항상 VPS 또는 클라우드에서 실행됩니다. 이러한 범위는 공개적으로 알려져 있으며 "비사용자"로 표시됩니다: 일부 사이트는 이러한 IP를 더 엄격하게 차단하며, 가정용 연결보다 요청 한도가 현저히 낮습니다.
- 요청 속도가 비인간적입니다. 노드는 하나의 주소에서 초당 수십 개의 요청을 발송하며, 이는 전형적인 속도 제한 트리거 및 이후 IP 차단의 원인입니다.
1단계. 노드 내에서 프록시 설정하기 (Cloud에서도 작동)
가장 빠른 방법은 특정 HTTP Request에 대해 프록시를 설정하는 것입니다:
- HTTP Request 노드를 엽니다.
- 아래에서 Add Option을 클릭하고 Proxy를 선택합니다 — 이는 프록시 서버의 URL을 위한 텍스트 필드입니다.
- 표준 형식으로 인증이 포함된 문자열을 입력합니다:
http://로그인:비밀번호@host:port. - 거기서 헤더 옵션을 추가합니다: Send Headers를 활성화하고 실제 브라우저의
User-Agent를 설정합니다 — Chrome의 DevTools에서 현재 문자열을 수동으로 복사합니다.
이 방법은 n8n Cloud에서 사용할 수 있는 유일한 방법입니다: 그곳에서는 실행 환경을 관리하지 않기 때문에 시스템 환경 변수를 사용할 수 없으며, 나가는 IP는 고정되어 있지 않고 실행할 때마다 변경됩니다. 이 접근 방식의 장점은 세분화입니다: 동일한 워크플로우의 다양한 노드가 서로 다른 프록시 및 서로 다른 지역을 통해 요청할 수 있습니다. 단점은 노드가 20개라면 20곳을 수정해야 한다는 것입니다.
2단계. 환경 변수를 통한 글로벌 프록시 설정 (self-hosted)
자신의 서버에서는 모든 나가는 트래픽을 한 번에 감싸는 것이 더 합리적입니다. n8n은 표준 변수를 읽습니다:
HTTP_PROXY— 노드의 비암호화 HTTP 트래픽을 위한 프록시 URL;HTTPS_PROXY— TLS/SSL 요청을 위한 동일한 것 (실제로는 주요 매개변수입니다);ALL_PROXY— 더 구체적인HTTP_PROXY/HTTPS_PROXY가 설정되지 않았을 때 사용됩니다;NO_PROXY— n8n이 프록시를 우회하여 직접 접근할 호스트 목록 (쉼표로 구분).
docker-compose.yml에서 이는 다음과 같이 보입니다:
HTTPS_PROXY=http://로그인:비밀번호@gate.provider.com:8080NO_PROXY=localhost,127.0.0.1,postgres,n8n.example.comN8N_ENFORCE_GLOBAL_USER_AGENT=true
반드시 NO_PROXY를 채워야 합니다. 그렇지 않으면 외부 프록시를 통해 내부 요청도 전송됩니다 — 당신의 Postgres, 인접한 컨테이너, 자신의 웹훅 도메인에 대한 요청이 포함됩니다. 증상은 "프록시를 활성화한 후 모든 것이 고장났다"는 것이며, 목표 사이트는 오히려 열리기 시작했습니다.
n8n의 버전을 외부에 노출하고 싶지 않다면, RFC 문자열 대신 N8N_GLOBAL_USER_AGENT_VALUE를 통해 자신의 값을 설정하십시오 — 이는 기본값을 덮어씁니다. 컨테이너 트래픽 설정의 일반적인 논리는 다른 시나리오와 동일합니다: 형식 및 함정에 대한 설명은 Docker 컨테이너 프록시 설정 가이드에서 확인할 수 있습니다.
3단계. 저녁 시간을 빼앗는 세 가지 함정
함정 1: 변수 등록이 결정합니다
이것은 명백하지 않으며 거의 모든 튜토리얼에서 다루어지지 않습니다. n8n은 _PROXY로 끝나는 변수를 npm 패키지 proxy-from-env를 통해 처리하며, 이 패키지는 우선 순위를 강제합니다: 소문자 변수가 (http_proxy) 대문자 변수 (HTTP_PROXY)보다 우선합니다, 두 개가 모두 설정된 경우. 고통의 전형적인 시나리오: 시스템에 오래된 https_proxy가 남아 있고, 당신은 compose에서 HTTPS_PROXY를 신중하게 설정했지만, 트래픽은 여전히 이전 주소로 전송됩니다. 두 가지 대소문자를 모두 확인하십시오.
Enterprise를 위한 별도의 세부사항: 라이센스 서버에 대한 요청의 프록시 변수 https_proxy_license_server는 소문자만 사용해야 합니다, 형식은 https://user:pass@proxy:port입니다.
함정 2: Code node는 당신이 생각한 대로 작동하지 않습니다
포럼에서 자주 보이는 조언 — "Code node에서 axios를 통해 프록시 에이전트를 사용하여 요청을 작성하세요". 기본적으로 이는 작동하지 않습니다: n8n은 Code node에서 모듈 가져오기를 비활성화합니다. 이를 명시적으로 허용해야 하며 — 내장 모듈의 경우 NODE_FUNCTION_ALLOW_BUILTIN을, 외부 모듈의 경우 NODE_FUNCTION_ALLOW_EXTERNAL를 사용합니다 (이들은 n8n/node_modules에서 가져옵니다). 추가적인 세부사항: 외부 모드에서 작업 실행기가 있는 경우, 이러한 변수는 컨테이너 환경이 아니라 실행기 구성 /etc/n8n-task-runners.json에서 env-override로 설정됩니다. 기본 옵션인 노드의 프록시를 사용하는 것이 더 쉽고 안전합니다.
함정 3: 프록시는 있지만 속도는 여전히 같다
프록시는 주소를 변경하지만 행동은 변경하지 않습니다. 워크플로우가 여전히 요청을 쏟아낸다면, 새로운 IP를 소모하게 됩니다. 동일한 노드에는 내장된 속도 조절기가 있습니다:
- Batching — Items per Batch (배치당 항목 수) 및 Batch Interval을 밀리초 단위로 설정합니다 (
0= 지연 없음). 1-5의 배치와 1000-3000 ms의 간격을 설정하십시오. - Timeout — 밀리초 단위; 거주 채널은 데이터 센터 채널보다 느리며, 기본값을 높이는 것이 좋습니다.
- Response → Never Error — 첫 번째 403에서 전체 워크플로우를 중단하지 않으며, 응답 코드를 분기하여 처리할 수 있게 합니다.
- Pagination — Update a Parameter 및 Response Contains Next URL 모드를 사용하여 수동 루프 대신 사용합니다.
인스턴스 수준에서 속도는 N8N_CONCURRENCY_PRODUCTION_LIMIT에 의해 제한됩니다 (기본값은 -1, 즉 제한 없음) — 합리적인 값은 프록시 풀과 서버를 모두 보호합니다. 요청을 계산하는 방법과 한도에 대한 자세한 내용은 프록시를 통한 속도 제한 우회 분석에서 확인할 수 있습니다.
n8n에 적합한 프록시 선택하기
선택은 "멋짐"이 아니라, 누가 반대편에 있는지에 따라 달라집니다.
- 데이터 센터 프록시. 저렴하고 빠릅니다. 공식 API, 내부 서비스, 봇에 친숙한 웹사이트 및 단순히 안정적인 정적 주소가 필요한 모든 작업에 적합합니다 — 예를 들어, 귀하의 IP를 파트너의 화이트리스트에 추가하기 위해서입니다. 보안이 강화된 사이트에서는 여전히 동일한 403 오류를 반환합니다: 그들의 범위는 알려져 있습니다. 이는 안티봇 없이 배치 작업의 기초입니다.
- 주거용 프록시. 실제 가정용 제공자의 주소 — 보안이 강한 사이트에서 데이터를 수집하거나 지역에 따라 달라지는 콘텐츠 및 가격 모니터링에 필요합니다. 공개 웹사이트를 대상으로 하는 워크플로우의 경우, 주거용 프록시는 기본적인 선택입니다: 대량 파싱을 위한 요청당 회전 및 노드 체인에서 하나의 세션을 유지해야 할 때 sticky 세션을 사용하십시오.
- 모바일 프록시. 가장 높은 신뢰 수준: 하나의 운영자 뒤에는 수천 명의 실제 가입자가 있으며, 이러한 IP를 차단하는 것은 사이트에 비쌉니다. 가장 엄격하게 차단되는 곳에서 정당화됩니다 — 소셜 미디어 및 메신저 작업. 이에 대한 대가는 속도와 가격입니다.
혼합된 워크플로우에서 실용적인 계획: 공식 API는 직접 또는 데이터 센터를 통해, 공개 웹사이트는 주거용 프록시를 통해, 소셜 미디어는 모바일 프록시를 통해 설정합니다. 각 노드에서 프록시 옵션을 개별적으로 설정할 수 있으므로, 이를 하나의 시나리오에서 조합하는 것은 문제없이 가능합니다.
시작 전 체크리스트
- 프록시가 설정되었습니다 — 노드의 Proxy 옵션을 통해 또는
HTTPS_PROXY를 통해; Cloud에서는 첫 번째 옵션만 사용할 수 있습니다. - 변수의 두 가지 대소문자를 확인했습니다 — 소문자가 대문자를 덮어씁니다.
NO_PROXY는 localhost, 데이터베이스 및 내부 호스트를 차단합니다.- User-Agent가 교체되었습니다:
N8N_ENFORCE_GLOBAL_USER_AGENT=true또는 노드에서 자신의 헤더. 다른 헤더의 일관성을 확인하십시오 — 일관되지 않은 헤더 세트는 자동화를 User-Agent만큼 잘 드러냅니다. - Batching이 비제로 간격으로 활성화되었습니다.
- 3-5 항목에 대해 테스트 실행이 이루어졌으며, 전체 목록이 아닙니다.
결론
n8n에서의 403 오류는 거의 항상 하나의 이유가 아니라 세 가지의 합입니다: 인식 가능한 User-Agent, 데이터 센터 IP 및 너무 일정한 요청 속도. 이는 또한 단일 체크박스가 아니라 세트로 해결됩니다: UA를 변경하고, 필요한 유형의 프록시를 통해 트래픽을 우회하며, Batching을 통해 노드를 느리게 합니다. 이 세 가지 레버는 모두 플랫폼에 내장되어 있으며, 이를 찾고 활성화하는 것만으로 충분합니다.
가장 문제가 많은 노드에는 주거용 채널을, 나머지에는 데이터 센터를 사용하는 것이 가장 간단합니다: ProxyCove에서의 요금은 트래픽에 따라 부과되므로, 테스트를 위해 최소량을 가져가고 귀하의 특정 워크플로우가 어떻게 작동하는지 확인할 수 있습니다. 작업에 적합한 프록시를 선택하고 프록시 필드에 문자열을 입력하는 것은 몇 분이면 가능합니다.
```