프록시 IP는 언제 로테이션해야 할까? 세션, 비용, 성공률을 위한 의사결정 프레임워크

요청마다 로테이션할지, 스티키 세션을 유지할지, 고정 ISP IP를 유지할지. 요청들이 서로 어떻게 연결되는지에 따라 선택하는 간단한 프레임워크입니다.

“요청마다 로테이션해야 하나요?”는 팀이 레지덴셜 프록시를 사용하기 시작할 때 가장 먼저 묻는 질문 중 하나이며, 정직한 답은 “요청들이 서로 어떤 공통점을 가지고 있는가에 따라 다르다”입니다. 너무 자주 로테이션하면 사이트가 한 방문자에게서 온 것으로 기대하는 흐름이 깨집니다. 너무 적게 로테이션하면 모든 트래픽이 하나의 주소에 몰립니다. 두 경우 모두 차단, 재시도, 대역폭 낭비라는 비용을 초래합니다.

이 가이드는 결정을 내리는 간단한 방법을 제시합니다. 결정의 핵심 질문은 프록시 자체에 관한 것이 아닙니다. 그것은 여러분의 작업에 관한 것입니다. 즉, 어떤 요청들이 함께 묶이는지, 그리고 그것이 얼마나 지속되는지입니다.

세 가지 모드

모드	동작 방식	Shifter에서는
요청마다 로테이션	모든 요청이 서로 다른 레지덴셜 IP에서 발신됨	기본값: 사용자 이름에 세션 플래그 없음
스티키 세션	동일한 세션 ID를 가진 요청들이 세션이 끝날 때까지 하나의 IP를 공유함	사용자 이름에 `sid-<id>`를 추가하고, 선택적으로 `ttl-<seconds>`를 추가; 기본 수명은 120초
고정 IP	선택한 도시와 ISP의 주소 하나를 결제 주기 전체 동안 사용	ISP 프록시

스티키 세션은 그 뒤에 있는 레지덴셜 IP의 연결이 끊어지면 조기에 종료될 수도 있으므로, 세션을 사용하는 코드는 세션 도중 가끔 새로운 IP가 나타날 수 있음을 예상해야 합니다. 스티키 세션은 지역별로 유지되므로, 하나의 세션을 공유하는 도구들은 동일한 지역 진입점을 통해 연결해야 합니다.

결정의 핵심 질문: 무엇이 함께 묶이는가?

스크래퍼가 반복하는 가장 작은 작업 단위를 살펴보고, 그것에 대해 두 가지를 물어보십시오.

1. 하나의 단위가 몇 개의 요청으로 구성되는가? 단독으로 가져오는 상품 페이지는 요청 하나입니다. 검색 후 이어지는 여섯 개의 상세 페이지는 하나의 흐름입니다. 결제 테스트는 상태를 가진 흐름입니다. 장바구니, 세션 쿠키, 때로는 CSRF 토큰이 있습니다.

2. 하나의 단위가 얼마나 걸리는가? 초 단위인가, 분 단위인가, 시간 단위인가?

이 두 가지 답으로부터:

독립적인 단일 요청: 로테이션하십시오. 각 페이지가 독립적으로 존재하므로 IP를 유지해서 얻을 것이 없으며, 요청을 여러 주소에 분산시키면 그중 어느 것도 바쁘게 보이지 않습니다.
30분 이내에 끝나는 흐름: 스티키 세션. 사이트는 첫 번째 요청에서 쿠키를 설정하고 나머지 흐름도 같은 방문자에게서 올 것으로 기대합니다. 검색이나 장바구니 도중 IP를 바꾸면 세션이 탈취된 것처럼 보이며, 이는 갑작스러운 차단과 상태 손실의 흔한 원인입니다.
그보다 길거나, 다시 돌아오는 로그인: 고정 IP. 스티키 세션은 몇 시간이 아니라 몇 분을 위해 만들어졌습니다. 하루 종일 지속되는 세션이나 매일 사용하는 계정이라면 ISP 프록시를 사용하십시오. 저희의 장시간 세션을 위한 ISP 프록시 설정 가이드에서 자세히 다룹니다.

코드로 보면

아래 두 함수는 이 규칙을 코드화하고 그에 맞는 Shifter 사용자 이름을 만듭니다:

def proxy_username(user, country=None, session_id=None, ttl_seconds=None):
    """Build a Shifter residential username: rotate per request, or stick to one IP."""
    parts = [f"customer-{user}"]
    if country:
        parts.append(f"country-{country}")
    if session_id:
        parts.append(f"sid-{session_id}")
        if ttl_seconds:
            parts.append(f"ttl-{ttl_seconds}")
    elif ttl_seconds:
        raise ValueError("ttl only works together with a session id")
    return "-".join(parts)


def choose_rotation(steps, minutes, needs_login=False, same_ip_required=False):
    """Pick a rotation mode for one unit of work.

    steps: requests that belong together (one page = 1, a checkout flow = many)
    minutes: how long that unit of work takes
    """
    if needs_login and minutes > 30:
        return "isp"                      # a login that outlives a sticky session
    if steps == 1 and not same_ip_required:
        return "rotate"                   # independent requests: new IP each time
    if minutes <= 30:
        return "sticky"                   # a short flow: one IP until it ends
    return "isp"

네 가지 전형적인 작업에 적용하면:

from rotation import choose_rotation, proxy_username

jobs = {   # session ids must not contain hyphens: the username uses them as separators
    "products": dict(steps=1, minutes=0.1),
    "search":   dict(steps=6, minutes=2),
    "checkout": dict(steps=15, minutes=8),
    "seller":   dict(steps=400, minutes=240, needs_login=True),
}
for name, job in jobs.items():
    mode = choose_rotation(**job)
    if mode == "rotate":
        user = proxy_username("USERNAME", "us")
    elif mode == "sticky":
        user = proxy_username("USERNAME", "us", session_id=name, ttl_seconds=job["minutes"] * 60 + 120)
    else:
        user = "an ISP proxy username from your plan"
    print(f"{name:<9} {mode:<7} {user}")

