VeilSwap
← All posts
프라이버시2026-11-019 min read

스왑 사이트가 실제로 보는 것: 지문·DNS 유출·WebRTC (2026 실측)

스왑 사이트가 채점할 수 있는 세 계층을 모두 측정했습니다. 브라우저 첫 요청은 헤더 14개·636바이트, curl은 80바이트. Chrome 8회 연결이 서로 다른 JA3 8개를 만들었고, 위조 UA는 자기 client hints에 모순됐으며, SOCKS 로컬 해석은 DNS 4패킷을 흘렸고(출구 해석이면 0), STUN URL 하나로 3초 만에 실제 IP가 돌아왔습니다.

스왑 사이트는 당신을 '인식'하는 게 아니라 연결 하나를 채점합니다. 사이트가 내릴 수 있는 판단은 모두 세 계층에서 나옵니다. 네트워크 계층은 IP와 그 ASN, 그 주소의 이력. 전송 계층은 TLS ClientHello — HTML 한 바이트도 도착하기 전에 브라우저가 이미 다 써 놓은 것입니다. 애플리케이션 계층은 요청 헤더, JS가 읽을 수 있는 기기 값, 그리고 시간에 걸친 행동입니다. 오늘 이 세 계층을 자체 리스너와 veilswap.io에 대해 모두 측정했습니다. 사람들이 생각하는 노출량과 실제 관측 가능량의 차이는 크고, 방향도 대부분의 안내문과 반대입니다.

네트워크 계층: 당신의 IP는 이력서를 들고 옵니다. Cloudflare 자체 문서는 bot score가 IP 평판, 요청 특성, TLS 지문에 근거한다고 명시하며, 이 사이트는 Cloudflare 뒤에 있으므로 그 채점은 우리 코드가 돌기 전에 이미 일어납니다. 오늘 측정에 쓴 호스트는 데이터센터 주소 64.118.134.27이었고, /exchange를 세 번, 서로 다른 UA로 요청했습니다 — curl/8.5.0, Windows Chrome 141, HeadlessChrome 151. 세 번 모두 200, 모두 43,014바이트, 챌린지 표식 0. 데이터센터 IP라는 사실 자체는 여기서 거부 사유가 아닙니다. 오리진이 실제로 기록하는 것은 CF-Connecting-IP 헤더이고, 실제로 강제되는 것은 속도입니다: IP당 시간당 6건, 전체 120건, 그리고 IP·코리도·금액·수취 주소를 키로 한 90초 중복 창.

DNS 유출은 지금 가능한 가장 값싼 실수입니다. 06:02 UTC, 로컬 리졸버 캐시를 비우고 Tor의 SOCKS 포트로 평범한 `--socks5`를 써서 veilswap.io를 가져왔습니다. 루프백에서 패킷을 잡아 보니 UDP 53번 패킷 4개가 기록됐습니다. 127.0.0.1에서 로컬 스텁 127.0.0.53으로 나간 질의 2개와 응답 2개. 소요 5.95초. 호스트명을 출구 노드에 넘기는 `--socks5-hostname`으로 바꾸면 DNS 패킷 0개, 소요 2.75초였습니다. 같은 URL, 같은 출구, 같은 도구입니다. 이 누출은 페이지에도 브라우저에도 보이지 않고, 당신의 리졸버를 운영하는 쪽에는 그대로 보입니다 — 가정용 회선이라면 보통 ISP입니다. (Tor 스왑은 안전한가?)

전송 계층: ClientHello가 UA보다 정직합니다. 로컬 TLS 포트에서 원시 ClientHello 바이트를 기록하는 리스너를 띄웠습니다. Chromium 151은 TLS 1.3, 암호 스위트 16개, 확장 17개를 제시했고, 8번의 별도 연결에서 암호 스위트 순서는 바이트 단위로 동일했으며 확장 집합도 정렬하면 같았습니다. 그런데 8번 모두 JA3 해시가 달랐습니다 — Chromium이 확장 순서를 의도적으로 무작위화하기 때문입니다. curl(OpenSSL)은 스위트 31개·확장 11개였고 두 연결이 같은 해시 77f696ec…를 냈습니다. 즉 JA3 비교는 양방향으로 약한 신호입니다: Chrome은 매번 새 클라이언트처럼 보이고, 안정적인 클라이언트는 '의심스러울 만큼 안정적'으로 보입니다.

