일반적인 프록시 오류 및 해결 방법

프록시 오류는 스크래핑, SEO 모니터링, 가격 추적, 광고 검증 및 브라우저 자동화 워크플로우에 조용히 피해를 줄 수 있습니다. 작업이 실행 중인 것처럼 보일 수 있지만, 이면에서는 요청이 시간 초과되고, 세션이 재설정되며, 페이지가 소프트 블록을 반환하거나, 지리적으로 타겟팅된 결과가 잘못된 위치에서 발생할 수 있습니다.

가장 일반적인 프록시 오류는 보통 인증 문제, 속도 제한, 차단된 IP 범위, TLS 또는 DNS 불일치, 불안정한 프록시 경로, 세션 불일치 또는 요청 속도 저하에서 발생합니다. 해결책이 항상 "다른 프록시를 사용하라"는 것은 아닙니다. 신뢰할 수 있는 설정은 올바른 자격 증명, 더 나은 라우팅, 깔끔한 세션 설계, 백오프, 콘텐츠 검증 및 파이프라인이 실제로 개선되고 있는지를 보여주는 메트릭을 필요로 합니다.

웹 스크래핑 프록시를 사용하는 팀의 목표는 간단합니다: 실패한 요청을 줄이고, 유효한 출력을 개선하며, 성공적인 요청당 비용을 낮추는 것입니다.

간단한 답변: 프록시 오류가 발생하는 이유

프록시 오류는 요청 경로의 한 레이어가 실패하거나 일관성이 없을 때 발생합니다.

그 레이어는 다음과 같을 수 있습니다:

• 프록시 인증
• IP 평판
• 요청 볼륨
• 세션 쿠키
• DNS 해상도
• TLS 핸드셰이크
• 브라우저 지문
• 타겟 측 속도 제한
• 지리적 라우팅
• 프록시 풀 상태

407 오류는 일반적으로 프록시 인증을 나타냅니다. 429는 속도 제한을 나타냅니다. 403은 타겟이 경로 또는 세션을 차단했음을 의미할 수 있습니다. 시간 초과 및 502/504 오류는 종종 불안정한 업스트림 경로를 나타냅니다. CAPTCHA 또는 중간 페이지는 일반적으로 타겟이 트래픽, 지문 또는 세션 신호에 따라 마찰을 적용하고 있음을 의미합니다.

프록시 오류를 수정하는 가장 좋은 방법은 먼저 실패한 레이어를 식별한 다음, 가장 작은 목표 수정 사항을 적용하는 것입니다.

프록시 오류 진단 표

이 표를 첫 번째 가이드로 사용하세요.

모든 오류를 동일하게 처리하지 마세요. 407, 429 및 소프트 블록은 서로 다른 응답을 요구합니다.

407 프록시 인증 필요

407 오류는 프록시 서버가 인증 실패로 인해 요청을 거부했음을 의미합니다.

일반적인 원인은 다음과 같습니다:

• 잘못된 사용자 이름
• 잘못된 비밀번호
• 만료된 토큰
• 잘못된 프록시 포트
• 누락된 인증 헤더
• 허용 목록에 없는 IP
• 잘못된 프록시 URL
• SOCKS 엔드포인트에서 HTTP 자격 증명 사용
• 비밀 회전이 올바르게 배포되지 않음

407 오류 수정 방법

신뢰할 수 있는 클라이언트를 사용하여 간단한 단일 요청 테스트로 시작하세요. 프록시 호스트, 포트, 사용자 이름, 비밀번호 및 프로토콜을 확인하세요.

확인해야 할 사항:

• 자격 증명 형식
• 엔드포인트 유형
• 인증 방법
• 토큰 만료
• 계정 상태
• IP 허용 목록
• 환경 변수
• 애플리케이션 비밀 저장소

인증이 IP 기반인 경우 요청이 예상 서버 IP에서 오는지 확인하세요. 인프라가 자동 확장되었거나 클라우드 지역이 변경된 경우 아웃바운드 IP가 변경되었을 수 있습니다.

모니터링할 사항

환경, 배포 및 프록시 계정별로 407 비율을 추적하세요. 갑작스러운 급증은 일반적으로 구성 변화, 만료된 자격 증명 또는 배포 문제를 의미합니다.

