AnyTLS は、TLS の中で動作し、すべての接続の冒頭にパディングを加えるプロキシプロトコルです。これにより、プロキシされた通信に、ふつうは「TLS の中の TLS」を見破る手がかりとなるサイズのパターンが現れなくなります。 パスワードでログインするとサーバがそれを確認し、接続は一見ごく普通の TLS セッションを通って運ばれます。AnyTLS は TLS 接続の再利用も行うため、新しい接続の多くでハンドシェイクを省けます。

この記事では、AnyTLS とは何か、どのように動作するのか、Trojan や VLESS と比べてどんな位置づけなのか、そして anytls:// リンクがどんな形なのかを説明します。

AnyTLS とは？

AnyTLS は比較的新しいプロトコルです。2025 年に、リファレンスのクライアント兼サーバである anytls-go とともに登場しました。プロトコルの仕様も anytls-go で公開されています。その後まもなく、広く使われている 2 つのプロキシエンジン、sing-box と mihomo（現在の Clash 系アプリの多くが採用するエンジン）が対応しました。

AnyTLS の目的は限定的です。Trojan のようなプロトコルはすでに TLS の中に隠れているため、観測者から見えるのは、どこかのサーバへの暗号化されたセッションだけです。しかし、そうしたプロキシ経由で HTTPS サイトを開くと、ブラウザ自身の TLS ハンドシェイクがプロキシの TLS セッションの中を通ります。内側のハンドシェイクの最初のいくつかのメッセージには、典型的なサイズとタイミングがあります。暗号化で隠れるのは内容であって長さではないため、こうしたパターンが外側の暗号化を通して漏れることがあります。これはよく「TLS-in-TLS」問題と呼ばれます。

AnyTLS は、こうしたパターンをぼかそうとします。すべての接続の最初のパケットを、パディングスキームに定められたサイズまでパディングし、典型的な TLS ハンドシェイクと一致しないようにします。

難しくはなるが、不可能にはならない：パディングによって、プロキシ通信の特徴はつかみにくくなります。ただし検出されなくなるわけではなく、新しい接続ごとに数バイトが加わります。

AnyTLS の仕組み

スマートフォンのアプリが AnyTLS サーバ経由で接続を開くと、次のことが起こります。

  1. まず TLS：クライアントは、サーバ名（SNI）と、必要に応じてブラウザに似せたフィンガープリントを使い、サーバへの普通の TLS 接続を開きます。ネットワークからは、ごく普通の HTTPS アクセスに見えます。
  2. パスワードの確認：TLS の中で、クライアントはパスワードのハッシュとパディングのブロックを送ります。パスワードを認識できないサーバは接続を閉じます。
  3. パディング：双方向の最初のパケットを、パディングスキームが定める長さに分割・パディングします。サーバは独自のパディングスキームを送ることができ、クライアントは次の TLS 接続からそれを使います。
  4. 実際の接続：クライアントは、宛先（たとえば example.com:443）への接続を開くようサーバに依頼し、双方向のバイトを中継します。
  5. 再利用：その接続が終わっても、TLS セッションは閉じられません。アイドル状態のセッションとして待機し、次の接続は新しいセッションを開く代わりにそれを使います。1 つのセッションが運ぶ接続は一度に 1 つだけなので、同時に複数の接続があれば複数のセッションが開かれ、それらがあとで再利用されます。

音声通話や QUIC などの UDP は、同じ TLS 接続の中で運ばれます。これを UDP over TCP と呼びます。

パディングスキーム

パディングスキームは、いくつのパケットをパディングし、それぞれをどの長さにするかを定めた短いルールの一覧です。長さはランダムな範囲で指定されることがよくあります。デフォルト値は anytls-go に由来します。サーバの運営者はこれを変更でき、クライアントは新しいスキームを自動で取り込みます。デバイス側で設定することは何もありません。

REALITY

通常の AnyTLS サーバには、そのドメインの TLS 証明書が必要です。sing-box のサーバでは、代わりに REALITY と組み合わせて AnyTLS を動かせます。REALITY は、別の実在するウェブサイトの TLS 証明書を借用する仕組みです。REALITY を使う場合は、サーバの公開鍵とショート ID を設定し、借用元のウェブサイトの名前をサーバ名にして、chrome などのブラウザのフィンガープリントを選びます。REALITY についてよく知らない方は、VLESS Reality とは？をご覧ください。

AnyTLS のメリットと弱点

メリット

  • HTTPS に見える：外側のレイヤーは本物のサーバ名を持つ素の TLS なので、普通のウェブ通信に溶け込みます。
  • TLS-in-TLS のサイズを隠す：パディングは、TLS プロキシを見つけやすくしている特定のパターンを狙ったものです。
  • ハンドシェイクが少ない：アイドル状態のセッションを再利用するため、新しい接続の多くは TLS ハンドシェイクを省けます。遅延の大きい回線で効果があります。
  • 設定がシンプル：クライアントに必要なのは、パスワードと通常の TLS 設定だけです。
  • REALITY と組み合わせられる：sing-box なら、独自の証明書が不要になります。