UA를 위조하면 그림이 나아지는 게 아니라 나빠집니다. 같은 브라우저를 Windows Chrome 141 UA, en-US 로케일, America/New_York 시간대로 다시 띄웠습니다. UA는 바뀌었습니다. 옆의 세 가지는 그대로였습니다: `navigator.userAgentData.brands`는 여전히 "Chromium/151"과 "Not=A?Brand/99", `navigator.platform`은 여전히 "Linux x86_64", 요청 헤더 `sec-ch-ua`는 여전히 151인데 `sec-ch-ua-platform`만 "Windows"로 바뀌어 있었습니다. 진짜 Windows Chrome 141은 일관된 조합을 보냅니다. 위조한 조합이 보내는 것은 실제 브라우저가 만들지 않는 모순입니다. 목표가 '평범해 보이기'라면, UA 스위처는 확실히 당신을 평범하지 않게 만드는 유일한 도구입니다.

라이브러리 없이 페이지가 여전히 읽는 것들. 같은 기기에서 두 번 실행한 결과: platform Linux x86_64, languages en-US와 en, hardwareConcurrency 4, deviceMemory 4, maxTouchPoints 0, vendor Google Inc., 화면 1280×720·24비트·devicePixelRatio 1, 시간대 UTC, WebGL 렌더러 문자열은 ANGLE과 SwiftShader 소프트웨어 장치를 가리켰습니다. 폭 측정으로 폰트 이름 12개를 시험해 6개가 존재했습니다: Arial, Courier New, Times New Roman, DejaVu Sans, Liberation Sans, Noto Color Emoji. 4코어, 보고된 4GB, 720p, 소프트웨어 래스터라이저 — 이것은 노트북이 아니라 클라우드 컨테이너의 형태입니다. 한 항목은 정직하게 실패했습니다: 헤드리스 문맥에서 canvas 해시가 예외를 던져서, 지어낸 값 대신 '얻지 못함'이라고 적습니다.

WebRTC는 JavaScript 한 줄로 실제 주소를 되돌려 놓습니다. STUN 서버를 설정하지 않으면 Chromium 151은 `.local` mDNS 이름으로 난독화된 호스트 후보 하나만 반환했습니다 — 로컬 인터페이스 주소는 가려져 있었습니다. `stun:stun.l.google.com:19302` 한 줄을 더하면 3초 안에 server-reflexive 후보 64.118.134.27이 돌아왔습니다. 이 기기의 실제 공인 주소이며, HTTP 요청 자체는 SOCKS 프록시를 통해 나가고 있었습니다. 사람들이 과소평가하는 지점이 여기입니다: WebRTC는 UDP로 돌고 프록시 설정을 보지 않습니다. 프록시는 HTTP 경로를 가릴 뿐 네트워크 경로를 가리지 않습니다. Tor Browser가 WebRTC를 기본 비활성화한 이유입니다. (Tor 스왑은 안전한가?)

사이트 자체가 실제로 수집하지 않은 것. /exchange 응답은 Set-Cookie 0개, Content-Security-Policy도 없습니다. 대신 strict-origin 리퍼러 정책, nosniff, SAMEORIGIN, 카메라·마이크·위치를 아예 막는 permissions policy를 보냅니다. HTML은 43,014바이트, script 태그 31개, 그중 18개가 Next.js 청크입니다. 그러나 그 마크업 안에 제3자가 둘 있습니다: 프로젝트 yyim3c5trv·ref=bwt의 인라인 Microsoft Clarity 로더, 그리고 spst2.com 서브도메인에서 preload되는 ustat.js. 둘 다 당신의 IP, UA, 클릭 경로를 우리 로그를 거치지 않고 직접 봅니다. Clarity는 세션 리플레이이고 `data-clarity-mask`는 페이지에 정확히 한 번 나옵니다. '로그를 남기지 않는다'와 '이 방문은 기록되지 않았다'는 다른 문장입니다.

