ECHがオンになっているのに、SNIがまだ見える：2026年にどうやって確認するか

```html

ECH — サイト名の暗号化はTLSハンドシェイクで、2026年3月に標準としての地位を獲得しました (RFC 9849, Standards Track)。FirefoxとChromeはデフォルトでこれを有効にしており、Cloudflareはほとんどすべてのクライアントにキーを配布しています。しかし、ほとんどのユーザーにとってECHは静かに機能していません：ブラウザは通常のハンドシェイクに戻り、プロバイダーは依然としてあなたの行き先を確認できます。

以下は、1分で自分の手でSNIが暗号化されているかどうかを確認する方法、なぜそれが最も暗号化されないのか、そしてどのようなシナリオでECHが根本的に無意味であるか（ネタバレ：アンチデテクトやパースにはほぼ常に無意味です）についてです。

ECHが隠すものと隠さないもの

通常のTLS 1.3では、最初のメッセージ—ClientHelloを除いてすべてが暗号化されています。その中には、接続しているドメインを含むSNIフィールドが平文で含まれています。ほとんどのフィルタリングシステムはSNIに依存しています：IPはCDNの背後にある数千のサイトに対して一つですが、ドメインは見えます。

ECHはClientHelloを二つに分割します：

ClientHelloOuter — オープンに送信されますが、偽のラッピングドメインで。Cloudflareではこれがcloudflare-ech.comです。
ClientHelloInner — 本当のドメイン、ALPN、暗号リストがサーバーの公開鍵で暗号化されています。

この暗号化のためのキーは、接続からではなくDNSから取得されます — HTTPSレコード（タイプ65）、パラメータech=です。ここからの重要な結論は、暗号化されたDNSなしではECHは不可能です。DNSリクエストがオープンなUDP/53で行われると、観察者はハンドシェイクの前にドメイン名を確認でき、フィルタリングリゾルバーは応答からech=パラメータを削除することができ、ECHは有効になりません。

ECHが全く隠さないもの：

宛先IPアドレス — 常に見えます;
トラフィックの量とタイミング;
クライアントのTLSフィンガープリント（JA3/JA4） — 暗号と拡張のセットはオープン部分に残ります;
サイトに対するあなた自身 — サーバーは復号化後、以前に見たすべてを確認できます。

最後のポイントは、ECHがアンチボットシステムの回避に関係しない理由です。Cloudflare、DataDome、Akamaiはサーバー側で動作します：SNIが道中で暗号化されていたかどうかは関係ありません。自動化時にばれないことが目的であれば、まったく異なるレイヤーが機能します：TLSフィンガープリント自体の置き換えについては、curl-cffiを使用したJA4フィンガープリントの回避に関する資料で説明しました。

チェック1：今すぐECHが機能しているか（10秒）

ブラウザで開いてください：

https://crypto.cloudflare.com/cdn-cgi/trace

sni=の行を探します。可能性のある二つの選択肢：

sni=encrypted — ECHが機能しており、サイト名が道中で隠されています;
sni=plaintext — ECHが適用されず、ドメインが平文で送信されました。

ターミナルでcurlを使用して同じアドレスを呼び出すと、常にsni=plaintextが返されます — 通常のcurlはECHをサポートしていないため、これは便利な指標です：これが「オフ」の状態です。

チェック2：ドメインにECHキーがあるか（dig、ブラウザなし）

ドメインにech=パラメータを持つHTTPSレコードがDNSに存在する場合にのみECHが有効になります。生のレコードを確認します：

dig +short TYPE65 example.com @1.1.1.1

応答の中でFE0Dバイトを探します — これはECH拡張のコードで、その後にECHConfigが続きます。実際の例：資料作成時点で、crypto.cloudflare.comと私たちのドメインproxycove.comのレコードは133〜136バイトの長さで、FE0Dと偽の名前cloudflare-ech.comが16進数で含まれています。しかし、cloudflare.com自体のレコードは短く、61バイトです：ALPNとIPヒントのみで、ECHは含まれていません。つまり、Cloudflareのインフラ内でもECHはすべてのドメインに配布されるわけではありません — 特定のサイトにECHがない場合は驚かないでください。

もしdigがignoring invalid type HTTPSと警告する場合は、古いバージョンのツールを使用しているため、上記のコマンドのように数値形式TYPE65を使用してください。

なぜECHが機能しないのか：順を追った五つの理由

暗号化されたDNSが無効です。 DoHがないと、ブラウザは信頼できる形式でECHConfigを取得できません。Firefoxでは：設定 → プライバシー → HTTPS経由のDNSを「強化」または「最大保護」モードにします。Chromeでは：設定 → セキュリティ → 安全なDNSを使用する。
ドメインに単にech=を持つHTTPSレコードがありません — 上記のブロックのコマンドで確認します。これはあなたのコントロール外であり、サイト所有者とそのCDNの決定です。
リゾルバーがパラメータを削除します。 企業やプロバイダーのDNSサーバーは、通常ech=なしでHTTPSレコードを返すことができます。パブリックリゾルバー（@1.1.1.1）に直接レコードをリクエストし、システムの応答と比較して確認してください。
ブラウザのフラグがリセットされています。 Firefoxではnetwork.dns.echconfig.enabledとnetwork.dns.http3_echconfig.enabledがabout:configで応答します — 両方ともtrueである必要があります。
中間に監視ゲートウェイがあります。 これについては次のセクションで説明します。

ECHが破られる方法：二つの異なるスキーム

企業ファイアウォール：静かなダウングレード

ネットワーク機器のベンダーはECHに対抗するための既製のレシピを発表しました — トラフィックの可視性を失うことは彼らにとって受け入れられません。例えば、CiscoはアプリケーションデータベースVDB 416（2025年10月）以降、「ECHサーバー」を別のアプリケーションとして特定し、二つのアプローチを提案しています：証明書を再作成して接続を傍受し、ClientHelloからencrypted_client_hello拡張を削除するか、より簡単にDNSレベルで行動することです：ECHドメインのHTTPSレコードをブロックし、DoH/DoT/DoQを削除し、カナリアドメインuse-application-dns.netをブロックし、DNSを企業サーバーのみに許可します。

最初のスキームの狡猾さは、ブロックのように見えないことです。サーバーがECH拡張を見なかった場合、通常通りに応答し、クライアントはECHが「安全にオフになっている」と考え、オープンなSNIで再接続します。サイトは開き、エラーはありません — しかしドメイン名はゲートウェイのログに記録されます。

国家レベル：接続が単に死ぬ

ロシアの例はその正確さで顕著です。2024年11月5日以降、フィルタリングは二つの特徴が同時に一致した場合にのみ作動します：cloudflare-ech.comというSNIとECH拡張の存在。単独ではどちらもブロックを引き起こしません — ECHは他のラッピングドメイン（例えば、テスト用のdefo.ieやtls-ech.dev）を通過します。これは接続をリセットするのではなく、静かにパケットを破棄することによって実現されています：ページはタイムアウトでハングし、切断されます。TCPベースのHTTP/2とQUIC/HTTP-3の両方が影響を受けます。ロスコムナズールはその時、TLS ECHの使用がロシアの法律に違反すると明言し、サイト所有者にCloudflare CDNから離れるよう推奨しました — 一度に数千の完全に合法的なリソースが一般的なラッピングに巻き込まれました。

そのような状況では、Firefoxは約1分後にECHなしで再試行します — つまり最終的にはオープンなSNIを返すことになり、これはセキュリティ上の理由から仕様では推奨されていません。もし「サイトがちょうど1分間読み込まれ、その後開く」という現象を観察しているなら、それはほぼ確実にそれです。

ECHが不十分な場合とその代わりに何を使うか

タスクを正直に分解しましょう。

家庭のインターネットプロバイダーからのプライバシー。 ECH + DoHは良好で無料の改善です。切断されない場所で機能します。
フィルタリングの回避。 ECHはこの目的で設計されておらず、実際にそれが確認されました：フィルターに干渉し始めると、識別されて完全に無効化されるようになりました。それをアクセス手段として頼ることはできません。
パース、マルチアカウント、オートメーション。 ECHは何も提供しません：ターゲットサイトはあなたのIP、JA4、リクエスト履歴を確認できます。重要なのはIPの出所とフィンガープリントの質だけです。

ECHが機能しないすべてのケースでは、より粗いが信頼性の高いレイヤーが機能します：TLSハンドシェイクを観察可能なネットワークの外に持ち出すことです。トラフィックがプロキシを通過する場合、あなたのチャネルの観察者はプロキシノードとの接続のみを確認し、ターゲットサイトのSNIはまったく存在しません、ドメインがECHをサポートしているかどうかに関係なく。日常のアクセスやIPの評判に敏感なサービスとの作業には、レジデンシャルプロキシが適しています；モバイルアプリや接続タイプに特に厳しいプラットフォームには、モバイルプロキシが適しています。

そしてDNSを忘れないでください：ブラウザ内のプロキシは、名前がそれを通じて解決されることを保証しません。DNSリークは、あなたが隠そうとしたものを正確に明らかにします — それを確認する方法については、DNSリークのプロキシ確認に関する別の指示で説明しました。もし問題がチャネル上のトラフィックの深い分析にあるなら、ECHではなく、トランスポート自体を見なければなりません。

短いチェックリスト

crypto.cloudflare.com/cdn-cgi/traceを開いてsni=の行を確認します。
plaintextの場合 — ブラウザでDoHを有効にして再確認します。
効果がなかった場合 — ドメインにキーがあるか確認します：dig +short TYPE65 ドメイン @1.1.1.1、FE0Dを探します。
キーがあるがECHが適用されない場合 — パブリックリゾルバーとシステムリゾルバーの応答を比較します：おそらく、パラメータが道中で削除されています。
接続が1分間ハングし、その後開く — ECHがネットワークレベルで無効化されています；ここではECHは役に立たず、別のトランスポートが必要です。

結論

ECHはTLSのプライバシーにおける最後の穴を慎重に閉じたものであり、アクセス手段や自動化のためのツールではありません。暗号化されたDNSに依存し、画面上にエラーが表示されることなく途中で無効化され、干渉し始めると完全に無効化されます。確認する価値はあります — 上記の二つのコマンドは1分で行えます。しかし、ブロック回避やアンチボットシステムからの保護をECHに基づいて構築するのは無意味です：これらのタスクは、サーバーが他の端で見るIPとTLSフィンガープリントのレベルで解決されます。