VeilSwap
← All posts
プライバシー2026-11-019 min read

スワップサイトに実際に見えるもの:指紋・DNS リーク・WebRTC(2026年実測)

スワップサイトが採点できる 3 層を実測しました。ブラウザの初回リクエストは 14 ヘッダ・636 バイト、curl は 80 バイト。Chrome の 8 接続は 8 つの異なる JA3 を生み、偽装 UA は自身の client hints に矛盾させられ、SOCKS のローカル解決は DNS を 4 パケット漏らし(出口解決なら 0)、STUN URL 1 つで 3 秒後に実 IP が返りました。

スワップサイトはあなたを「認識」しているのではなく、1 回の接続を採点しています。 下せる判断はすべて 3 層から来ます。ネットワーク層は IP、その ASN、そのアドレスの履歴。トランスポート層は TLS ClientHello——HTML が 1 バイトも届く前にブラウザが書き終えているものです。アプリケーション層はリクエストヘッダ、JavaScript から読める端末の値、そして時間軸の行動。本日この 3 層をすべて、自前のリスナーと veilswap.io に対して実測しました。人が思っている露出量と、実際に観測できる量の差は大きく、しかも多くの解説が言う方向とは逆です。

ネットワーク層:あなたの IP は履歴書を持って届きます。 Cloudflare のドキュメントは、bot score が IP レピュテーション・リクエスト特性・TLS フィンガープリントに基づくと明記しており、当サイトは Cloudflare の背後にあるため、この採点はこちらのコードが動く前に起きています。今朝の実測元はデータセンターのアドレス 64.118.134.27 で、/exchange に 3 回、UA を変えてアクセスしました——curl/8.5.0、Windows の Chrome 141、HeadlessChrome 151。3 回とも 200、3 回とも 43,014 バイト、チャレンジの痕跡はゼロ。データセンター IP であること自体は、ここでは拒否条件ではありません。オリジンが実際に記録するのは CF-Connecting-IP ヘッダで、実際に効いているのはレートです:IP あたり 1 時間 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 拡張で、2 回の接続が同じハッシュ 77f696ec… でした。つまり JA3 の照合はどちら向きにも弱い信号です:Chrome は毎回新しいクライアントに見え、安定したクライアントは「不自然に安定」に見えます。

UA を偽装すると、絵は良くなるどころか悪くなります。 同じブラウザを Windows Chrome 141 の UA、en-US ロケール、America/New_York タイムゾーンで起動し直しました。UA は変わりました。隣の 3 つは変わりません:`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 スイッチャーは確実に「普通でなく見せる」唯一の道具です。

ライブラリなしでページがまだ読めるもの。 同じ機械で 2 回実行した結果: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 コア・申告 4 GB・720p・ソフトウェアラスタライザは、ノート PC ではなくクラウドコンテナの形です。1 つは正直に失敗しました:ヘッドレス文脈で canvas ハッシュが例外を投げたので、捏造した値ではなく「取得できず」と書きます。

WebRTC は JavaScript 1 行で本当のアドレスに変えます。 STUN サーバを設定しない場合、Chromium 151 は `.local` の mDNS 名で難読化されたホスト候補を 1 つ返すだけでした——ローカルインターフェースのアドレスは隠れています。`stun:stun.l.google.com:19302` を 1 つ足すと、3 秒以内に server-reflexive 候補 64.118.134.27 が返りました。これはこの機械の実際のグローバルアドレスで、HTTP リクエスト自体は SOCKS プロキシを通っていました。ここが過小評価される仕組みです:WebRTC は UDP 上で動き、プロキシ設定を見ません。プロキシが隠すのは HTTP の経路であって、ネットワークの経路ではありません。Tor Browser が WebRTC を既定で無効にしているのはこのためです。 (Torでのスワップは安全?)

サイト側が実際に集めていないもの。 /exchange の応答は Set-Cookie ゼロ、Content-Security-Policy もなし。一方で strict-origin の referrer ポリシー、nosniff、SAMEORIGIN、カメラ・マイク・位置情報を明示的に禁止する permissions policy は送っています。HTML は 43,014 バイト、script タグ 31 個、うち 18 個が Next.js のチャンク。ただしそのマークアップには第三者が 2 つ座っています:プロジェクト yyim3c5trv・ref=bwt のインライン Microsoft Clarity ローダと、spst2.com サブドメインから preload される ustat.js。どちらもあなたの IP、UA、クリック経路を、当方のログを経由せず直接見ます。Clarity はセッションリプレイで、`data-clarity-mask` はページ内に 1 回だけ出現します。「ログを残さない」と「この訪問は記録されていない」は別の文です。

相手の代わりに仕事をしてしまう 8 つの習慣。(1)UA だけ変える——上の矛盾を作る。(2)IP は変えてタイムゾーンと言語を変えない。(3)`--socks5-hostname` ではなく `--socks5` を使い DNS を漏らす——実測 4 パケット対 0。(4)プロキシの背後で WebRTC を有効にしたまま、3 秒で実アドレスを渡す。(5)日常のブラウザプロファイルで注文する——拡張、フォント、リプレイスクリプトごと。(6)Tor で注文しクリアネットで支払う——2 つの経路を 1 つの入金アドレスに溶接する。(7)1 つの受取アドレスを何度も使う。上流の入金アドレスも再利用されることがあり、実際に 4 回と 7 回使われた 2 件を数えました。(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(1 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 から 3 つの UA で /exchange を取得し、3 回とも 200・43,014 バイト・チャレンジなしでした。実際に遮るのは通常サイト前面の Cloudflare 層で、こちらは IP レピュテーションを見ます。アプリケーション層で存在する制限はレートです:IP あたり 1 時間 6 注文、全体 120、90 秒の重複窓。

Tor だけで訪問を隠せますか?

いいえ。本日の実測で Tor が直したのは 2 点だけ:出口アドレスとローカル DNS 解決(`--socks5` で 4 パケット漏れ、`--socks5-hostname` で 0)。ブラウザフィンガープリント、タイムゾーン、WebRTC には触れません。STUN サーバを 1 つ与えると 3 秒以内にこの機械の実アドレス 64.118.134.27 が返りました。WebRTC を止め出口で名前解決する Tor Browser の既定設定を使ってください。

プロキシの背後で本当の IP は見えますか?

通常の HTTP リクエストからは見えません(そこにはプロキシのアドレスしかありません)。WebRTC 経由なら見えます:ページに STUN URL を 1 つ置くと、Chromium は 3 秒未満でこのホストのグローバルアドレスに等しい server-reflexive 候補を返しました。WebRTC は UDP を使いプロキシ設定を無視するためです。ローカル NIC のアドレスは mDNS の `.local` 難読化で既に隠れており、漏れるのはグローバル側です。

Ready to swap?

No account · No KYC · No email

Exchange now
スワップサイトに実際に見えるもの:指紋・DNS リーク・WebRTC(2026年実測) — VeilSwap