당신은 Windows와 Chrome에 맞게 안티탐지 브라우저를 설정하고, 깨끗한 IP를 선택하고, 타임존과 언어를 조정했지만, 사이트가 여전히 CAPTCHA를 요구하거나 계정을 차단합니다. 자주 발생하는 원인은 브라우저 아래, TCP/IP 수준에 있습니다. 서버는 첫 번째 연결 패킷(SYN)을 보고, 그 필드에서 어떤 운영 체제가 이 패킷을 보냈는지 알 수 있습니다. 만약 이것이 Linux 프록시 서버이고, User-Agent가 Windows라고 주장하면, 안티봇은 헤더로는 수정할 수 없는 모순을 겪게 됩니다.
이 주제는 더 이상 이국적인 것이 아닙니다. 2026년 10월 13일, Proxyway에 따르면, 영국의 제공업체 Byteful은 데이터 센터 및 ISP 프록시를 위한 TCP/IP 지문 변경 기능을 공개 베타로 포함시켰습니다: 이들은 Windows, macOS, Linux, Android 및 iOS로 자신을 가장할 수 있습니다. Proxyway의 설명은 간단합니다: 안티봇 시스템은 점점 더 TCP/IP 지문을 주목하고 있습니다. 아래에서는 이 검사가 어떻게 이루어지는지, 자신의 프록시를 5분 안에 어떻게 확인하는지, 불일치 시 무엇을 해야 하는지 알아보겠습니다.
TCP/IP 지문이란 무엇이며 프록시는 왜 이를 변경하는가
각 운영 체제는 SYN 패킷을 저마다 다르게 수집합니다: 고유한 초기 TTL, TCP 윈도우 크기, 윈도우 스케일링 계수, MSS, 그리고 가장 중요한 TCP 옵션의 집합과 순서입니다. 수동 지문 인식(여기서의 고전적인 도구는 p0f이며, 현대적인 버전은 Zardaxt와 JA4T라고 불립니다)은 이러한 필드를 읽고 운영 체제를 추측하며, 클라이언트에게 아무것도 응답하지 않습니다.
프록시를 통해 작업하는 사람들에게 중요한 점: 사이트는 마지막으로 연결을 여는 기계의 TCP 스택을 봅니다. 일반 프록시(HTTP CONNECT 또는 SOCKS5)는 당신의 연결을 수락하고 사이트에 대해 새로운 연결을 자신의 이름으로 엽니다. 따라서 패킷의 TTL과 TCP 옵션은 프록시의 것이지 당신의 컴퓨터의 것이 아닙니다. User-Agent, TLS 지문 또는 헤더를 변경할 수 있지만, SYN은 이미 당신이 나가는 기계의 커널에 의해 수집되었습니다.
운영 체제별 전형적인 값
Scrapfly의 분석와 pydoll 문서에서의 기준(특정 커널 버전과 네트워크에 따라 값이 다를 수 있습니다):
- Windows 10/11: 초기 TTL 128, 윈도우 64240–65535, MSS, NOP, WSCALE, NOP, NOP, SACK 순서(기본적으로 타임스탬프 없음).
- Linux: TTL 64, 3.x+ 커널에서는 29200, 일부 5.x/6.x 커널에서는 64240, MSS, SACK, TIMESTAMP, NOP, WSCALE 순서.
- macOS 및 iOS: TTL 64, 윈도우 65535, MSS, NOP, WSCALE, NOP, NOP, TIMESTAMP, SACK, EOL 순서.
- Android: TTL 64, 옵션 순서는 Linux와 유사하며, 이는 논리적입니다. 왜냐하면 Android는 Linux 커널을 사용하기 때문입니다.
여기서 주요 함정은 거의 모든 데이터 센터 프록시가 Linux에서 작동한다는 것입니다. "Windows + Chrome" 프로필은 이러한 프록시 위에서 SYN에 Linux의 흔적을 남기며, 이 모순은 가장 눈에 띄게 드러납니다.
안티봇이 불일치를 얼마나 정확하게 감지하는가
열린 프로젝트 Zardaxt에서 수치가 있습니다: 이는 p0f와 satori.py를 재작성한 것으로, HTTP 및 SOCKS 프록시를 찾습니다. 2026년 9월 21일의 빌드 README에 따르면(1,453개의 지문에서 약 23,000개의 세션):
- 0.8의 임계값을 가진 모델은 94.4%의 프록시 연결을 감지하고, 0.1%의 직접 연결만 잘못 표시합니다;
- 브라우저가 Windows라고 주장할 경우, 프록시는 96%의 경우에 감지되며, Mac일 경우 99%입니다;
- 약점은 Android와 Linux입니다: 이들은 하나의 클래스를 공유하므로 이러한 리피터는 74%의 경우에 감지됩니다;
- 터널 VPN 모델은 거의 감지되지 않습니다(6.1%): 사이트와의 터널을 통해 당신의 장치 스택이 보입니다.
운영 체제는 TCP 옵션의 순서를 가장 강하게 나타냅니다: 프로젝트의 인자 분석에서 이 필드는 99.1%의 경우에 운영 체제를 추측합니다. DF 플래그는 거의 쓸모가 없습니다(0.362). 이는 한 연구자의 공개 도구이며, 상업적 안티봇은 세부 사항을 공개하지 않지만 원리는 동일합니다: SYN의 운영 체제를 User-Agent의 운영 체제와 비교합니다.
자신의 프록시를 확인하는 방법: 단계별
- 프록시 없이 "기준"을 찍으세요. 일반 브라우저에서 browserleaks.com/tcp를 엽니다. TTL, MSS, 옵션 순서, p0f의 추측 및 운영 체제에 대한 Zardaxt의 평가를 기록합니다. 이것이 당신의 실제 스택입니다.
- 콘솔에서 프록시를 확인하세요. 프록시를 통해 열린 분류기로 요청을 실행합니다:
curl -x http://LOGIN:PASS@HOST:PORT "https://tcpip.incolumitas.com/classify?by_ip=1"
응답에는 Linux, Windows, Mac OS 및 iOS에 대한 점수가 포함된avg_score_os_class필드가 있습니다. 여기서 승자는 프록시의 출구 노드 운영 체제입니다, 당신의 컴퓨터가 아닙니다. - 안티탐지 프로필에서 반복하세요. 이제 프록시가 있는 프로필에서 browserleaks.com/tcp 또는 proxydetect.live/tcpip.html를 엽니다. 이제 두 가지를 비교하세요: TCP/IP의 운영 체제와 프로필의 User-Agent의 운영 체제.
- MSS를 확인하세요. 깨끗한 이더넷 라인은 MSS 1460을 제공합니다. 1380(WireGuard), 1360(IPsec) 또는 1240과 같은 값은 경로에 터널이 있음을 나타냅니다. 이것만으로는 차단되지 않지만, 모바일 네트워크도 종종 더 작은 MSS를 제공하므로 다른 신호와 결합하면 의심을 더할 수 있습니다.
- 회전에서 5–10번 측정하세요. 주거용 및 모바일 프록시에서 각 새로운 IP는 다른 운영 체제를 가진 다른 장치일 수 있습니다. 하나의 측정은 아무것도 말하지 않으므로 분포를 확인하세요.
- 표로 정리하세요: 프록시 유형 → TCP에 따른 운영 체제 → 프로필의 운영 체제 → 일치 여부. 이것이 어떤 프록시에서 어떤 프로필을 실행해야 하는지에 대한 답입니다.
하나의 TTL만으로는 증거가 되지 않습니다: 가시적인 값은 각 라우터에서 감소하며, 사이트는 가장 가까운 제곱에 따라 초기 값(64 또는 128)만 평가합니다. 필드의 조합이 결정적이며, 우선 옵션의 순서입니다.
불일치 시 해야 할 일
1. 프록시에 맞게 프로필을 조정하세요, 그 반대가 아닙니다
가장 저렴한 방법: 프로필의 운영 체제를 출구 노드가 보여주는 것과 일치하도록 선택하세요. 프록시가 Linux를 제공하는 경우, Windows라고 주장하기보다는 Linux 프로필을 실행하는 것이 더 정직합니다. 프로필의 운영 체제가 중요하지 않은 작업(공개 페이지 파싱, 가격 모니터링)에서는 이 방법이 문제를 완전히 해결합니다.
2. 필요한 운영 체제에 맞는 프록시 유형을 선택하세요
- 데이터 센터 프록시는 거의 항상 클라우드 ASN의 Linux 서버를 보여줍니다. 이는 Linux 클라이언트(Python, Go, curl 서버)에서 스크래핑하는 데 정상입니다: 스택과 스크립트의 User-Agent가 일치합니다. "Windows 사용자" 프로필에는 약점입니다. 데이터 센터 프록시는 속도와 기가바이트당 가격이 중요한 곳에서 선택하세요, "실제 사람"의 전설이 아니라.
- 주거용 프록시는 실제 가정용 장치와 게이트웨이를 통해 나가므로, 사이트는 실제 사용자 노드의 스택을 봅니다. 특정 IP에서 운영 체제가 보장되지는 않지만, 이는 실제 장치의 스택이지 클라우드 서버의 것이 아닙니다. 멀티 계정 및 복잡한 안티봇을 위해 주거용 프록시는 회전에서 운영 체제 분포를 확인하면 가장 자연스러운 그림을 제공합니다.
- 모바일 프록시는 Android 또는 iOS와 유사한 경로를 보여줍니다. 모바일 프로필(소셜 미디어, 애플리케이션, 웹사이트의 모바일 버전)에 대해 모든 계층에서 완벽하게 일치합니다. 진짜 모바일 IP와 가짜를 구별하는 방법에 대한 자세한 내용은 모바일 프록시 검증 가이드를 참조하세요. 이러한 작업에는 모바일 4G/5G 프록시가 적합합니다.
3. TCP 계층과 TLS 계층을 혼동하지 마세요
curl-impersonate 또는 curl_cffi와 같은 도구는 TLS 핸드셰이크와 HTTP/2를 Chrome에 맞게 위장하지만, TCP 스택은 건드리지 않습니다: SYN은 여전히 연결이 이루어지는 기계의 커널에 의해 수집됩니다. 좋은 TLS 지문이 모순된 TCP 위에 있더라도 구제되지 않으며, 두 계층이 모두 필요합니다. TLS 부분을 조정하는 방법은 curl_cffi를 통한 JA4 우회에 대한 기사에서 설명되어 있습니다.
4. 프록시 측에서 운영 체제를 변경하고 터널링
제공업체들은 이제 자신의 서버에서 TCP/IP 지문 변경 기능을 판매하기 시작하고 있으며, 위의 Byteful이 그 예입니다. 그러나 이는 아직 드물고 베타입니다. 반대 경로도 있습니다: 터널 VPN 모델은 Zardaxt가 리피터로 거의 감지하지 못합니다, 왜냐하면 사이트는 당신의 스택을 보기 때문입니다. 단점도 알려져 있습니다: 감소된 MSS는 터널을 나타내며, VPN의 IP는 종종 호스팅으로 분류됩니다.
자주 하는 실수
- IP 체크만 확인하기. IP 평판 서비스는 주소와 ASN을 보고 SYN을 보지 않습니다. Linux 스택을 가진 깨끗한 IP가 Windows 프로필 아래에서 체크를 통과하고 안티봇에서 실패합니다.
- 회전에서 하나의 측정으로 결론 내리기. 주거용 풀에서 다음 IP는 다른 운영 체제가 될 수 있습니다.
- 헤더로 수정하기. 커널이 SYN을 보낸 후에는 어떤 헤더도 이를 수정하지 않습니다.
- Linux 프록시에서 Android 프로필을 무시하기. 공개 모델의 경우 이는 불확실한 영역입니다(74% 포착률), 그러나 상업적 안티봇은 타이밍 및 모바일 ASN과 같은 다른 신호를 추가할 수 있습니다. 모바일 프로필은 모바일 IP에서 더 자연스럽게 보입니다.
결론
TCP/IP 지문은 브라우저에서 수정할 수 없는 계층입니다: 이는 사이트에 연결을 여는 기계에 의해 결정됩니다. 검사는 5분이 소요됩니다: 프록시 없이 browserleaks.com/tcp와 프록시와 함께, 그리고 열린 분류기로 curl을 사용합니다. 이후 간단한 규칙: 프로필의 운영 체제는 출구 노드의 운영 체제와 일치해야 합니다. 데이터 센터는 Linux 스크립트에 적합하고, 주거용 프록시는 "실제" 데스크탑 프로필에 적합하며, 모바일은 모바일 시나리오에 적합합니다. 자신의 프로필에 맞는 프록시 유형을 선택하고, 회전에서 5–10번 측정하여 안티봇이 가장 신뢰할 수 있는 단서를 잃게 하세요.