상대의 일을 대신 해 주는 여덟 가지 습관. (1) UA만 바꾸기 — 위의 모순을 만듭니다. (2) IP는 바꾸고 시간대와 언어는 그대로 두기. (3) `--socks5-hostname` 대신 `--socks5`를 써서 DNS 유출 — 실측 4패킷 대 0패킷. (4) 프록시 뒤에서 WebRTC를 켜 둔 채 3초 만에 실제 주소 넘겨주기. (5) 일상용 브라우저 프로필로 주문하기 — 확장, 폰트, 리플레이 스크립트까지 전부. (6) Tor로 주문하고 클리어넷으로 결제하기 — 두 경로를 입금 주소 하나에 용접합니다. (7) 수취 주소 하나를 여러 번 재사용하기. 업스트림 입금 주소도 재사용될 때가 있고, 실제로 4회와 7회 쓰인 주소 두 개를 셌습니다. (8) 주문 URL을 북마크하기 — 그것은 참조가 아니라 베어러 능력입니다. (Tor 스왑은 안전한가?)

실제로 견디는 순서, 그리고 이 숫자들의 경계. 독립 브라우저 컨테이너, WebRTC를 기본 차단하고 도메인을 원격 해석하는 Tor Browser, 주문마다 새 수취 주소, 주문 링크는 필요한 몇 분만 보관. 특정 거래소가 이 신호들을 어떻게 채점하는지는 일부러 측정하지 않았습니다. 그것은 비공개 모델이고, 추측을 쓰면 조작이 됩니다. 검증 가능한 것은 좁지만 충분합니다 — DNS 4패킷 대 0, 8회 연결에서 8개의 JA3, 위조 UA가 자기 client hints에 모순되는 것, STUN 서버가 3초에 실제 주소를 돌려주는 것. 작성 시점(2026-11-01 06:05 UTC 무렵) 견적은 100 USDT-TRC20이 0.14544658 XMR(XMR당 약 687.54 USDT), 1,000이 1.633163, 5,000이 8.167982로 둘 다 612 근처, 1 XMR이 599.32 USDT(2개 라우트, 196 bps 우위). 카탈로그는 430개 자산·62개 네트워크, 그중 53개 스테이블코인, 6개 자산은 tag 필요. 환율은 초 단위로 움직이므로 페이지의 실시간 견적이 기준입니다. (Tor 스왑은 안전한가?)

Frequently asked questions

VPN을 쓰면 거래소에서 거부되나요?

VPN이라는 사실 때문에 거부되지는 않습니다. 오늘 데이터센터 IP에서 세 가지 UA로 /exchange를 가져와 세 번 모두 200, 43,014바이트, 챌린지 없음이었습니다. 실제로 막는 것은 보통 사이트 앞단의 Cloudflare 계층이고, 그쪽은 IP 평판을 봅니다. 애플리케이션 계층의 제한은 속도입니다: IP당 시간당 6건, 전체 120건, 90초 중복 창.

Tor만 켜면 방문이 숨겨지나요?

아니요. 오늘 측정에서 Tor가 고친 것은 딱 두 가지입니다: 출구 주소와 로컬 DNS 해석(`--socks5`에서 4패킷 유출, `--socks5-hostname`에서 0). 브라우저 지문, 시간대, WebRTC는 건드리지 않습니다. STUN 서버 하나를 주면 3초 안에 이 기기의 실제 주소 64.118.134.27이 돌아왔습니다. WebRTC를 막고 출구에서 이름을 해석하는 Tor Browser 기본 설정을 쓰세요.

프록시 뒤에서 실제 IP가 보이나요?

일반 HTTP 요청으로는 보이지 않습니다. 거기에는 프록시 주소만 있습니다. WebRTC로는 보입니다: 페이지에 STUN URL 하나를 두면 Chromium이 3초 이내에 이 호스트의 공인 주소와 같은 server-reflexive 후보를 반환했습니다. WebRTC가 UDP를 쓰고 프록시 설정을 무시하기 때문입니다. 로컬 NIC 주소는 이미 mDNS `.local` 난독화로 가려져 있고, 새는 것은 공인 주소입니다.

Ready to swap?

No account · No KYC · No email

Exchange now
스왑 사이트가 실제로 보는 것: 지문·DNS 유출·WebRTC (2026 실측) — VeilSwap