あなたはWindowsとChrome用のアンチデテクトブラウザを設定し、クリーンなIPを選び、タイムゾーンと言語を整えましたが、サイトはそれでもキャプチャを要求したり、アカウントを制限したりします。よくある原因はブラウザの下、TCP/IPレベルにあります。サーバーは接続の最初のパケット（SYN）を見ており、そのフィールドからどのオペレーティングシステムがこのパケットを送信したかがわかります。もしそれがLinuxのプロキシサーバーで、User-AgentがWindowsを主張している場合、アンチボットは矛盾を受け取り、ヘッダーでは修正できません。
このテーマはもはやエキゾチックではありません。2026年10月13日、Proxywayによると、英国のプロバイダーBytefulは、データセンターおよびISPプロキシ用のTCP/IPフィンガープリンティングの置換をオープンベータで導入しました：彼らはWindows、macOS、Linux、Android、iOSとして自分自身を偽装することができます。Proxywayの説明は簡単です：アンチボットシステムはますますTCP/IPフィンガープリンティングを注視しています。以下では、このチェックがどのように機能するか、5分でプロキシを確認する方法、そして不一致があった場合の対処法を説明します。
TCP/IPフィンガープリンティングとは何か、そしてなぜプロキシはそれを変更するのか
各OSはSYNパケットを独自の方法で収集します：独自の初期TTL、TCPウィンドウサイズ、ウィンドウスケーリング係数、MSS、そして最も重要なTCPオプションのセットと順序です。パッシブフィンガープリンティング（ここではp0fツールがクラシックで、現代のバリエーションはZardaxtとJA4Tと呼ばれます）は、これらのフィールドを読み取り、クライアントに何も返さずにOSを推測します。
プロキシを介して作業する人々にとっての重要なポイントは、サイトは最後の接続を開くマシンのTCPスタックを見ているということです。通常のプロキシ（HTTP CONNECTまたはSOCKS5）は、あなたの接続を受け入れ、サイトへの新しい接続を自分の名前で開きます。したがって、パケット内のTTLとTCPオプションはプロキシに属し、あなたのコンピュータには属しません。User-Agent、TLSフィンガープリンティング、またはヘッダーを変更することはできますが、SYNはあなたが出ているマシンのカーネルによってすでに収集されています。
OSごとの典型的な値
Scrapflyの分析とpydollのドキュメントからの指標（特定のカーネルバージョンやネットワークによって値は異なる場合があります）：
- Windows 10/11：初期TTL 128、ウィンドウ64240–65535、オプションの順序MSS、NOP、WSCALE、NOP、NOP、SACK（デフォルトでタイムスタンプなし）。
- Linux：TTL 64、ウィンドウ29200（カーネル3.x以上では、一部のカーネル5.x/6.xでは64240）、オプションの順序MSS、SACK、TIMESTAMP、NOP、WSCALE。
- macOSとiOS：TTL 64、ウィンドウ65535、オプションの順序MSS、NOP、WSCALE、NOP、NOP、TIMESTAMP、SACK、EOL。
- Android：TTL 64、オプションの順序はLinuxに近く、論理的にLinuxカーネルを持っています。
ここからの主な罠は、ほとんどのデータセンタープロキシがLinuxで動作していることです。「Windows + Chrome」のプロファイルは、そのようなプロキシの上にLinuxの兆候を持つSYNを持ち、これは最も目立つ矛盾です。
アンチボットは不一致をどれだけ正確に捕まえるか
オープンプロジェクトZardaxtには数字があります：これはp0fとsatori.pyを再構築したもので、特にリレーター、つまりHTTPおよびSOCKSプロキシを探し出します。2026年9月21日のビルドのREADMEによると（約23000セッションから1453のフィンガープリンティングのデータベース）：
- 0.8の閾値を持つモデルは、94.4%のプロキシ経由の接続を捕まえ、0.1%の直接接続を誤ってマークします；
- ブラウザがWindowsを主張する場合、プロキシは96%の確率で捕まえられ、Macの場合は99%です；
- 弱点はAndroidとLinuxです：これらは同じクラスを共有しているため、そのようなリレーターは74%の確率で捕まえられます；
- トンネルVPNモデルはほとんど見えません（6.1%）：トンネルを介してサイトに接続する際、あなたのデバイスのスタックが見えます。
OSはTCPオプションの順序を最も強く示します：プロジェクトの因子分析では、このフィールドがOSを99.1%の確率で推測します。DFフラグはほとんど役に立ちません（0.362）。これは一人の研究者のオープンツールであり、商業的なアンチボットは詳細を公開していませんが、原則は同じです：SYNのOSとUser-AgentのOSを比較します。
プロキシを確認する方法：ステップバイステップ
- プロキシなしで「基準」を取得します。通常のブラウザでbrowserleaks.com/tcpを開きます。TTL、MSS、オプションの順序、p0fの推測、OSに関するZardaxtの評価を記録します。これがあなたの実際のスタックです。
- コンソールからプロキシを確認します。プロキシを介してオープンな分類器にリクエストを実行します：
curl -x http://LOGIN:PASS@HOST:PORT "https://tcpip.incolumitas.com/classify?by_ip=1"
応答にはLinux、Windows、Mac OS、iOSに関するスコアを持つavg_score_os_classフィールドが含まれます。ここでの勝者はプロキシの出口ノードのOSであり、あなたのコンピュータのOSではありません。 - アンチデテクトプロファイルで繰り返します。プロキシを使用してbrowserleaks.com/tcpまたはproxydetect.live/tcpip.htmlを開きます。今、2つのことを比較します：TCP/IPのOSとプロファイルのUser-AgentのOS。
- MSSを確認します。クリーンなEthernetラインはMSS 1460を提供します。1380（WireGuard）、1360（IPsec）または1240のような値は、経路上のトンネルを示します。これ自体はバンではありませんが、モバイルネットワークもしばしば小さなMSSを提供するため、他の兆候と組み合わせると疑わしさが増します。
- ローテーションで5〜10回測定します。レジデンシャルおよびモバイルプロキシでは、各新しいIPが異なるデバイスで異なるOSを持つ可能性があります。一度の測定では何も言えないため、分布を確認してください。
- 表にまとめます：プロキシの種類→TCPによるOS→プロファイルのOS→一致するかどうか。これが、どのプロファイルをどのプロキシで実行するかの答えです。
TTLだけでは証拠としては不十分です：可視値は各ルーターで減少し、サイトは最も近い冪乗に基づいて初期値（64または128）だけを評価します。フィールドの組み合わせ、特にオプションの順序が決定的です。
不一致があった場合の対処法
1. プロキシに合わせてプロファイルを調整し、逆にしない
最も安価な方法は、プロファイルのOSを出口ノードが示すものと一致させることです。プロキシがLinuxを提供する場合、Windowsをサイトに証明するよりもLinuxプロファイルを起動する方が正直です。プロファイルのOSが重要でないタスク（公開ページのパース、価格の監視）では、これが問題を完全に解決します。
2. 必要なOSに合わせてプロキシの種類を選択します
- データセンタープロキシはほぼ常にクラウドASNからのLinuxサーバーを示します。これはLinuxクライアント（Python、Go、サーバー上のcurl）からのスクレイピングには正常ですが、「Windowsユーザー」プロファイルには弱点です。データセンタープロキシは、速度とギガバイトあたりの価格が重要であり、「生きた人間」の伝説ではない場所で取得してください。
- レジデンシャルプロキシは実際の家庭用デバイスやゲートウェイを介して接続されるため、サイトは本物のユーザーノードのスタックを見ます。特定のIPのOSは事前に保証されていませんが、これは生きたデバイスのスタックであり、クラウドサーバーではありません。マルチアカウントや複雑なアンチボットには、レジデンシャルプロキシが最も自然な状況を提供します。
- モバイルプロキシは、AndroidやiOSに似た経路を示します。モバイルプロファイル（ソーシャルネットワーク、アプリ、モバイル版サイト）には、すべての層で理想的な一致です。本物の携帯IPと偽造を区別する方法については、私たちのモバイルプロキシの確認ガイドをお読みください。このようなタスクには、モバイル4G/5Gプロキシが適しています。
3. TCP層とTLS層を混同しない
curl-impersonateやcurl_cffiのようなツールは、TLSハンドシェイクとHTTP/2をChromeの下で偽装しますが、TCPスタックには触れません：SYNは依然として接続元のマシンのカーネルによって収集されます。矛盾したTCPの上に良好なTLSフィンガープリンティングがあっても救われず、両方の層が必要です。TLS部分を整える方法は、curl_cffiを使用したJA4のバイパスに関する記事で説明されています。
4. プロキシ側でのOSの置換とトンネル
プロバイダーは、サーバー上でのTCP/IPフィンガープリンティングの置換を販売し始めています。Bytefulの例のように、これはまだ珍しくベータ版です。逆の方法もあります：トンネルVPNモデルはZardaxtによってほとんどリレーターとして捕まえられません。なぜなら、サイトはあなた自身のスタックを見ているからです。欠点も知られています：減少したMSSはトンネルを示し、VPN自体のIPはホスティングとしてデータベースに記載されることが多いです。
よくある間違い
- IPチェッカーだけを確認する。IPの評判サービスはアドレスとASNを見ており、SYNを見ていません。LinuxスタックのクリーンIPがWindowsプロファイルの下でチェッカーを通過し、アンチボットで失敗します。
- ローテーションでの1回の測定から結論を出す。レジデンシャルプールでは、次のIPが別のOSである可能性があります。
- ヘッダーで修正する。カーネルがSYNを送信した後、どのヘッダーもそれを再記述しません。
- LinuxプロキシでAndroidプロファイルを無視する。オープンモデルでは不確実性の領域（捕獲率74%）ですが、商業的なアンチボットはタイミングやモバイルASNのような他の信号を追加することがあります。モバイルプロファイルはモバイルIPでより自然に見えます。
結論
TCP/IPフィンガープリンティングは、ブラウザから修正できない層です：それはサイトへの接続を開くマシンによって決定されます。確認には5分かかります：プロキシなしとプロキシありでbrowserleaks.com/tcpを確認し、さらにオープンな分類器へのcurlを実行します。次に、単純なルールがあります：プロファイルのOSは出口ノードのOSと一致する必要があります。データセンターはLinuxスクリプトに適しており、レジデンシャルプロキシは「生きた」デスクトッププロファイルに、モバイルはモバイルシナリオに適しています。プロファイルに合ったプロキシの種類を選び、ローテーションで5〜10回測定を行い、アンチボットは最も信頼できる手がかりの1つを失うでしょう。