403 금지됨

403은 대상 서버가 접근을 거부했음을 의미합니다. 이는 권한, 대상 측 차단, IP 평판, 브라우저 지문 문제 또는 요청 패턴 문제로 인해 발생할 수 있습니다.

일반적인 원인은 다음과 같습니다:

• 차단된 프록시 범위
• 데이터 센터 ASN 플래그 지정
• 필요한 헤더 누락
• 유효하지 않은 세션 쿠키
• 지원되지 않는 국가 또는 지역
• 공격적인 요청 비율
• 대상을 감지하는 자동화
• 사이트 정책에 의해 제한된 접근

403 오류 수정 방법

먼저 페이지가 일반 브라우저를 통해 접근 가능한지, 그리고 귀하의 워크플로우가 허용되는지 확인하세요. 페이지에 로그인이 필요한 경우 세션이 유효한지 확인하세요.

그런 다음 원인을 분리하세요:

• 클린 클라이언트에서 단일 요청 테스트.
• 데이터 센터와 주거지 경로 비교.
• 동시성 낮추기.
• 헤더와 쿠키 확인.
• 지역 및 언어 설정 유효성 검사.
• 반환된 콘텐츠가 하드 블록인지 소프트 블록인지 검토.

데이터 센터 범위를 차단하는 공개 페이지의 경우, 주거지 프록시가 성공률을 높일 수 있습니다. 관용적인 대상을 위해서는 데이터 센터 프록시가 여전히 더 비용 효율적일 수 있습니다.

더 넓은 라우팅 결정을 위해서는 데이터 센터 vs 주거지 vs ISP 프록시 설명를 참조하세요.

401 권한 없음

401은 일반적으로 대상이 유효한 인증을 요구하며 귀하의 요청이 이를 제공하지 않았음을 의미합니다.

일반적인 원인은 다음과 같습니다:

• 만료된 로그인 세션
• 누락된 베어러 토큰
• 유효하지 않은 API 키
• 쿠키가 유지되지 않음
• 로그인 흐름이 깨짐
• 세션이 이전 IP에 묶여 있음
• 계정이 재인증을 요구함

401 오류 수정 방법

API 워크플로우의 경우, 토큰을 새로 고치고 인증 헤더를 확인하세요.

브라우저 워크플로우의 경우, 쿠키, 로컬 저장소 및 세션 상태를 유지하세요. 대상이 로그인 상태를 네트워크 ID에 바인딩하는 경우 세션 중간에 IP를 회전하지 마세요.

계정 기반 워크플로우에는 스티키 또는 정적 세션을 사용하세요. 라우트 동작에 대한 자세한 내용은 회전 vs 정적 프록시를 참조하세요.

429 요청이 너무 많음

429는 대상이 작업 부하를 속도 제한하고 있음을 의미합니다.

일반적인 원인은 다음과 같습니다:

• 한 IP에서 너무 많은 요청
• 한 서브넷에서 너무 많은 요청
• 도메인당 높은 동시성
• 급격한 스케줄링
• 재시도 폭풍
• 높은 마찰 엔드포인트에 대한 반복 접근
• 오류 후 백오프 없음

429 오류 수정 방법

더 부드러운 트래픽 쉐이핑을 사용하세요.

추천 수정 사항:

• 도메인당 동시성 줄이기
• 무작위 지터 추가
• 지수 백오프 사용
• 작업을 더 긴 시간에 분산
• 안정적인 응답 캐시
• 즉시 재시도 피하기
• 높은 위험 엔드포인트와 낮은 위험 페이지 분리
• 워크플로우가 허용할 때만 회전

단순히 더 많은 재시도를 추가하지 마세요. 깊은 재시도는 비용을 증가시키고 속도 제한을 악화시킬 수 있습니다.

모니터링할 사항

재시도 깊이, 차단 비율 및 CPSR을 추적하세요.

CPSR은 성공적인 요청당 비용을 의미합니다. 간단히 말해, CPSR은 프록시 비용, 컴퓨팅, 재시도 및 실패 후 각 유효 결과의 비용을 알려줍니다.