弱点

  • 新しく、対応がまだ広くない：AnyTLS を提供するサーバパネル、プロバイダ、アプリは、Trojan、Shadowsocks、VLESS より少数です。
  • パディングのぶん帯域を使う：オーバーヘッドは小さいものの、新しいセッションごとに余分なバイトを送ります。
  • UDP は TCP の上を通る：UDP over TCP は動作しますが、パケットが失われると、TLS 接続の中のすべてが待たされます。Hysteria 2 のような QUIC ベースのプロトコルのほうが、パケットロスにうまく対処できます。
  • トランスポートがない：AnyTLS は TLS の上で直接動作します。WebSocket や gRPC を使えないため、WebSocket 上の Trojan や VLESS のように CDN の背後に置くことはできません。

AnyTLS と近いプロトコルの比較

AnyTLS Trojan VLESS + REALITY Hysteria 2
下位の通信 TCP 上の TLS TCP 上の TLS TCP 上の REALITY（TLS） UDP 上の QUIC
ログイン パスワード パスワード ユーザ ID（UUID） パスワード
TLS-in-TLS の隠蔽 パディング なし Vision フローを使用 —
接続の再利用 あり なし なし あり（1 本の QUIC 接続）
証明書 必要（または REALITY） 必要（または REALITY） 不要 必要（自己署名が一般的）
UDP UDP over TCP TLS 経由 同じ接続を経由 QUIC データグラム

Shadowsocks、VMess、SOCKS5 も含めた広い比較は、プロキシ プロトコル比較をご覧ください。いちばん近いプロトコルについては、Trojan プロキシとは？をお読みください。

AnyTLS の共有リンクの見方

プロバイダは通常、AnyTLS サーバを anytls-go の URI 形式の anytls:// リンクで配布します。

anytls://password@host:port/?parameters#name

パスワードはパーセントエンコードされ、# のあとの名前は単なるラベルです。ポートが省略されている場合、クライアントは 443 を使います。パスワード secret の基本的なサーバの例です。

anytls://secret@anytls.example.com:443/?sni=anytls.example.com#Basic

よく使われるパラメータは次のとおりです。

パラメータ 意味
sni TLS のサーバ名。
insecure 1 で証明書の検証をオフにします。
alpn ALPN のリスト。カンマ区切りで、パーセントエンコードします。
fp ブラウザのフィンガープリント。chrome など。
hpkp ピン留めに使う、サーバ証明書の SHA-256。

自己署名証明書を使うサーバを、検証なしのままにせずピン留めする例です。

anytls://secret@anytls.example.com:443/?sni=anytls.example.com&fp=chrome&hpkp=abababababababababababababababababababababababababababababababab#Pinned

Clash や Mihomo のサブスクリプションでは、同じサーバは type: anytls のエントリになり、password、sni のほか、udp: true や client-fingerprint などのオプションを持ちます。Clash のエントリでは、idle-session-check-interval、idle-session-timeout、min-idle-session でセッションの再利用を調整することもできます。

insecure モードは避ける：insecure=1 にすると、あなたとサーバの間にいる誰もが通信を読めるようになります。サーバが自己署名証明書を使う場合は、代わりに hpkp でピン留めしてください。

iPhone で AnyTLS を使う

iPhone・iPad 向けの無料プロキシクライアント Potatso は、パディングスキーム、接続の再利用、UDP over TCP、REALITY、ECH、証明書のピン留め、ブラウザのフィンガープリントを含めて AnyTLS に対応しています。サーバは、anytls:// リンク、Clash や Mihomo のサブスクリプション、Surge の構成から追加するか、手動で入力できます。

iPhone で AnyTLS を使う方法の手順に沿って設定するか、対応しているすべての設定を AnyTLS リファレンスで確認してください。

よくある質問

AnyTLS は何に使うのですか？
AnyTLS は、接続を普通の TLS 接続の中で運び、パディングを加えることで、通信をプロキシだと見分けにくくするプロキシプロトコルです。TLS プロキシを使いつつ「TLS の中の TLS」のサイズのパターンも隠したいときに、Trojan や VLESS の代わりとして使われます。
AnyTLS は Trojan より優れていますか？
どんな場合でも優れているというものではありません。どちらも TLS の中で動作し、パスワードで認証します。AnyTLS はパディングと接続の再利用を加えて、プロキシされた HTTPS の特徴をつかみにくくしています。一方 Trojan は歴史が長くシンプルで、対応するサーバやアプリも多いです。
AnyTLS に対応しているサーバやアプリは？
リファレンスサーバは anytls-go です。sing-box と mihomo も AnyTLS に対応しており、sing-box では REALITY と組み合わせられます。iPhone・iPad では、Potatso が anytls:// リンク、Clash や Mihomo のサブスクリプション、Surge の構成、手動で入力した設定から AnyTLS サーバに接続できます。
AnyTLS は UDP に対応していますか？
対応しています。AnyTLS は UDP を TLS 接続の中で運びます。これを UDP over TCP と呼びます。Potatso では AnyTLS サーバの UDP リレーが初期状態でオフになっているため、サーバが UDP を中継する場合はオンにしてください。

他の言語: English · 简体中文 · 繁體中文 · Русский