프록시를 사용한 다중 계정 소셜 미디어 관리

소셜 미디어 플랫폼은 마법이 아니라 IP 평판, 행동 클러스터링, 브라우저 지문 충돌을 집계하여 계정을 연결합니다. 두 계정에서 동일한 프록시 IP를 사용하면 직접적인 연결이 됩니다 — Meta 및 TikTok과 같은 플랫폼은 공유 IP 주소를 공동 소유권의 95% 신뢰도 지표로 간주합니다. 계정별 IP 격리 없이 프록시만 사용하면 며칠 내에 탐지가 보장됩니다.

공유 IP 시그니처가 계정 연결을 유발하는 이유

모든 HTTP 요청은 소스 IP를 전달합니다. 플랫폼은 이 IP를 계정 ID, 세션 쿠키, 기기 지문과 함께 기록합니다. 두 번째 계정이 동일한 IP에서 인증되면 플랫폼은 계정 간 IP 조인을 실행합니다. 이는 단순한 문자열 일치가 아닙니다 — 서브넷 클러스터링(IPv4의 경우 /24), ASN 중복, 시간적 근접성을 사용합니다. 두 계정이 24시간 이내에 동일한 203.0.113.0/24에서 나타나면 위험 점수가 급등합니다. 데이터센터 IP는 특히 위험합니다: IP 품질 데이터베이스(예: ipqualityscore.com)의 데이터에 따르면, 데이터센터 범위의 80%가 소셜 미디어 남용 팀에 의해 첫 사용 후 24시간 이내에 플래그 지정됩니다. ISP 풀의 리지덴셜 IP는 더 나은 편이지만, 이들조차 ASN별로 그룹화됩니다 — 같은 도시의 동일한 ISP에서 다른 IP를 사용하는 두 계정은 여전히 BGP 프리픽스를 공유하며, 플랫폼은 이를 약한 연결로 간주합니다.

모바일, 리지덴셜 및 데이터센터 탐지 프로파일

모바일 IP는 캐리어급 NAT(CGNAT) 범위(RFC 6598)에서 비롯됩니다. 단일 모바일 IP는 수천 명의 사용자에게 서비스를 제공할 수 있습니다 — 플랫폼은 이를 알고 모바일 IP 중복을 노이즈로 간주합니다. 하지만 이것이 모바일 프록시를 안전하게 만들지는 않습니다. T-Mobile이나 Vodafone 같은 통신사는 잘 알려진 ASN에서 IP를 할당하며, 플랫폼은 통신사별 평판 테이블을 유지합니다. 모든 계정을 동일한 모바일 통신사를 통해 라우팅하면 여전히 ASN 신호를 공유하게 됩니다. ISP(Comcast, Deutsche Telekom)의 리지덴셜 프록시는 IP당 더 나은 익명성을 제공하지만, IP 풀이 자주 빠르게 재활용됩니다 — 오늘 한 계정에 사용된 프록시 IP가 내일 다른 사용자에게 할당되어 세션 고정성을 깨뜨릴 수 있습니다. 데이터센터 프록시는 최악입니다: 저렴하고 빠르며 즉시 플래그 지정됩니다. 플랫폼은 whois 조회를 실행하고 PTR 레코드를 확인합니다; server.provider.com을 가리키는 역방향 DNS는 즉각적인 적신호입니다. 프로덕션 다중 계정 설정의 경우, 계정 간에 재사용되지 않는 전용 IP를 가진 리지덴셜 또는 모바일 프록시를 사용하십시오.

계정별 고정 세션 — IP 지속성은 필수

각 계정은 전체 수명 주기 동안 단일 프록시 IP에 바인딩되어야 합니다. 세션 고정성은 플랫폼이 IP 변동을 보지 못하게 하며, IP 변동 자체가 의심스러운 신호입니다. 가장 간단한 구현은 계정별 프록시 구성 파일입니다. 아래는 전용 프록시와 무작위 사용자 에이전트로 curl 요청을 실행하는 bash 함수입니다:

