핵심 한 줄: 원격 호스팅 DevTools 프론트엔드(appspot.com)를 로컬 CDP에 붙이되, 중간에 로컬 프록시(9223)를 끼워 Chrome의 cross-origin WebSocket 거부를 우회한다.

프론트엔드 WS를 로컬 프록시(9223)가 종단하고, 파이썬이 Origin 없는 새 WS로 9222에 재접속해 Chrome의 cross-origin 거부를 우회하는 구조

연결 경로:

  • chrome_devtools_remote (unix socket) → adb forward로 localhost:9222에 노출
  • localhost:9222에서 /json으로 탭 목록, /devtools/page/{id}로 페이지별 CDP WS 제공
  • localhost:9223 aiohttp 프록시가 프론트엔드 WS를 받아 9222로 양방향 중계
  • DevTools 프론트엔드는 termux-open-url로 브라우저에서 실행, ?ws=localhost:9223/{id}로 백엔드 지정
adb forward로 소켓을 노출하고 프록시를 띄운 뒤 DevTools 프론트엔드를 실행하기까지의 전체 연결 수명주기

트릭의 본질 — 왜 프록시가 필요한가:

  • 프론트엔드 origin은 https://chrome-devtools-frontend.appspot.com → 9222 직결 시 Chrome CDP가 외부 Origin WS를 거부 (DNS rebinding 방어)
  • 프록시가 프론트엔드 WS를 종단하고 파이썬 프로세스가 새 WS로 9222에 재접속 → 브라우저 Origin이 없으니 통과 (“Origin laundering”). cors_middleware가 허용 헤더를 덧붙인다.

기억해둘 것:

  • ws://localhost이 HTTPS 페이지에서 mixed-content로 안 막히는 이유: localhost는 secure context로 취급 → IP/도메인이었으면 wss 강제로 깨졌을 것.
  • 더 깔끔한 대안: 프록시를 안 쓰고 프론트엔드를 localhost에서 self-host하면 Origin 문제 자체가 사라진다.
  • ?@f84901f7… = DevTools 프론트엔드 빌드 리비전 핀.
#chrome-devtools#cdp#websocket#proxy
#565