429 오류가 감소하지만 CPSR이 상승하는 경우, 수정이 효율적이지 않을 수 있습니다.

502 및 504 게이트웨이 오류

502 또는 504 오류는 일반적으로 클라이언트, 프록시 제공업체 및 대상 서버 간의 업스트림 문제를 나타냅니다.

일반적인 원인에는 다음이 포함됩니다:

• 불안정한 프록시 종료
• 과부하된 경로
• 대상 서버 지연
• 프록시 체인 실패
• 지역 라우팅 문제
• 타임아웃이 너무 짧음
• 불량 업스트림 연결

502 및 504 오류 수정 방법

백오프가 있는 제한된 재시도를 사용하세요. 무한정 재시도하지 마세요.

추천 수정 사항:

• 지연을 두고 1-2회 재시도
• 반복적인 실패 후 프록시 경로 변경
• 지역 및 프록시 풀에 따라 모니터링
• 실패하는 종료를 격리
• 대상이 일반적으로 느린 경우에만 타임아웃 증가
• 영향을 받는 도메인에서 동시성 감소
• 네트워크 오류를 대상 차단과 분리

무거운 JavaScript 페이지에서 504 오류가 발생하면 간단한 정적 HTML 페이지와는 다른 타임아웃이 필요할 수 있습니다.

연결 타임아웃 및 ECONNRESET

타임아웃 및 연결 재설정은 연결이 완료되지 않거나 예기치 않게 닫힐 때 발생합니다.

일반적인 원인에는 다음이 포함됩니다:

• 죽은 프록시 종료
• 과부하된 대상
• 불안정한 네트워크 경로
• 차단된 연결
• 열린 소켓이 너무 많음
• 타임아웃 설정이 너무 공격적임
• 대상에서 너무 먼 프록시 경로
• 대상이 의심스러운 세션을 닫음

타임아웃 수정 방법

연결 타임아웃과 읽기 타임아웃을 분리하는 것부터 시작하세요. 설정할 수 없는 연결은 느린 페이지 응답과 다릅니다.

추천 수정 사항:

• 대상에 더 가까운 지역 프록시 경로 사용
• 연결 타임아웃 단축
• 현실적인 읽기 타임아웃 설정
• 반복적인 실패 후 종료 회전
• 작업자당 열린 연결 수 제한
• p95 대기 시간 모니터링
• 높은 실패율의 프록시 종료 격리

브라우저 자동화의 경우, 브라우저 충돌 및 탐색 타임아웃도 별도로 모니터링하세요.

TLS 및 SSL 오류

TLS 오류는 보안 연결 설정 중에 발생합니다.

일반적인 원인에는 다음이 포함됩니다:

• SNI 불일치
• 지원되지 않는 TLS 버전
• 인증서 검증 실패
• 구식 클라이언트 라이브러리
• ALPN 불일치
• 현대 암호 지원을 요구하는 대상
• 잘못된 프록시 프로토콜을 통해 전송된 HTTPS 요청

TLS 오류 수정 방법

요청이 올바른 호스트 이름과 프로토콜을 사용하는지 확인하세요. 필요한 경우 프록시 유형이 HTTPS 터널링을 지원하는지 확인하세요.

추천 확인 사항:

• SNI가 대상 호스트 이름과 일치하는지 확인
• HTTP 클라이언트 또는 브라우저 런타임 업데이트
• 현대 TLS 버전 사용
• 구식 암호 설정 피하기
• 인증서 검증 동작 확인
• 일반 브라우저 요청과 비교

TLS 동작은 봇 탐지에도 기여할 수 있습니다. User-Agent가 Chrome이라고 주장하지만 TLS 프로필이 Chrome과 유사하지 않으면 대상이 세션을 신뢰하지 않을 수 있습니다.

브라우저 및 클라이언트 일관성 문제에 대해서는 웹 스크래핑을 위한 브라우저 지문 인식을 검토하세요.

DNS 해상도 오류

DNS 오류는 대상 호스트 이름을 해석할 수 없거나 잘못 해석되고 있음을 의미합니다.

일반적인 원인에는 다음이 포함됩니다:

• 불량 DNS 해석기
• 지역 DNS 불일치
• 분할 수평 DNS
• 차단된 DNS 경로
• 오래된 캐시된 기록
• IPv6/IPv4 불일치
• 예상 해석기를 우회하는 프록시