function acct_request() {
  local account_id="$1"
  local proxy_ip="$2"
  local proxy_port="$3"
  local ua=$(shuf -n1 /path/to/user_agents.txt)
  curl --proxy "socks5://$proxy_ip:$proxy_port" \
       --proxy-user "user:pass" \
       -H "User-Agent: $ua" \
       --cookie "session_$account_id=..." \
       --cookie-jar "/tmp/cookies_$account_id.txt" \
       "https://platform.com/api/endpoint"
}

이 스크립트는 계정 ID별로 프록시 할당을 일정하게 유지합니다. 브라우저 자동화의 경우, --proxy-server을 통해 페이지별 프록시와 전용 브라우저 컨텍스트를 사용하여 Puppeteer을 사용하십시오. 계정 간에 프록시를 공유하지 마십시오 — 공유 IP에서의 단일 요청도 기록되며, 한 계정이 플래그 지정될 때 소급 연결을 유발할 수 있습니다.

프록시 격리와 함께 브라우저 지문 격리

IP는 하나의 차원일 뿐입니다. 플랫폼은 또한 캔버스 지문, WebGL 렌더러, 설치된 글꼴, 시간대 및 navigator.hardwareConcurrency를 수집합니다. 동일한 브라우저 지문을 공유하지만 IP가 다른 두 계정은 높은 신뢰도로 연결됩니다 — 지문은 종종 IP보다 더 안정적입니다. 계정별로 지문을 격리해야 합니다. 별도의 브라우저 프로필(Chrome --user-data-dir) 또는 puppeteer-extra-plugin-stealth와 같은 지문 무작위화 라이브러리를 사용하는 헤드리스 브라우저를 사용하십시오. 그럼에도 미묘한 누출이 존재합니다: navigator.webdriver 플래그, chrome.runtime 존재, WebRTC 로컬 IP 누출. 브라우저에서 WebRTC를 비활성화하거나 동일한 프록시를 통해 라우팅하십시오. 일반적인 실수는 WebRTC를 활성화한 상태로 리지덴셜 프록시를 사용하는 것입니다 — 브라우저가 STUN 요청을 통해 실제 IP를 누출하여 프록시를 즉시 무력화합니다.

대량 정지의 연쇄 위험

한 계정이 스팸, 정책 위반 또는 자동화된 행동으로 플래그 지정되면, 플랫폼은 그 계정에서 멈추지 않습니다. 역방향 스캔을 실행합니다: 동일한 IP, 동일한 브라우저 지문, 또는 동일한 로그인 패턴(예: 동일한 시간대 활동)을 공유한 모든 계정이 검토 대기열에 들어갑니다. 이것이 대량 정지 연쇄입니다. 단일 손상된 프록시 IP를 재사용했다면 50개의 계정을 무너뜨릴 수 있습니다. 더 나쁜 것은, 플랫폼이 위협 인텔리전스를 공유한다는 점입니다 — Meta의 Facebook ThreatExchange와 Google의 reCAPTCHA Enterprise은 IP 및 지문 해시를 서로 교환합니다. Instagram에서 플래그 지정된 IP는 WhatsApp이나 Facebook에서 정지를 유발할 수 있습니다. 유일한 방어는 엄격한 격리입니다: 하나의 IP, 하나의 지문, 하나의 계정. 공유 인프라는 없습니다. 컨테이너별 프록시 및 지문 구성을 사용하여 별도의 가상 머신 또는 Docker 컨테이너를 사용하십시오. virustotal API 또는 ip-api.com과 같은 도구를 사용하여 매주 프록시 풀에서 IP 블랙리스트를 감사하십시오 — IP가 어떤 남용 데이터베이스에 나타나면 즉시 폐기하고 계정을 새 IP로 마이그레이션하십시오. 단일 정지 연쇄의 비용은 계정당 전용 프록시 리소스를 유지하는 비용보다 몇 자릿수 더 높습니다.