운영(실 x86 서버) 실측으로 문제 범위가 크게 좁아졌다:
쿠팡 컨테이너에서 **60건 정상**
네이버 매 IP 첫 요청부터 wtm_captcha(43~57KB)
즉 '컨테이너가 문제'가 아니라 **네이버 WTM 만 이 컨테이너를 걸러낸다**. kr_host 도 정상이다
(ensure_ports 에 kr.decodo.com 이 찍혔고, 마커가 해외 IP 하드차단 '비정상적인 접근'(2.6KB)이
아니라 wtm_captcha 다 = 한국 IP 는 제대로 나가고 있다). IP·게이트웨이가 아니라 지문 쪽이 남았다.
서버는 Docker 전용이라 '워커만 호스트 실행' 우회를 쓸 수 없다. 그래서 추측으로 이것저것
고치는 대신, **고치기 전에 무엇이 다른지 눈으로 보는** 도구를 먼저 만든다.
diag_naver.py — 컨테이너 안에서 실물과 동일한 스택(patchright + 실제 Chrome + locale/timezone +
kr 프록시)으로 띄워:
- 네이버 WTM 이 볼 수 있는 값 덤프(UA·languages·webdriver·plugins·screen/avail·devicePixelRatio·
WebGL vendor/renderer·한글 폰트·timeZone …)
- 자동화/가상화로 읽히기 쉬운 항목에 판정과 이유를 붙임
- 실제 msearch 요청 → HTTP·카드 등장 여부·파싱 건수·차단 마커, 실패 시 HTML 저장
--no-cdp 바이트 계측 CDP(Network.enable)를 빼고 A/B — 네이버는 '요청 가로채기 자체가 탐지
신호'라 리소스 차단을 끈 이력이 있는데, 계측용 CDP 는 그대로 붙고 있다
--no-proxy 프록시 없이 시도 — IP 요인과 지문 요인 분리
재빌드 없이 docker cp + docker exec 로 실행한다(사용법은 파일 상단 docstring).
통과 환경 기준값(맥 직결, 참고용):
glRenderer=ANGLE(Apple M3 Pro) · plugins=5 · 한글폰트 6종 · screen 2560x1080/avail 2560x1050
→ HTTP 200 · 파싱 6건 · html 1.26MB
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