products  rotate  customer-USERNAME-country-us
search    sticky  customer-USERNAME-country-us-sid-search-ttl-240
checkout  sticky  customer-USERNAME-country-us-sid-checkout-ttl-600
seller    isp     an ISP proxy username from your plan

TTL은 흐름의 예상 길이에 2분의 여유를 더해 설정되므로, 세션이 작업보다 오래 지속되지만 불필요하게 남아있지는 않습니다. 동시에 실행되는 모든 흐름에는 각각 고유한 세션 ID를 부여하십시오. 두 워커가 하나의 ID를 공유하면 하나의 IP를 공유하게 되어 목적이 무의미해집니다.

이 선택이 비용과 성공률에 미치는 영향

성공률. 가장 흔한 로테이션 실수는 흐름 도중에 로테이션하는 것입니다. 첫 번째 요청이 쿠키를 받고, 두 번째 요청이 그 쿠키를 가진 채 다른 나라의 ISP에서 도착하면, 사이트는 이를 의심스러운 것으로 간주합니다. 흐름에 대한 스티키 세션은 다른 어떤 단일 변경보다 더 많은 실패를 바로잡는 경우가 많습니다. 반대의 실수, 즉 수천 개의 독립적인 요청을 하나의 스티키 IP로 보내는 것은 그 하나의 주소를 봇처럼 보이게 만듭니다. 저희의 스티키 대 로테이팅 레지덴셜 프록시 가이드는 두 실패 모드를 더 깊이 다룹니다.

대역폭. 레지덴셜 트래픽은 기가바이트 단위로 과금되며, 로테이션 자체는 이를 바꾸지 않습니다. 이를 바꾸는 것은 재시도입니다. 실패한 흐름은 모두 다시 다운로드됩니다. 모드를 작업에 맞추면 재시도가 줄어들고, 바로 거기서 절감이 발생합니다. 스티키 세션 내에서는 동일한 연결과 쿠키를 재사용함으로써 동일한 자산을 두 번 다운로드하는 것을 피할 수도 있습니다.

속도. 요청마다 로테이션한다는 것은 모든 요청마다 새로운 경로를 의미합니다. 매번 새로운 연결까지 연다면 설정 시간이 누적됩니다. 연결을 재사용하는 것이 로테이션 모드보다 더 중요합니다. 저희의 스크래퍼가 느린 이유는 대개 프록시 때문이 아니다 테스트에서 그 정도를 측정했습니다.

잘못 선택했다는 신호들

보이는 현상	가능성 있는 원인	변경할 점
첫 번째 단계 이후 흐름이 실패함; 장바구니나 세션이 사라짐	흐름 도중 로테이션	흐름당 스티키 세션
요청이 몰린 직후 하나의 IP가 차단됨	하나의 스티키 세션에 너무 많은 독립 작업이 몰림	독립적인 페이지는 요청마다 로테이션
작업이 끝나기 전에 세션이 끊김	TTL이 너무 짧거나, 흐름이 스티키 세션에 비해 너무 김	TTL을 늘리거나, 몇 시간씩 걸리는 작업은 ISP 프록시로 이전
두 워커가 서로 간섭함	세션 ID 공유	동시 흐름마다 세션 ID 하나씩
로그인이 매일 도전받음	로테이팅 또는 스티키 IP에서의 로그인	계정당 고정 ISP IP

자주 묻는 질문

모든 요청마다 프록시 IP를 로테이션해야 하나요?

관련 없는 상품 페이지를 가져오는 것과 같은 독립적인 요청의 경우라면 그렇습니다. 검색, 장바구니, 로그인처럼 여러 요청에 걸쳐 상태를 공유하는 작업이라면, 스티키 세션으로 흐름 전체 동안 하나의 IP를 유지하십시오.

스티키 세션은 얼마나 오래 지속되어야 하나요?

그 세션이 처리하는 흐름만큼, 거기에 약간의 여유를 더한 만큼입니다. Shifter에서는 기본값이 120초이며 ttl-<seconds>로 설정할 수 있습니다. 약 30분을 넘는 흐름과, 다시 돌아오는 로그인은 ISP 프록시에 속합니다.

IP를 로테이션하면 차단이 줄어드나요?

부하를 분산시켜 어떤 단일 주소도 바쁘게 보이지 않게 하므로, 독립적인 요청에는 도움이 됩니다. 흐름 도중의 로테이션은 그 반대 효과를 냅니다. 하나의 방문자를 여러 명처럼 보이게 만들어, 사이트들이 흔히 차단합니다.

로테이션이 대역폭 비용에 영향을 미치나요?

레지덴셜 트래픽은 용량 단위로 과금되므로 직접적인 영향은 없습니다. 간접적으로는, 잘못된 모드가 실패한 흐름과 재시도를 유발하며, 이것들이 다시 다운로드되어 청구액에 더해집니다.

결론

독립적인 작업에는 요청마다 로테이션하고, 함께 묶이는 각 흐름에는 스티키 세션을 유지하며, 몇 시간씩 지속되거나 다시 돌아오는 로그인이 관련된 작업에는 고정 ISP IP를 사용하십시오. 프록시 설정이 아니라 작업 단위를 보고 결정하고, 동시에 실행되는 모든 흐름에 고유한 세션 ID를 부여하고, 위 표의 신호들을 주의 깊게 살펴보십시오. 저희의 레지덴셜 프록시 로테이션 작동 방식 설명서는 각 모드 뒤에 있는 메커니즘을 다룹니다.