DNS 오류 수정 방법

신뢰할 수 있는 해석기를 사용하고 요청을 보내는 동일한 런타임 내에서 DNS 동작을 검증하세요.

추천 수정 사항:

• 대상 호스트 이름 해석 확인
• 프록시 경로에서 테스트
• DNS 지역을 프록시 지역과 일치시킴
• 오래된 DNS 캐시 지우기
• 기록을 임시로만 고정
• 지역별 DNS 실패 모니터링

지리적으로 민감한 워크플로에서는 해석기 위치가 반환된 콘텐츠에 영향을 미칠 수 있기 때문에 DNS가 중요합니다.

CAPTCHA 및 인터스티셜 페이지

CAPTCHA 또는 인터스티셜 페이지는 일반적으로 대상이 마찰을 적용하고 있음을 의미합니다.

• 높은 요청 비율
• 의심스러운 IP 평판
• 브라우저 지문 불일치
• 세션 기록 없음
• 너무 많은 재시도
• 지리적 불일치
• WebRTC 또는 DNS 유출
• 비정상적인 탐색 행동

CAPTCHA 빈도 줄이는 방법

목표는 예방이며, 회피가 아닙니다.

추천 수정 사항:

• 동시성 줄이기
• 도전 후 백오프 추가
• 적절한 경우 스티키 세션 사용
• 프록시 지역, 시간대 및 언어 정렬
• 세션 워크플로우를 위한 쿠키 보존
• 브라우저 프로필 일관성 검증
• 재시도 폭풍 피하기
• 가능한 경우 승인된 API 또는 피드 사용

CAPTCHA 프롬프트가 거의 모든 요청에 나타나면, 더 강하게 밀어붙이기보다는 워크플로우를 재평가하세요.

WebRTC 관련 문제에 대해서는 WebRTC 유출: 왜 안티-디텍트 설정을 깨는가를 참조하세요.

지리적 불일치 오류

지리적 불일치는 프록시 위치, 브라우저 설정, 대상 상점 또는 반환된 콘텐츠가 일치하지 않을 때 발생합니다.

예시:

• 프록시가 한 국가에서 종료되지만 콘텐츠는 다른 국가를 보여줌
• 도시 수준의 SEO 결과가 잘못된 지역에서 나옴
• 가격이 잘못된 통화로 표시됨
• 배송 옵션이 대상 지역과 일치하지 않음
• 시간대가 IP 위치와 충돌함
• 쿠키가 오래된 지역을 포함함

지리적 불일치 수정 방법

프록시 제공업체 레이블만 의존하지 마세요. 반환된 콘텐츠를 검증하세요.

확인 사항:

• 통화
• 언어
• 로컬 팩 주소
• 상점 위치
• 배송 지역
• 페이지 URL
• 국가 배너
• 지역화된 스니펫

로컬 SEO 및 지리적 모니터링을 위해, 주거용 경로가 더 신뢰할 수 있는 경우가 많습니다. 주거용 프록시를 통한 로컬 SEO 모니터링를 참조하세요.

소프트 블록: 프록시 오류 팀이 놓치는 것

소프트 블록은 페이지가 성공적으로 반환되지만 콘텐츠가 유효하지 않을 때 발생합니다.

예시:

• HTTP 200과 CAPTCHA 콘텐츠
• 가격이 없는 제품 페이지
• 유기적 결과가 없는 SERP 페이지
• 일반 오류 템플릿
• 빈 재고 데이터
• 잘못된 지역 페이지
• 자리 표시자 콘텐츠
• 반복된 동일한 응답

소프트 블록은 실제 데이터로 대시보드에 들어갈 수 있기 때문에 위험합니다.

소프트 블록 감지 방법

성공을 계산하기 전에 콘텐츠 구조를 검증하세요.

가격 모니터링을 위해 확인하세요:

• 제품 제목
• SKU
• 가격
• 통화
• 가용성
• 지역

SEO 모니터링을 위해 확인하세요:

• 유기적 결과 수
• 로컬 팩 데이터
• 대상 위치
• 예상 SERP 기능

