“요청이 시간 초과됩니다”는 저희가 받는 가장 흔한 지원 문의 중 하나이며, 동시에 가장 구체성이 떨어지는 문의이기도 합니다. 타임아웃은 증상이지 원인이 아닙니다. 게이트웨이가 일치하는 종료 IP를 찾지 못했든, 8초가 필요한 연결에서 클라이언트가 5초 만에 포기했든, 대상 사이트가 느리든, 컨테이너 설정이 잘못되어 프록시에 아예 도달하지 못했든 동일한 오류가 나타납니다.
이 글은 진단 가이드입니다. 이 중 실제로 어떤 일이 일어나고 있는지 가장 빠르게 찾아내는 순서를 다룹니다. 이는 지연 시간 줄이기의 짝이 되는 글입니다. 그 글이 작동하는 설정을 더 빠르게 만드는 방법을 다룬다면, 이 글은 멈추거나 실패하는 설정과 그 이유를 다룹니다.
0단계: 정말로 타임아웃인가?
진단에 앞서 정확히 분류해야 합니다. “시간 초과”로 보고되는 세 가지 서로 다른 실패가 있으며, 각각 해결 방법이 다르기 때문입니다:
- 연결 타임아웃(Connect timeout) — 클라이언트가 게이트웨이와 아예 연결을 맺지 못한 경우입니다. 이는 사용자 측 문제를 가리킵니다: 네트워크 아웃바운드, 방화벽, 잘못된 호스트/포트, 또는 컨테이너 설정 문제입니다.
- 읽기/응답 타임아웃(Read / response timeout) — 연결은 정상적으로 이루어지고 요청도 전송되었지만, 제시간에 응답이 돌아오지 않은 경우입니다. 이는 종료 지점이나 대상을 가리킵니다: 일치하는 IP가 없거나, 종료 디바이스가 느리거나, 대상 사이트가 느린 경우입니다.
- 타임아웃이 아예 아닌 경우 —
407(인증),502(필터에 맞는 IP 없음), 또는 멈춰버린 CAPTCHA 페이지입니다. 이런 경우 모든 예외를 하나로 처리하는 래퍼 코드에 의해 종종 타임아웃으로 보고됩니다.
대부분의 클라이언트는 연결 타임아웃과 읽기 타임아웃을 명시적으로 분리할 수 있게 해줍니다. 이렇게 하는 것이 가장 가치 있는 단일 진단 단계이며, 보통 한 줄만 바꾸면 됩니다:
import requests
# (connect_timeout, read_timeout) - 분리하세요, 하나의 숫자로 전달하지 마세요r = requests.get(url, proxies=proxies, timeout=(10, 30))처음 10초 이내에 실패한다면 연결 문제입니다. 연결은 통과했는데 30초에 죽는다면 읽기 문제입니다. 해당하는 섹션을 계속 읽어보세요.
원인 1: 지역 필터가 너무 좁음
이것이 가장 흔한 실제 원인이며, 가장 쉽게 고칠 수 있습니다.
모든 타겟팅 플래그는 적격 종료 IP 풀을 좁힙니다. country-us는 매우 큰 집합에서 선택합니다. country-us-city-scranton-asn-12345는 거의 아무것도 선택하지 못할 수 있습니다. 일치하는 종료 지점이 거의 또는 전혀 없으면 요청은 대기하다가 실패하며, 클라이언트에 따라 이는 타임아웃 또는 502로 나타납니다.
진단은 플래그를 하나씩 완화해가며 확인합니다:
# 국가만 지정했을 때 작동하는가?curl -x customer-USER-country-us:PASS@p.shifter.io:443 https://api.ipify.org --max-time 30
# 도시를 다시 추가하고 비교curl -x customer-USER-country-us-city-chicago:PASS@p.shifter.io:443 https://api.ipify.org --max-time 30국가만 지정했을 때는 성공하고 더 좁은 필터에서는 시간 초과가 발생한다면 원인을 찾은 것입니다. 해결책: 데이터에 실제로 필요한 정밀도만 유지하세요. 사용 사례상 정말로 해당 도시가 필요하다면, 더 작은 풀과 더 낮은 처리량을 예상하고 그에 맞게 계획을 세우세요(도시 단위 타겟팅이 중요한 경우에서 그럴 가치가 있는 경우를 다룹니다).
원인 2: 타임아웃이 데이터센터 기준으로 설정되어 있음, 레지덴셜이 아니라
거의 근소한 두 번째 원인이며, 실제로는 전혀 문제가 없던 요청에서 “타임아웃”을 만들어냅니다.
레지덴셜 트래픽은 가정 네트워크의 실제 소비자 기기를 경유하므로 데이터센터 프록시에는 없는 지연 시간 하한선이 존재합니다(레지덴셜 vs 데이터센터). 데이터센터에는 완전히 합리적인 5초 총 타임아웃이 정상적인 레지덴셜 요청을 도중에 끊어버리고 실패로 보고할 수 있습니다.
진단은 조정하기 전에 먼저 측정하는 것입니다: 프록시를 통한 실제 대상에 대해 p50 및 p95 지연 시간을 수집하세요(레지덴셜 프록시 속도, 성공률, 위치 정확도 테스트 방법에 방법이 나와 있습니다). 타임아웃이 p95보다 낮게 설정되어 있다면 스스로 실패를 만들어내고 있는 것입니다.
해결책: 추측이 아니라 측정된 p95보다 여유를 두고 타임아웃을 설정하세요. 시작점으로, 레지덴셜의 경우 연결 타임아웃 약 10초, 읽기 타임아웃 30초 이상이 합리적입니다. 이후 자신의 수치에 맞게 조정하세요.
원인 3: 프록시가 아니라 대상이 느림
확인하기 쉽지만 오판하기도 쉽습니다. 동일한 프록시를 통해 빠르고 중립적인 엔드포인트와 실제 대상에 대해 동일한 요청 경로의 시간을 측정하세요:
# 중립적인 엔드포인트 - 프록시 오버헤드를 측정requests.get("https://api.ipify.org", proxies=proxies, timeout=(10, 30))
# 실제 대상 - 프록시 오버헤드 + 대상 지연 시간을 측정requests.get("https://your-target.example/page", proxies=proxies, timeout=(10, 30))중립적인 엔드포인트는 빠른데 대상은 느리다면, 프록시는 문제가 아니며 아무리 프록시를 조정해도 해결되지 않습니다. 해당 대상에 대한 읽기 타임아웃을 늘리거나, 페이지에서 가져오는 양을 줄이세요.
원인 4: 동시성이 너무 높음
부하 상태에서만 나타났다가 단일 요청으로 테스트하면 사라지는 타임아웃은 여기에 해당합니다.
두 가지 메커니즘이 있습니다: 로컬 리소스(연결 풀 슬롯, 파일 디스크립터, 이벤트 루프 용량)를 소진하여 요청이 사용자 측을 벗어나기도 전에 대기열에 쌓이는 경우이거나, 대상이 요청 속도를 제한하면서 깔끔한 429 대신 멈추는 방식으로 응답하는 경우입니다.
진단은 동시성을 1로 낮추고 재테스트하는 것입니다. 타임아웃이 사라진다면 부하와 관련된 것입니다. 해결책: 전역 단일 숫자가 아니라 호스트별 동시성 제한을 적용하세요. 이는 프록시 로드 밸런싱에서 다루는 아키텍처입니다.
원인 5: 연결 처리
정반대되는 두 가지 실수가 모두 타임아웃을 유발합니다:
연결 재사용이 없는 경우. 요청마다 새 연결을 생성한다는 것은 매번 프록시를 통해 전체 TCP + TLS 핸드셰이크 비용을 지불한다는 의미이며, 이는 느리고 타임아웃 여유를 훨씬 줄어들게 만듭니다. 풀링을 지원하는 세션/클라이언트를 사용하세요.
오래된 풀링 연결. 연결을 풀링하지만 요청마다 종료 IP를 로테이션한다면, 풀링된 소켓이 더 이상 유효하지 않은 종료 지점을 가리킬 수 있고 그 연결은 멈춰버립니다. 풀링된 연결이 하나의 종료 지점에 유지되도록 스티키 세션과 함께 사용하고, 연결을 주기적으로 재활용하세요.
원인 6: 종료 디바이스 자체
레지덴셜 종료 지점은 실제 가정 네트워크의 실제 소비자 기기입니다. 일부는 혼잡한 회선에 있고, 일부는 모바일이며, 일부는 요청 도중 끊어지기도 합니다. 레지덴셜에서 느리거나 실패한 요청의 작은 비율은 결함이 아니라 정상이며 예상되는 현상입니다.
해결책: 가장 나쁜 디바이스에 맞추려고 타임아웃을 늘리지 마세요, 그러면 모든 실패가 더 느려질 뿐입니다. 빠르게 실패하고 새로운 아이덴티티로 재시도하세요, 그러면 다른 종료 지점을 얻게 됩니다. 장애 조치 가이드에서는 전송 실패를 분류하고 올바르게 재시도하는 방법을 다룹니다. 풀의 품질이 이 꼬리 부분이 얼마나 두꺼운지를 결정합니다(IP 평판).
원인 7: 애초에 프록시에 도달하지 못함
모든 것이 시간 초과되는 경우, 특히 컨테이너 환경에서는 초기에 확인해볼 가치가 있습니다.
요청이 실제로 게이트웨이를 통해 나가고 있는지 확인하세요:
curl -x customer-USER-country-us:PASS@p.shifter.io:443 https://api.ipify.org# 레지덴셜 IP를 반환함 -> 프록시가 작동 중.# 자신의 IP를 반환함 -> 클라이언트가 프록시를 무시하고 있음.# 완전히 멈춤 -> 로컬 아웃바운드가 차단됨 (방화벽, VPN, 회사 네트워크).Docker와 Kubernetes에서는 이것이 흔한 원인입니다: 클라이언트가 HTTP_PROXY를 전혀 준수하지 않거나, NO_PROXY가 잘못 설정되었거나, 컨테이너 내부에서 localhost가 생각하는 것과 다른 의미를 갖는 경우입니다. Docker 설정 가이드에서 이런 경우를 구체적으로 다룹니다.
원인 8: 인증 또는 자격 증명 오류가 위장된 경우
타겟팅 플래그의 오타나 지원되지 않는 매개변수 등 잘못된 형식의 사용자 이름이나 잘못된 자격 증명은 클라이언트가 407을 처리하는 방식에 따라 멈춤이나 일반적인 실패로 나타날 수 있습니다. 가장 느슨한 설정으로도 여전히 실패한다면, 네트워크 문제라고 가정하기 전에 자격 증명 문자열을 한 글자씩 확인하세요.
진단 순서
다음을 순서대로 실행하세요. 각 단계는 큰 범주의 원인을 제거해줍니다:
- 연결과 읽기 타임아웃을 분리하세요. 연결 실패는 사용자 측 문제를 의미하고, 읽기 실패는 종료 지점이나 대상 문제를 의미합니다.
- 애초에 프록시를 경유하고 있는지 확인하세요 (위의 ipify 확인).
country만으로 테스트하세요. 이것이 작동한다면 지역 필터가 너무 좁았던 것입니다.- 중립적인 엔드포인트와 대상을 비교하세요. 프록시 오버헤드와 대상의 느림을 분리해줍니다.
- 동시성을 1로 낮추세요. 타임아웃이 사라진다면 프록시가 아니라 부하 문제입니다.
- 측정된 p95와 타임아웃을 비교하세요. 타임아웃이 그보다 낮다면 스스로 실패를 만들어내고 있는 것입니다.
여섯 가지 점검이며, 실제로는 이 중 하나가 저희가 접하는 타임아웃 보고의 거의 전부를 설명합니다.
타임아웃이 실제로 괜찮은 경우
작은 비율의 느리고 실패한 요청은 레지덴셜 프록시에 본질적으로 내재된 것입니다. 실제 소비자 기기는 본질적으로 변동성이 있기 때문입니다. 점점 더 긴 타임아웃으로 100% 성공률을 추구하는 것은 잘못된 목표이며, 실패를 줄이지 못한 채 실패를 더 느리게 만들 뿐입니다.
올바른 목표는 SLO입니다: 작업 부하에 대해 허용 가능한 성공률과 p95를 정의하고, 꼬리 부분에서는 빠르게 실패시키고, 새로운 아이덴티티로 재시도하세요. 요청을 30초 만에 실패시키고 재시도로 성공하는 파이프라인이, 120초를 기다리며 희망을 거는 파이프라인보다 더 건강합니다.
자주 묻는 질문
도시나 ASN 필터를 사용하면 타임아웃이 발생하는데 국가만 사용하면 발생하지 않는 이유는 무엇인가요? 각 플래그가 적격 종료 풀을 좁히기 때문입니다. 국가 + 도시 + ASN을 함께 사용하면 일치하는 IP가 매우 적게 남을 수 있어 요청이 대기하다 실패합니다. 데이터에 실제로 필요한 정밀도로 완화하고, 정말로 정밀한 타겟팅이 필요할 때는 더 낮은 처리량을 예상하세요.
레지덴셜 프록시에는 어떤 타임아웃 값을 사용해야 하나요? 먼저 측정하세요: 타임아웃은 관찰된 p95보다 여유를 두고 설정해야 합니다. 시작점으로, 레지덴셜의 경우 대략 연결 10초, 읽기 30초 이상이 합리적이며, 이후 자신의 수치로 조정하세요. 데이터센터 기준으로 조정된 타임아웃은 정상적인 레지덴셜 요청을 끊어버립니다.
프록시가 느린지 대상이 느린지 어떻게 구분하나요? 동일한 프록시를 통해 빠른 중립 엔드포인트와 실제 대상의 시간을 측정하세요. 중립 엔드포인트는 프록시 오버헤드를 측정합니다. 그 차이가 대상 자체의 지연 시간입니다. 중립 엔드포인트가 빠르다면 프록시는 문제가 아닙니다.
단순한 요청조차 모든 것이 시간 초과됩니다. 무엇이 잘못되었나요? 프록시에 아예 도달하고 있는지 확인하세요: IP 에코 엔드포인트를 통해 curl로 확인하세요. 자신의 IP가 나온다면 클라이언트가 프록시를 무시하는 것이고, 완전히 멈춘다면 로컬 아웃바운드가 차단된 것입니다(방화벽, VPN, 컨테이너 설정). 그다음 자격 증명과 플래그를 확인하세요.
그냥 타임아웃을 늘려야 할까요? 대개는 아닙니다. 원인이 좁은 지역 필터, 느린 대상, 또는 나쁜 종료 디바이스라면 타임아웃을 늘리는 것은 실패에 걸리는 시간만 늘릴 뿐입니다. 원인을 고치고, 피할 수 없는 꼬리 부분에 대해서는 빠르게 실패시키고 새 아이덴티티로 재시도하세요.
결론
타임아웃은 최소 여덟 가지의 서로 다른 원인을 가진 증상이며, 해결책은 전적으로 어떤 원인인지에 달려 있습니다. 연결과 읽기를 분리하고, 실제로 프록시를 경유하고 있는지 확인하고, 지역 필터를 완화하고, 대상의 느림과 프록시 오버헤드를 분리하고, 동시성 1에서 테스트하고, 측정된 p95와 타임아웃을 비교하세요. 이 순서를 따르면 대다수의 경우가 해결되며, 보통 몇 분이면 충분합니다.
그리고 꼬리 부분은 받아들이세요: 레지덴셜 종료 지점은 실제 기기이므로, 어느 정도의 변동성은 실제 사용자 신뢰를 얻는 대가입니다. 빠르게 실패시키고, 새로운 아이덴티티로 재시도하고, 요청이 시간 초과되는지 여부가 아니라 성공률과 p95로 설정을 평가하세요. 여섯 가지 점검 후에도 여전히 막혀 있다면 레지덴셜 게이트웨이 문서와 저희 팀이 원인을 좁히는 데 도움을 드릴 수 있습니다. 연결/읽기 분리 결과와 실패한 자격 증명 문자열 샘플을 함께 가져오시면 대개 빠르게 답을 드릴 수 있습니다.