가격 감시 스크립트가 매일 밤 수백 개 상품 페이지를 몇 달간 문제없이 확인했습니다. 빈도를 높이고 두 번째 판매점을 추가하자 로그가 429 응답과 CAPTCHA로 채워졌습니다. 포럼은 회전 프록시를 권합니다. IP가 많으면 차단이 줄어든다는 생각은 절반만 맞습니다.
고정 게이트웨이 뒤의 여러 IP로 요청을 보내 IP별 한도 아래로 트래픽을 분산합니다. 하지만 로그인 도중에도 주소가 바뀌어 인증 세션이 끊길 수 있습니다. 한 문제를 해결하며 다른 문제를 만듭니다.
요약
- 호스트와 포트로 된 단일 게이트웨이가 풀의 출구 IP로 요청을 전달하며 규칙으로 변경 시점을 정합니다.
- 요청마다 바꾸는 방식은 공개 페이지 수집 같은 무상태 작업에 적합합니다. 로그인과 장바구니에는 고정 세션이나 정적 프록시가 좋으며, IP 연속성을 확인하는 사이트에서는 특히 중요합니다.
- 정상 순환해도 다른 고객이 공유 IP 평판을 소모하면 실패합니다. 풀 크기보다 대상에 대한 주소의 신선함과 적은 공유가 성공을 더 잘 설명합니다.
- 계정, 토큰, 쿠키별 한도에는 효과가 없습니다. 소량 작업은 먼저 속도를 낮추고 대기 시간을 알리는
Retry-After를 지키세요.
회전 프록시란?
단일 게이트웨이가 풀에서 고른 IP로 전달합니다. 요청, 시간, 세션별 규칙으로 변경합니다. 호스트와 포트는 일정하고 게이트웨이가 대상이 볼 주소를 정합니다.
요청 하나의 흐름:
- 클라이언트는 항상 같은 게이트웨이 호스트와 포트로 보냅니다.
- 게이트웨이가 규칙을 적용해 출구 IP를 고릅니다.
- 그 IP에서 대상 사이트로 요청이 나갑니다.
- 대상은 출구 IP를 봅니다. 게이트웨이가
X-Forwarded-For같은 헤더로 전달하지 않으면 원래 주소는 보이지 않습니다.
풀, 상태 확인, 장애 전환은 제공업체가 관리하므로 스크립트는 호스트와 포트만 압니다. 이 편리함이 서비스의 이유입니다. 직접 프록시를 운영한다고 무료 순환이 생기지는 않습니다. 보통 하나의 안정적인 출구 IP만 있으며 돈을 내는 부분은 풀 유지입니다.
업체는 게이트웨이와 풀을 백커넥트 프록시라고 부릅니다. MDN 프록시 서버 안내서는 게이트웨이를 포워드 프록시의 다른, 더 쉬운 명칭으로 제시합니다. 주소가 주거용, 데이터센터, 모바일인지와 변경 빈도는 별개입니다.
IP 변경 시점은 무엇이 정하나요?
규칙과 업체에 따라 요청별, 연결별, 고정 시간 또는 명시 명령으로 바뀝니다. 클라이언트나 관리자가 실패하거나 차단된 요청을 재시도하기 전에 바꿀 수도 있습니다. ‘요청별’의 뜻을 확인하세요. 여러 HTTPS 요청이 터널과 IP를 공유할 수 있습니다. 암호화 HTTPS를 중계하는 게이트웨이는 보통 대상 상태 코드를 읽고 스스로 순환을 시작할 수 없습니다.
| 순환 조건 | 대가 |
|---|---|
| 매 요청 | 연속성보다 분산을 우선합니다. 검색과 결과 두 번째 페이지가 서로 다른 IP일 수 있습니다. |
| N개 요청마다 | 요청을 묶지만 5단계 흐름의 3번째와 4번째 사이에서 카운터가 바뀔 수 있습니다. |
| 시간 기준 | 일정 기간 유지한 뒤 바꾸므로 작업 중간에 바뀔 수 있습니다. |
| 실패 시 | 차단이나 429를 새 IP로 재시도합니다. 복원력은 높지만 대상이 전부 거절하면 모르게 주소를 소모합니다. |
표는 배분 결정입니다. 분산은 IP별 임계치 아래를 유지하고 연속성은 같은 방문자로 인식되게 합니다. 요청별 순환은 분산에 전부 투자합니다. 실패 시 방식은 튼튼한 절충처럼 보이지만 비용을 숨깁니다. 로그는 재시도 성공을 보여 주다가 결국 아무것도 통하지 않습니다. 고정 세션은 반대로 일정 기간 한 IP를 유지합니다.
고정 세션, 순환, 정적 프록시의 차이는?
고정 세션은 같은 방문자로 보이도록 풀 IP를 잠시 예약했다가 반환합니다. 정적 프록시는 유지하는 동안 고정 IP를 줍니다. 요청별 순환은 예약하지 않습니다. 요청 사이에 사이트가 사용자를 알아야 하는지로 고릅니다.
| 기능 | 요청별 순환 | 고정 세션 | 정적 프록시 |
|---|---|---|---|
| IP 변경 시점 | 업체에 따라 요청별 또는 연결별 | 기간 만료, 세션 종료, 출구 장애 시 | 할당 중에는 보통 고정 |
| 세션 유지 여부 | IP 연속성 검사 시 실패 가능 | 같은 IP 동안 가능하지만 보장 안 됨 | 가능하지만 다른 세션 검사는 적용됨 |
| 요청 분산 | 풀 전체 | 세션당 IP 하나, 여러 병렬 세션 | 모두 한 IP |
| 적합한 용도 | 공개 페이지 무상태 수집 | 몇 분간 연속성이 필요한 다단계 흐름 | 여러 날 같은 신원이 필요한 계정 작업 |
| 주요 리스크 | 상태 있는 흐름을 방해함 | 기간이 짧으면 작업 중 세션 종료 | 한 IP가 모든 제한과 차단을 받음 |
무상태 수집에는 요청별 순환이 일반적입니다. 로그인에는 IP 유지 방식 둘 중 기간으로 선택합니다. 고정 세션은 빌리고 반환하며 정적 프록시는 할당을 유지합니다. 매일 같은 IP로 로그인하면 재방문자처럼 보입니다. 업체의 기간을 가장 긴 작업과 비교하고 장애도 확인하세요. 조기에 바꾸는 곳도 있고 엄격한 단일 IP 모드는 요청을 실패시킵니다. 긴 기간만으로 연속성이 보장되지는 않습니다.
언제 작업을 중단시키나요?
로그인, 2FA, 장바구니, 결제, 다단계 양식 도중 IP가 바뀌면 실패할 수 있습니다. 쿠키 자체가 자동 무효가 되지는 않습니다. 하지만 IP에 묶인 세션이나 네트워크 변경 사기 탐지는 로그아웃, 재확인, 표시를 유발할 수 있습니다.
프록시를 겨냥했다기보다 사이트가 할 일을 하는 것으로 봅니다. 쿠키는 1분 전과 같은 브라우저라고 주장하고 IP는 확인할 증거입니다. 인증 세션의 네트워크 변경은 훔친 쿠키를 다른 곳에서 재사용하는 모습과 같습니다. 사기 탐지가 찾는 상황이므로 로그아웃과 2FA는 비례하는 대응입니다.
OWASP 세션 관리 지침은 IP와 User-Agent 변화 확인을 설명합니다. 사이트 통제에 따라 예상 밖 변화가 경고나 종료를 일으킬 수 있습니다.
사이트가 요청 사이에 사용자를 기억해야 하나요? 그렇다면 한 IP를 유지하고 아니면 순환하세요. 밤마다 공개 가격을 확인하는 작업은 필요 없지만 대시보드에 로그인해 보고서를 내보내는 작업은 처음부터 끝까지 같은 IP가 필요합니다.
실무 팁: 혼합 작업을 나누세요. 무상태 수집에는 회전 풀, 로그인과 인증 후 작업에는 고정 세션이나 정적 IP를 씁니다. 반대 요구를 같은 규칙으로 처리하지 마세요.
왜 며칠 후 풀이 작동하지 않나요?
정상 순환해도 실패할 수 있습니다. 바뀌는 것은 IP이지 평판이 아닙니다. 공유 주소는 과거 활동을 물려받고 같은 대상에서의 과용이 표시와 성공률 저하를 낳습니다.
풀은 유한한 공유 자원입니다. 고객마다 사이트에서의 평판을 소모합니다. 다른 고객이 같은 IP로 내 대상에 접근하면 CAPTCHA와 차단으로 대가를 치릅니다. 지원 업무에서 평판이 관찰한 활동에 반응하는 사이트와 차단 목록의 생태계처럼 움직이는 것을 봤습니다.
광고하기 쉬운 풀 크기는 생각보다 예측력이 낮습니다. 성공은 다음에 달렸습니다:
- 같은 대상에서 최근 사용한 시점. 다른 고객이 한 시간 전에 쓴 주소는 이미 계산됩니다.
- 공유 고객 수. 작업이 많을수록 빨리 소모됩니다.
- 네트워크 다양성. 몇 범위에 집중된 IP는 함께 차단됩니다.
- 기존 표시 여부. 악용 IP를 남기는 풀은 계속 배포합니다.
많이 재사용한 큰 풀이 대상에 신선한 작은 풀보다 못할 수 있습니다. 대상에서 장기간 성공률을 비교하세요. 첫 성공은 지속 성능의 증거가 아닙니다.
정말 회전 프록시가 필요한가요?
IP 한도 아래 분산할 수 있지만 제한과 재시도 지침 준수를 대신하지 못합니다. MDN 429 문서에 따르면 보통 IP 기준이나 인증이나 쿠키가 있으면 사용자·앱별일 수 있습니다. 계정 한도는 새 IP를 무시합니다. 소량 작업은 먼저 Retry-After를 따르세요.
표준은 429를 정의한 RFC 6585입니다. 대기 시간의 Retry-After를 허용하며 사용자 식별과 계산 방식은 정하지 않습니다. 예로 인증 정보나 상태 있는 쿠키를 듭니다.
잘못된 구매는 세 경우입니다. 계정, API 토큰, 쿠키 한도에서는 모든 IP가 같은 할당량을 소비해 429가 계속됩니다. 작은 작업은 밤에 수백 페이지를 나눠 Retry-After를 기다리고 무료로 지수 백오프로 재시도할 수 있습니다. 안정적 신원이 필요한 로그인 작업에는 고정 IP가 맞습니다.
IP 한도, 물량에 따른 가치, 허용된 범위의 독립 요청일 때 유용합니다. 이용약관은 계속 적용됩니다. 사이트는 연결 수준의 클라이언트 특성과 요청 속도도 판단하므로 순환만으로 접근을 보장하지 못합니다.
구매 전 제한 문서와 응답 헤더를 확인하세요. 비슷한 인증 요청은 429이고 같은 IP의 익명 요청은 성공하면 계정·인증 한도를 시사하지만 증명은 아닙니다. 둘 다 실패하면 IP, 리소스, 서버 전체 한도일 수 있습니다. 엔드포인트와 속도를 비교 가능하게 유지하고 재검사 전 Retry-After를 지키세요.
자주 묻는 질문
VPN과 같은가요?
아닙니다. VPN은 보통 기기 전체 트래픽을 한 서버로 가는 암호화 터널에 보내 연결 중 IP를 유지합니다. 프록시는 앱·요청별 설정 후 규칙으로 바꿔 한 스크립트가 여러 IP를 쓸 수 있습니다.
익명으로 만들어 주나요?
완전히는 아닙니다. 대상에는 IP를 숨겨도 제공업체는 주소와 접속 사이트를 봅니다. 로그인하거나 저장 쿠키를 보내면 대상은 IP와 무관하게 계정이나 쿠키로 알아봅니다.
사이트가 차단할 수 있나요?
네. 프록시로 복제된 사이트에 관한 Hacker News 토론에서 운영자가 봤듯 출발 IP가 바뀌면 개별 차단이 실패할 수 있습니다. 답변은 네트워크와 범위 전체 차단을 제안했습니다. 사이트는 요청 패턴을 평가하는 WAF도 쓸 수 있습니다.
얼마나 자주 바꿔야 하나요?
공통 간격은 없습니다. 대상 IP 한도에 따라 정하세요. 무상태 요청은 필요한 만큼만, 유지해야 할 로그인·결제 세션 중에는 바꾸지 마세요.
토론
댓글
토론에 참여하려면 로그인하세요.