Tor 미러 감사: .onion 스왑 사이트는 같은 사이트인가
8개 경로를 Tor와 클리어넷에서 두 번씩: API는 바이트까지 같고, HTML은 정확히 150바이트 차이, 보안 헤더 5종이 사라지고 추적 스크립트 둘 중 하나는 여전히 실행됩니다.
측정 가능한 약속. .onion 미러를 운영하는 프라이버시 우선 스왑 사이트는 모두 같은 암묵적 주장을 합니다: 그것은 같은 사이트다. 마케팅 페이지는 감사할 수 없지만 이 주장은 감사할 수 있습니다. 2026-11-07 06:14–06:19 UTC에 8개 경로를 두 번씩 요청했습니다 — 한 번은 Tor SOCKS5 포트로 이름 해석을 프록시에 맡기고(`--socks5-hostname`, .onion 이름이 로컬 리졸버에 닿지 않음), 한 번은 클리어넷 도메인으로 직접 — 상태 코드, 바이트 수, 헤더, 지연을 비교했습니다. (Tor 스왑은 안전한가?)
백엔드는 바이트까지 같습니다. JSON 엔드포인트는 양쪽이 동일했습니다: `/api/currencies`는 각 경로에서 71,655바이트, 1,000 USDT-TRC20 견적은 양쪽 181바이트, 없는 주문 UUID는 같은 21바이트 404, `robots.txt` 525바이트, `sitemap.xml` 448,943바이트. 이 데이터 어디에도 두 번째 배포나 오래된 사본의 흔적은 없습니다. 미러는 같은 Next.js 오리진을 다른 경로로 공개한 것이고 — 그것이 미러의 마땅한 모습이며, 그래서 헤더 차이가 내용 차이보다 훨씬 중요합니다. (XMR→USDT 출구 루트)
150바이트의 정체. .onion으로 받은 HTML은 모두 정확히 150바이트 작았습니다: 홈 72,531 대 72,681, `/exchange` 44,775 대 44,925, 블로그 64,617 대 64,767. 홈의 첫 분기는 49,874바이트 지점이며 연락처 링크입니다. 클리어넷은 `<a href="/cdn-cgi/l/email-protection#0e7d…">`와 `/cdn-cgi/scripts/5c5dd728/cloudflare-static/email-decode.min.js`를 내보내고, .onion은 순수한 `mailto:[email protected]`를 내보냅니다. Cloudflare의 이메일 난독화이며 150바이트 전부가 그것입니다. 즉 미러가 재작성되지 않은 오리진, 두 사본 중 더 정직한 쪽입니다.
보안 헤더 5종이 사라집니다. 클리어넷은 HTTP/2로 `strict-transport-security: max-age=31536000; includeSubDomains; preload`, `x-frame-options: SAMEORIGIN`, `x-content-type-options: nosniff`, `referrer-policy: strict-origin-when-cross-origin`, `permissions-policy: camera=(), microphone=(), geolocation=()`에 `nel`, `report-to`, `cf-ray`까지 보냅니다. .onion은 HTTP/1.1로 `content-type`, `vary`, `date`, `connection`뿐입니다. frame 보호가 없으면 페이지를 iframe에 넣을 수 있고, nosniff가 없으면 타입이 잘못된 응답이 구형 브라우저에서 스크립트로 해석될 수 있습니다. referrer 정책은 브라우저 기본값으로 돌아가 페이지에서 외부로 이동할 때 origin만이 아니라 전체 URL이 전달될 수 있습니다. HSTS는 .onion에서 정말 무의미합니다 — 443 포트가 SOCKS5 연결 자체를 거부해 고정할 TLS가 없습니다 — 하지만 나머지 넷은 아닙니다.
캐시, 프로토콜, 그리고 오리진이 실제로 보내는 것. 클리어넷 HTML은 `cache-control: public, max-age=0, s-maxage=300, stale-while-revalidate=900`; .onion은 캐시 적중 시 같은 줄을, 콜드 요청에는 `private, no-cache, no-store`를 보냈습니다 — CDN이 없는 Next.js 오리진의 본래 동작입니다. `/api/*`의 비대칭은 더 명확합니다: 클리어넷은 `no-store`, .onion은 cache-control을 아예 보내지 않습니다. 클리어넷은 `alt-svc: h3`(HTTP/3)까지 광고하지만 미러는 HTTP/1.1만 말합니다. 어느 것도 스왑을 깨뜨리지 않으며, 두 사본이 서로 다른 계층에서 생성되고 그중 한 계층만 설정되었다는 사실을 보여 줍니다.
추적 스크립트 둘 중 하나는 꺼졌고, 하나는 아직 켜져 있습니다. 페이지 소스의 Clarity 로더에는 명시적 가드가 있어 hostname이 `.onion`으로 끝나면 script 태그를 만들기 전에 return합니다. UStat 태그 — `spst2.com/ustat.js`, `afterInteractive` 로드 — 에는 그 가드가 없고 태그가 .onion HTML에 그대로 나타납니다. 페이지가 내보내는 것만 확인했고 스크립트를 실행하지 않았으므로, 이는 태그에 대한 진술이지 전송 페이로드에 대한 것이 아닙니다. 그래도 비대칭이 결론입니다: 'onion에는 분석이 없다'는 두 스크립트 중 하나에만 참이고, 둘의 차이는 코드 한 줄입니다. (모네로 확인 대기)
Tor의 비용은 초 단위입니다. .onion 홈 5회의 TTFB는 1.81–1.90초(중위 1.86), 클리어넷은 0.053–0.070초. 견적 API 3회는 2.49–6.03초 대 0.21–0.58초. 448KB sitemap은 왕복 4.50초 대 1.34초. 홈은 압축 시 16.6KB, 1.99초에 완료 — 문제는 페이로드가 아니라 회선입니다. 주문에는 무관합니다: 견적 유효기간은 약 120초, 입금 창은 30분이라 3초 로딩이 결과를 바꾸지 않습니다. 15개 페어를 훑어보고 고르는 입장에서는 도구와 잡일의 경계입니다. (Tor 스왑은 안전한가?)
클리어넷 쪽에 빠진 것. Tor Browser는 `Onion-Location` 헤더를 찾으면 원클릭 리다이렉트를 제안합니다. 클리어넷 응답에는 그것이 없어, 이미 Tor를 쓰는 방문자는 주소를 다른 사람에게 들어야 합니다. 미러 자체는 얌전합니다: `<link rel="canonical" href="https://veilswap.io">`를 유지해 중복으로 색인되지 않고, `robots.txt`와 `sitemap.xml`도 클리어넷과 같은 525, 448,943바이트입니다. 검색에는 맞지만, 발견 가능성은 주소가 공개된 위치에 달려 있습니다. (Tor 스왑은 안전한가?)
어떤 미러든 일곱 가지 점검, 그리고 이 사이트의 답. (1) API 본문 하나를 바이트 비교. (2) HTML 한 페이지를 diff하고 모든 차이 바이트를 설명. (3) 헤더를 diff, 특히 nosniff, frame, referrer. (4) 내보내는 HTML에서 분석 호스트를 grep. (5) TLS가 존재하는지 확인. (6) TTFB는 한 번이 아니라 다섯 번. (7) 클리어넷 쪽의 `Onion-Location` 확인. 이 사이트의 결과는: 같은 백엔드, 150바이트 이메일 재작성, 빠진 헤더 5종, 추적 스크립트 둘 중 하나만 중지, HTTP/1.1만, 약 1.8초 추가 지연. 작성 시점(2026-11-07 06:1x UTC) 100 USDT-TRC20은 0.14333064 XMR, 1,000은 1.612097 XMR(2개 경로, 148bps 우위), 역방향 1 XMR은 607.322 USDT. 카탈로그는 438개 자산·65개 네트워크·52개 스테이블코인, 그중 6개는 추가 ID가 필요합니다. 숫자는 움직이며 페이지의 라이브 견적이 기준입니다. (XMR→USDT 출구 루트)