동일한 프록시 포트는 Wildberries 파싱 시 50개의 병렬 요청을 무리 없이 처리할 수 있지만, Facebook Ads 관리자에서 동시에 3개의 세션 후에는 "소멸"될 수 있습니다. 문제는 프록시의 품질이 아니라, 서로 다른 유형의 트래픽이 IP에 서로 다른 부하를 생성한다는 것입니다. 이 기사에서는 귀하의 작업에 맞는 실제 스레드 한계를 계산하는 방법을 설명하고, 단순한 수학적 오류로 인해 계정이나 프록시 풀을 차단하지 않도록 하겠습니다.
프록시 포트에서의 "스레드"란 무엇인가
스레드는 특정 시점에 프록시를 통해 이루어지는 하나의 병렬 연결입니다. 만약 당신이 Dolphin Anty의 안티디텍트 브라우저에서 10개의 탭을 열고 모두 동일한 프록시 포트를 통해 Instagram을 동시에 로드한다면, 이는 10개의 스레드입니다. Python에서 Wildberries에 동시에 50개의 요청을 보내는 파서를 가지고 있다면, 이는 50개의 스레드입니다.
중요한 점은 스레드 수는 인터넷 속도와 관련된 것이 아니라, 특정 IP 주소에서 목표 사이트가 한 단위 시간에 보는 "동시 개인"의 수와 관련이 있다는 것입니다. 바로 이 숫자를 Facebook, Instagram, TikTok의 안티프로드 시스템과 마켓플레이스의 보호 시스템이 분석하여 IP를 차단할지 트래픽을 허용할지를 결정합니다.
중재자와 SMM 전문가에게 스레드는 대개 한 순간에 열린 하나의 계정과 같습니다. 마켓플레이스의 판매자에게 스레드는 파서 또는 가격 모니터링 스크립트의 동시에 이루어지는 HTTP 요청입니다. 트래픽의 성격 차이가 한 포트에서 안전하게 유지할 수 있는 스레드 수를 결정합니다.
스레드 한계는 무엇에 따라 달라지는가
"프록시가 N개의 스레드를 유지한다"는 보편적인 숫자는 없습니다 — 이는 차단으로 이어지는 신화입니다. 실제 한계는 여러 요인의 조합에 의해 결정됩니다:
- IP 유형. 레지던트, 모바일 및 데이터 센터 프록시는 안티프로드 시스템에 의해 다르게 인식됩니다. 모바일 IP는 대개 한 명의 실제 사람을 나타내므로, 서로 다른 쿠키를 가진 2-3개의 병렬 세션조차 의심스럽게 보입니다.
- 목표 플랫폼. Facebook과 TikTok은 행동 패턴을 더 엄격하게 분석합니다. Wildberries와 Ozon은 요청 빈도를 우선적으로 살펴보며, "개인"의 수는 중요하지 않습니다.
- 요청 유형. 상품 가격을 얻기 위한 간단한 GET 요청은 가벼운 부하입니다. 인증, 미디어 로딩 및 인터페이스와의 상호작용이 포함된 완전한 세션은 무거운 부하입니다.
- 프록시 제공업체. IP 주소 풀, 회전 속도 및 기술적 용량은 제공업체마다 크게 다릅니다.
- 트래픽의 목적. 멀티 계정 관리는 IP에서 "개인"의 독창성을 요구하고, 파싱은 단순히 신원과 무관한 대역폭을 요구합니다.
이러한 이유로 "프록시의 스레드 한계"가 아니라 "특정 플랫폼에서 특정 작업에 대한 스레드 한계"에 대해 이야기하는 것이 더 정확합니다.
멀티 계정 관리를 위한 계산 (SMM 및 중재)
멀티 계정 관리의 황금 규칙은 간단합니다: 하나의 계정 — 하나의 IP — 하나의 세션. 즉, Facebook Ads, TikTok Ads 또는 Instagram 계정에 대해 프록시 포트에는 정확히 1개의 활성 스레드가 있어야 합니다. 이는 프록시의 기술적 제한 때문이 아니라, 안티프로드 시스템이 IP + 디바이스 지문 + 행동의 조합을 추적하기 때문입니다. 두 개의 계정이 서로 다른 안티디텍트 브라우저 탭에서 동시에 하나의 IP에 "앉아" 있다면, 이는 체인 차단의 위험을 급격히 증가시킵니다 — 즉, 모든 계정이 동시에 차단될 위험이 커집니다.
실제로 SMM 에이전시와 중재 팀에서는 다음과 같은 분배 논리를 사용합니다:
| 작업 | 1 포트당 스레드 수 | 비고 |
|---|---|---|
| Facebook Ads 계정 농사 | 1 | 1개의 안정적인 IP에 대해 엄격히 1개의 계정, 가능하면 고정된 (sticky session) |
| 클라이언트의 Instagram 계정 관리 | 1 | 짧은 병렬 세션조차 이상으로 감지됩니다 |
| 온난화가 포함된 TikTok Ads | 1 | TikTok은 하나의 세션 내에서 IP의 급격한 변경에 특히 민감합니다 |
| 대량 계정 확인 (작업 없음) | 2-3 | 주요 활동에 위험이 없는 가벼운 확인 작업에 허용됩니다 |
이 схем에 있어 IP의 안정성이 중요합니다: 세션 중간에 프록시가 주소를 변경하면 계정과 "개인"의 연결이 끊어지고 장치 변경으로 보입니다. 따라서 멀티 계정 관리에는 일반적으로 레지던트 프록시를 사용하여 하나의 IP를 오랜 시간 동안 고정할 수 있도록 하며 (sticky session 10분에서 몇 시간까지), 특히 민감한 플랫폼의 경우 모바일 프록시를 사용하여 최대한 "인간적인" 트래픽 프로필을 제공합니다.
Dolphin Anty, AdsPower, Multilogin 또는 GoLogin의 안티디텍트 브라우저에서는 설정이 간단합니다: 각 계정의 프로필에 개별 프록시 포트를 지정하고 전체 브라우저에 대한 공용 풀을 사용하지 않습니다. 프로필 설정을 열고 → "프록시" 섹션 → 각 계정에 대한 개별 데이터 (IP, 포트, 로그인, 비밀번호)를 입력하고 → 저장합니다. 이렇게 하면 두 계정이 우연히 동시에 동일한 IP에 있을 수 있는 상황을 물리적으로 배제할 수 있습니다.
마켓플레이스 파싱을 위한 계산
Wildberries, Ozon 또는 Avito의 파싱에서는 논리가 반대입니다. 여기에는 "개인"이라는 개념이 없으며, "한 IP에서 단위 시간 내의 요청 빈도"라는 개념이 있습니다. 마켓플레이스의 보호 시스템은 단순히 병렬 스레드 수가 아니라 요청 속도와 행동 패턴 (동일한 간격, 중단 없음, 동일한 헤더)에 반응합니다.
실제 계산은 다음 공식을 기반으로 합니다:
실제로 대부분의 대형 마켓플레이스의 안전한 범위는 IP당 3-8개의 병렬 스레드이며, 요청 간의 간격은 1-3초입니다. 이 값을 초과하면 403 및 429 응답의 비율이 증가합니다 (캡차, 요청의 일시적 차단).
| 플랫폼 | 1 IP당 권장 스레드 수 | 요청 간 지연 |
|---|---|---|
| Wildberries (상품 카드) | 3-6 | 1-2초 |
| Ozon (가격 모니터링) | 4-8 | 1-2초 |
| Avito (광고 파싱) | 2-4 | 2-4초 |
| Yandex.Market | 3-5 | 1-3초 |
만약 작업이 많은 상품을 빠르게 우회하는 것이라면, 올바른 방법은 하나의 IP를 한계 이상으로 "로드"하는 것이 아니라 IP 주소 풀을 늘리고 부하를 분산하는 것입니다. 1000개의 상품과 IP당 5개의 스레드 한계, 1.5초의 지연이 있을 경우, 하나의 IP는 5분 동안 약 200개의 요청을 처리할 수 있으며, 10개의 IP 풀을 사용할 경우 같은 작업은 약 30초가 소요됩니다. 이러한 작업에 대해 속도/비용 비율이 최적인 것은 데이터 센터 프록시입니다 — 이들은 레지던트 프록시보다 빠르며 인증 없이 공개 페이지를 파싱하는 데 충분합니다.
레지던트 vs 모바일 vs 데이터 센터: 스레드 표
아래는 프록시 유형과 작업 성격에 따라 안전한 병렬 스레드 한계를 빠르게 추정하는 데 도움이 되는 요약 표입니다. 숫자는 대략적인 것이며 특정 플랫폼에 따라 다르지만, 계획을 세우는 데 올바른 규모를 제공합니다.
| 프록시 유형 | 멀티 계정 관리 (스레드/포트) | 파싱 (스레드/포트) | 특징 |
|---|---|---|---|
| 레지던트 프록시 | 1 | 3-5 | 높은 플랫폼 신뢰도, 유연한 회전 |
| 모바일 프록시 | 1 | 2-3 | 최대 "인간성", 그러나 제한된 대역폭 |
| 데이터 센터 프록시 | 소셜 미디어에는 권장되지 않음 | 5-10 | 높은 속도와 낮은 가격, 그러나 소셜 미디어에서 더 쉽게 감지됨 |
주의: 데이터 센터 프록시는 기술적으로 여러 Instagram 계정을 여는 것을 금지하지 않지만, 이러한 IP는 "서버"로서 소셜 미디어의 감지 데이터베이스에 더 자주 기록되어, 하나의 스레드라도 차단 위험이 크게 증가합니다. 소셜 미디어와 광고 플랫폼에서는 스레드 수보다 IP의 유형과 평판이 더 중요합니다.
부하 계산 시 일반적인 실수
실제로 대부분의 차단과 블록은 나쁜 프록시와 관련이 없으며, 잘못된 스레드 분배와 관련이 있습니다. 가장 흔한 실수는 다음과 같습니다:
- 전체 안티디텍트 브라우저에 대한 공용 프록시 풀. 프로필 설정에서 각 계정에 대한 개별 포트가 지정되지 않으면 시스템이 두 프로필을 동일한 IP를 통해 우연히 전달할 수 있습니다.
- 파서의 지연 무시. 요청 간의 간격 없이 스크립트는 자동화로 즉시 감지되는 패턴을 생성합니다, 비록 스레드 수가 형식적으로 하나일지라도.
- 하나의 포트에서 작업 혼합. 계정을 따뜻하게 하는 것과 피드를 파싱하는 데 동일한 프록시를 동시에 사용하는 것은 갑작스러운 차단의 일반적인 원인입니다.
- 활성 세션 중간에 IP 회전. 멀티 계정 관리에서는 sticky 세션이 중요합니다: 계정 작업 중 IP를 변경하는 것은 계정의 타협으로 보입니다.
- 눈대중으로 스레드 계산. 플랫폼의 응답 시간과 실제 한계를 고려하지 않으면 IP를 과부하하거나 프록시 풀을 비효율적으로 사용할 수 있습니다.
체크리스트: 필요한 스레드 수 계산하기
작업을 시작하기 전에 — Facebook Ads 계정 농사나 Wildberries 가격 모니터링이든 — 짧은 체크리스트를 따라가세요:
- 트래픽 유형을 결정하세요: 멀티 계정 관리 (1 계정 = 1 스레드 = 1 IP) 또는 파싱 (1 IP에 여러 요청 허용).
- 플랫폼에 공개 요청 한계 (rate limits) 또는 문서화된 차단 임계값이 있는지 확인하세요.
- 소셜 미디어 및 광고 계정의 경우 레지던트 또는 모바일 IP를 선택하고 1 포트당 1 스레드를 엄격하게 고정하세요.
- 파싱의 경우 "요청 한계 ÷ 응답 시간" 공식을 계산하고 부하의 급증을 위해 20-30%의 여유를 추가하세요.
- 요청 간의 지연을 수동으로 설정하세요, 비록 파싱 도구가 기본적으로 요구하지 않더라도.
- 확대하기 전에 소규모 IP 풀에서 테스트하세요 — 그렇게 하면 특정 플랫폼의 실제 차단 임계값을 확인할 수 있습니다.
- 오류 로그 (403, 429, 캡차)를 유지하세요 — 이러한 코드의 증가가 현재 스레드 한계를 초과했음을 알립니다.
결론
"프록시 포트가 얼마나 많은 스레드를 유지할 수 있는가"에 대한 보편적인 답은 존재하지 않습니다 — 모든 것은 트래픽 유형에 달려 있습니다. Facebook Ads, TikTok Ads 또는 Instagram의 멀티 계정 관리의 경우 규칙은 하나입니다: 1 계정 — 1 IP — 1 스레드이며, 여기서 IP의 평판이 대역폭보다 더 중요합니다. Wildberries, Ozon 또는 Avito의 파싱의 경우, 요청 간의 지연이 올바르게 설정되면 하나의 IP에서 3-8개의 병렬 스레드를 안전하게 유지할 수 있습니다.
만약 귀하의 작업이 체인 차단의 위험 없이 여러 계정을 농사하고 관리하는 것이라면, 고정 세션을 지원하는 레지던트 프록시에 주목하고, 특히 민감한 플랫폼의 경우 모바일 프록시를 고려하세요. 반면에 가격 및 상품 카드의 빠르고 대량 파싱이 목표라면, 여러 데이터 센터 프록시 풀에 대한 부하를 계산하고 요청을 고르게 분산하여 하나의 주소에서 안전한 스레드 한계를 초과하지 않도록 하는 것이 더 합리적입니다.