스크래핑 파이프라인을 위해 필요한 필드와 스키마 규칙을 확인하세요.

측정할 사항

프록시 신뢰성은 원시 요청이 아닌 유효한 출력을 통해 측정해야 합니다.

이들을 도메인, 경로, 프록시 유형, 지역 및 작업량별로 추적하세요.

결정 프레임워크: 올바른 레이어 수정

문제를 해결할 때 이 경로를 사용하세요.

1. 인증 오류? 자격 증명, 허용 목록, 포트 및 비밀 회전을 수정하세요.

2. 요율 제한 오류? 동시성을 줄이고, 지터를 추가하고, 백오프를 적용하세요.

3. 네트워크 오류? 경로 건강, 타임아웃, DNS 및 지역 대기 시간을 확인하세요.

4. TLS 또는 프로토콜 오류? 클라이언트 버전, SNI, ALPN 및 인증서 동작을 검증하세요.

5. 하드 차단? 프록시 유형, 헤더, 브라우저 지문 및 요청 타이밍을 검토하세요.

6. 소프트 차단? 페이지 내용 및 파서 기대치를 검증하세요.

7. 지리적 불일치? 프록시 위치, 브라우저 로케일, 쿠키 및 대상 상점을 정렬하세요.

이렇게 하면 문제 해결에 집중할 수 있습니다.

실제 사례: 전자상거래 가격 모니터링

가격 팀은 수천 개의 제품 페이지를 모니터링합니다. 시스템은 갑작스러운 가격 누락 증가를 보고합니다.

처음에 팀은 소매업체가 레이아웃을 변경했다고 가정합니다. 그러나 실패 샘플은 빈 제품 컨테이너와 함께 HTTP 200 응답을 보여줍니다. 문제는 소프트 차단입니다.

수정 사항은 다음과 같습니다:

• 동시성 감소
• 민감한 제품 페이지를 주거용 프록시로 전환
• 지역 상점 확인을 위한 스티키 세션 사용
• 기록 저장 전에 가격 및 통화 검증
• 파서 실패 시 HTML 샘플 캡처

누락된 가격 비율이 감소하고 CPSR이 개선됩니다. 재시도가 줄어듭니다.

실제 사례: SEO 순위 추적

SEO 플랫폼은 수백 개의 위치에서 도시 수준의 SERP를 수집합니다.

보고서에는 불안정한 지역 순위가 나타납니다. 조사를 통해 팀은 일부 프록시 경로가 정확한 목표 도시 결과 대신 인근 도시 결과를 반환한다는 것을 발견합니다.

수정 사항은 다음과 같습니다:

• 지역 팩 주소 검증
• 지리적 정확도 플래그 기록
• 주거용 프록시 라우팅 강화
• Accept-Language 및 검색 매개변수 정렬
• 광범위한 국가 검사를 지역 검사와 분리

결과는 더 깨끗한 순위 데이터와 더 적은 잘못된 순위 변경입니다.

피해야 할 일반적인 실수

모든 오류를 동일한 방식으로 재시도하기

407, 429, 타임아웃 및 소프트 차단은 서로 다른 응답이 필요합니다.

소프트 차단 무시하기

성공적인 상태 코드는 데이터가 유효하다는 것을 의미하지 않습니다.

IP를 너무 자주 회전하기

과도한 회전은 세션 신뢰 및 쿠키를 깨뜨릴 수 있습니다.

모든 곳에서 프리미엄 프록시 사용하기

유효한 출력을 개선하는 곳에서는 주거용 또는 ISP 경로를 사용하세요. 관대한 페이지에는 데이터 센터 경로를 유지하세요.

DNS 및 TLS 잊기

라이브러리 업데이트 또는 인프라 변경 후 DNS 및 TLS 동작이 변경될 수 있습니다.

계측 없이 확장하기

성공률, 차단률, 대기 시간 및 CPSR이 측정되기 전까지 볼륨을 늘리지 마세요.

모범 사례 체크리스트

프록시 기반 워크플로를 확장하기 전에:

• 자격 증명 및 프록시 엔드포인트 구성을 확인하세요.
• 오류를 유형별로 분류하세요.
• 성공률, 차단률, 소프트 차단률 및 CPSR을 추적하세요.
• 도메인별 동시성 한도를 사용하세요.
• 재시도 예산 및 지수 백오프를 추가하세요.
• 데이터를 저장하기 전에 내용을 검증하세요.
• 다단계 워크플로를 위해 스티키 세션을 사용하세요.
• 프록시 지역을 브라우저 로케일 및 대상 상점과 정렬하세요.
• DNS 및 TLS 실패를 모니터링하세요.
• 나쁜 프록시 종료를 격리하세요.
• 디버깅을 위해 실패 샘플을 저장하세요.
• 클라이언트 또는 브라우저 업데이트 후 재테스트하세요.

설정 지원을 위해 SquidProxies 프록시 튜토리얼 및 더 넓은 프록시 사용 사례를 검토하세요.

자주 묻는 질문

가장 일반적인 프록시 오류는 무엇인가요?

가장 일반적인 프록시 오류는 407 인증 오류, 403 금지 응답, 401 권한 없음 응답, 429 속도 제한, 502 및 504 게이트웨이 오류, TLS 오류, DNS 실패, 연결 타임아웃, CAPTCHA 페이지 및 지리적 불일치입니다.

407 프록시 인증 필요는 무엇을 의미하나요?

인증이 실패하여 프록시가 요청을 거부했음을 의미합니다. 사용자 이름, 비밀번호, 토큰, 포트, 프록시 프로토콜 및 IP 허용 목록 설정을 확인하세요.

429 너무 많은 요청은 무엇을 의미하나요?

대상이 귀하의 트래픽을 속도 제한하고 있음을 의미합니다. 동시성을 줄이고, 지터를 추가하고, 백오프를 사용하며, 즉시 재시도하지 마세요.

HTTP 200을 받지만 유용한 데이터가 없는 이유는 무엇인가요?

이는 종종 소프트 차단, 파서 실패, 동의 페이지, 잘못된 지역 페이지 또는 JavaScript 렌더링 문제입니다. 성공을 계산하기 전에 페이지 구조를 검증하세요.

프록시 타임아웃을 줄이는 방법은 무엇인가요?

더 건강한 경로를 사용하고, 연결 시간 초과를 줄이며, 현실적인 읽기 시간 초과를 설정하고, 백오프를 사용하여 재시도하며, 실패율이 높은 프록시 종료를 격리하십시오.

언제 데이터 센터 프록시 대신 주거용 프록시를 사용해야 하나요?

지리적 정확성, 소비자와 같은 네트워크 아이덴티티 또는 차단 저항이 중요한 경우 주거용 프록시를 사용하십시오. 낮은 마찰과 대량의 공개 페이지에는 데이터 센터 프록시를 사용하십시오.

프록시가 문제인지 어떻게 알 수 있나요?

프록시 유형, 지역 및 일반 브라우저 기준에서 동일한 요청을 비교하십시오. 실패가 하나의 경로 또는 풀을 따르는 경우, 프록시 레이어가 관련되어 있을 가능성이 높습니다.

어떤 지표를 모니터링해야 하나요?

성공률, 차단률, 소프트 차단률, 재시도 깊이, CPSR, p95 대기 시간, 세션 생존, 지리적 정확성, 인증 실패 및 프록시 풀 건강을 추적하십시오.

최종 생각

대부분의 프록시 오류는 실패하는 레이어를 식별하면 수정할 수 있습니다. 인증 오류는 자격 증명 수정을 필요로 합니다. 속도 제한은 페이싱이 필요합니다. 시간 초과는 경로 건강 검사가 필요합니다. TLS 및 DNS 실패는 프로토콜 검증이 필요합니다. 소프트 블록은 콘텐츠 검증이 필요합니다. 지리적 불일치는 더 나은 라우팅 및 로케일 정렬이 필요합니다.

가장 강력한 시스템은 맹목적인 재시도에 의존하지 않습니다. 오류를 분류하고, 목표 수정 사항을 적용하며, 유효한 출력이 개선되는지 측정합니다.

명확한 지표로 시작하고, 작은 파일럿에서 변경 사항을 테스트하며, 성공률, 지리적 정확성, 대기 시간 및 CPSR이 안정적일 때만 확장하십시오.