Clash プロトコルとカーネル技術リファレンス プロキシプロトコル選定ガイド

これら6種類のプロトコルは、6つの並列な選択肢ではなく、同じ問題に対して段階ごとに与えられた異なる答えです。目的は共通しています。ローカルの通信を暗号化してリモートのサーバーへ送り、サーバー側からリクエストを出すことです。違いは実装の道筋にあります。伝送層に TCP と UDP のどちらを選ぶか、認証をハンドシェイクの前と後のどちらに置くか、接続がステートフルかステートレスか。この3つの軸が、プロトコルの性能特性、互換範囲、適した導入環境を決めます。

第1の軸：伝送層

Shadowsocks、Vmess、Trojan、VLESS はいずれも TCP 優先のグループです。QUIC が成熟するまで、TCP はほぼすべてのネットワーク環境で使える伝送層でした。代償は、ハンドシェイクに往復が必要なことと、パケットロスからの復旧をカーネルが担うことです。Hysteria2 と TUIC は UDP 上の QUIC を選び、暗号化・輻輳制御・多重化をすべてユーザー空間の実装に載せています。利点はハンドシェイクが速く、パケットロスからの復旧が柔軟なこと、代償は CPU 使用率が高くなることです。

伝送層の選択は、必要なポートを直接決めます。TCP 系プロトコルは TCP ポートを1つ開けるだけで済み、サーバーのファイアウォール、クラウド事業者のセキュリティグループ、コンテナのポートマッピングの3か所を揃えれば完了です。QUIC 系プロトコルは UDP ポートを開ける必要があり、しかも一部のクラウド事業者のセキュリティグループはデフォルトで UDP を許可していません。設定時にこの手順を飛ばしやすく、「クライアントが接続できず、サーバー側のログにも何も出ない」という症状になります。

第2の軸：認証と特徴

Shadowsocks にはハンドシェイクのネゴシエーションがありません。クライアントとサーバーが鍵を共有し、一致すればすぐにデータ送信を始めます。プロトコル層で身元を宣言することはありません。Vmess は UUID による身元を導入し、認証をプロトコルの一部にしました。サーバーは UUID ごとにユーザーを区別し、通信量を集計し、個別に速度制限できます。Trojan と VLESS は別の道を選びました。通信を標準の TLS に載せ、認証情報を TLS の内側に隠します。サーバーは証明書と SNI のレベルでは、ごく普通の HTTPS サイトと区別がつきません。

認証方式が複雑になるほどハンドシェイクのコストは増えますが、得られる管理性も変わります。共有パスワードは最も簡単ですが、パスワードを変えるたびに全員へ通知が必要です。UUID はユーザー単位の管理に向きますが、設定項目が増えます。TLS に載せる方式は管理性が最も高い一方、証明書とドメインが必須です。選定時は「サーバーを誰が運用するか」も一緒に考えるほうが、プロトコルの性能だけを比べるより意味があります。

第3の軸：状態とオーバーヘッド

ステートフルなプロトコルはセッションテーブルを維持する必要があり、ステートレスなプロトコルはリクエストごとに独立して処理します。VLESS はステートレス設計の代表で、サーバーは接続ごとにセッションを保持する必要がなく、再起動や移行のコストが低くなります。Vmess は初期に時刻ウィンドウによる検証に依存していましたが、後にこの仕組みを廃止しました。これは「状態」がエンジニアリング上つねに負担であることを示しています。クライアント側から見ると、ステートフルなプロトコルは接続の再利用（多重化）ができ、ハンドシェイクの繰り返しを減らせます。ただし大容量の単一接続には効果がなく、むしろすべての接続が同じ回線の揺らぎを共有してしまう可能性があります。

3つの軸を並べて見ると、6種類のプロトコルの位置づけがはっきりします。Shadowsocks と Vmess は汎用型で互換範囲が最も広く、Trojan と VLESS は TLS に載せる型で標準的な HTTPS の特徴が必要な導入に向き、Hysteria2 と TUIC は UDP 優先型でパケットロスや高遅延の回線で優位に立ちます。以降の3章で、この3つのグループをそれぞれ掘り下げます。

Shadowsocks：暗号化転送を薄く作る

Shadowsocks の設計目標はただ一つ、ローカルの通信を暗号化してそのまま転送し、プロトコル内に余計なネゴシエーションを入れないことです。クライアントとサーバーはパスワードを1つ共有し、そのパスワードから鍵導出関数でセッション鍵を生成、AEAD 暗号（AES-256-GCM または ChaCha20-Poly1305）をデータストリームに直接適用します。最初のパケットがすでに暗号文で、ハンドシェイクの往復がないため、接続確立の遅延はほぼ TCP ハンドシェイク1回分です。

代償は、プロトコル自体に身元の宣言がなく、サーバーは「誰が」接続しているかを知ることができず、パスワードでしか区別できないことです。Shadowsocks 2022 仕様（SIP022）はこの点を改善しました。セッション ID とリプレイ保護を導入し、鍵導出をマスター鍵とセッション鍵の2層に分け、UDP の扱いも改善しています。新旧バージョンのサーバーとクライアントの間には互換性の差があるため、導入前にサーバー側の実装が 2022 仕様に対応しているか確認してください。対応していないと「パスワードは合っているのに接続できない」という状況になります。

暗号スイートの選択にもコツがあります。AES-256-GCM はハードウェアアクセラレーション命令を備えた機器で速く、ルーターや低消費電力の機器では ChaCha20-Poly1305 のほうが安定します。安全性は同等で、違いは実装効率だけです。クライアントとサーバーは同じ暗号方式を使う必要があります。

Vmess：伝送層を選択式にする

Vmess は V2Ray プロジェクトのネイティブプロトコルで、核心的な変化は伝送層を抽象化したことです。同じ Vmess の身元を、素の TCP、mKCP、WebSocket、gRPC、HTTP/2 の上で動かせ、TLS を重ねることもできます。身元は UUID で表し、サーバーは UUID ごとにユーザーを区別し、統計や速度制限を行えます。この設計により Vmess の導入形態は非常に柔軟になります。標準的な WebSocket ポートを使いたい場面、gRPC の多重化を使いたい場面で、同じ身元設定を再利用できます。

柔軟性と引き換えに設定は複雑になります。Vmess の共有リンクは base64 でエンコードされた JSON で、フィールド名は実装間で統一されていません（ps、add、port、id、aid、net、type、host、path、tls、sni がそれぞれ情報の一部を表します）。変換ツールの扱いが適切でないとフィールドが欠落します。また、Vmess が持つ暗号化層は、すでに TLS を重ねている場合は二重暗号化になり、計算コストが VLESS より高くなります。これも VLESS が生まれた理由の一つです。

両者のトレードオフ

互換性だけを見れば、Shadowsocks と Vmess はもっとも対応範囲の広い2つのプロトコルです。オリジナル Clash、mihomo、Surfboard、各種モバイルクライアントが認識できます。違いはリソース消費と設定コストにあります。Shadowsocks は CPU に優しく、Vmess は柔軟です。UDP 転送については、Shadowsocks はサーバー側の実装で明示的に有効化する必要があり、Vmess は UDP over TCP の転送方式をネイティブにサポートしているため、TCP しか通さない環境では手間が少なくて済みます。

よくある誤解は「新しいプロトコルほど速い」というものです。同じサーバー、同じ回線で測ると、Shadowsocks と Vmess の実測スループットの差は、回線自体の変動より小さいことがほとんどです。実際に差を生むのはハンドシェイクの回数と TLS を重ねているかどうかです。選定ではプロトコルが登場した順序ではなく、クライアントの対応範囲とサーバー側の実装を優先してください。

Trojan：認証を TLS の内側に置く

Trojan のやり方は明快です。サーバーは 443 番で待ち受け、まず標準の TLS ハンドシェイクを完了します。クライアントはハンドシェイク完了後にパスワードを送り、サーバーが検証を通ってから転送を始めます。途中の転送機器から見ると、このポートの通信は普通の HTTPS サイトと区別がつきません。サーバーは同じポートで実在のサイトをフォールバックとして使うこともでき、認証を通らないリクエストはサイト側に処理させるため、1つのドメインでサイトとプロキシを同時に運用できます。

この設計の依存関係は明確です。有効な証明書、証明書と一致するドメイン、正しい SNI。3つのうちどれかがずれると、クライアントはハンドシェイク段階で失敗し、ログには「接続がリセットされました」や「TLS ハンドシェイクに失敗しました」といった大まかなメッセージしか残りません。Trojan の UDP 対応は実装によって差があり、ネイティブ実装は UDP associate を提供し、一部の実装は拡張版に依存します。設定面では Trojan は6種類の中で最も簡単で、アドレス、ポート、パスワード、SNI の4項目で動きます。

VLESS：二重暗号化をなくす

VLESS の設計前提はこうです。外側にすでに TLS があるなら、プロトコル内部で再度暗号化する必要はない。そこで VLESS 自体は暗号化を行わず、身元（UUID）と宛先アドレスの運搬だけを担い、安全性は下層の伝送に完全に委ねます。この割り切りが Vmess で最も重かった計算コストを削り、サーバーをステートレスにしました。セッションを維持する必要も、タイムスタンプを検証する必要もなく、再起動しても以降の接続確立に影響しません。

VLESS のもう一つの変化はフロー制御です。Vision フロー（flow フィールドに xtls-rprx-vision を指定）は TLS 層の内側でパディングと分割を行い、TLS の入れ子構造による追加コストを減らします。注意したいのは、flow パラメータがクライアントとサーバーの間の取り決めであることです。サブスク変換ツールがこのフィールドを捨ててしまうと、接続は通常の TLS モードに退化します。機能的には使えますが、性能特性は想定と変わります。確認方法は接続ログを開き、実際に使われているフロー制御方式を確かめることです。

証明書と時刻：もっとも多い2つの問題

TLS に載せるタイプのプロトコルの不具合は、多くがプロトコル自体ではなく証明書チェーンにあります。自己署名証明書はクライアント側で検証を明示的にスキップする必要があり、長期的な運用には向きません。証明書チェーンが不完全な場合、デスクトップのブラウザは中間証明書をキャッシュしていて正常に見えることがありますが、クライアントはそのままエラーを出します。もう一類はシステム時刻の問題です。時刻のずれが証明書の有効期間の許容範囲を超えると検証に失敗しますが、症状は「ノードが使えない」ように見えるため、サーバー側の障害と誤判定されがちです。

切り分けの順序は固定しておくのがおすすめです。まずクライアントのログでエラーの種類（ハンドシェイク失敗、証明書検証失敗、接続タイムアウト）を見て、次にシステム時刻、証明書チェーン、SNI の3項目を順に潰していきます。証明書エラーの切り分け手順の全体は、技術ノート「Clash 環境での HTTPS 証明書エラー：よくある原因と確認順序」で解説しています。

Hysteria2：設定した帯域幅で送信する

Hysteria2 は伝送層を QUIC（HTTP/3 の下層プロトコル）に置き換え、TLS 1.3 を内蔵するため暗号スイートを別途設定する必要はありません。最も特徴的なのは輻輳制御です。デフォルトでは Brutal を使い、クライアントが設定した上下限の帯域幅で固定レート送信し、回線にパケットロスが生じても自主的に速度を落としません。この戦略はパケットロス率の高い回線でスループットを維持できますが、前提として帯域幅のパラメータが実測値に近い必要があります。大きすぎると同じ回線の他の通信を圧迫し、小さすぎるとプロトコル本来の利点を活かせません。

Hysteria2 には UDP 層の難読化オプション（salamander）もあり、QUIC パケットを軽くラップします。サーバー側は UDP ポートを1つ用意するだけでよく、ユーザーごとにポートを割り当てる必要がないため、導入も増設も TCP 系プロトコルより簡単です。設定項目は Trojan よりやや多く、アドレス、ポート、パスワード、SNI、帯域幅の上下限、証明書検証をスキップするかどうかです。

TUIC：0-RTT とネイティブな UDP 転送

TUIC も QUIC をベースにし、設計は「QUIC の能力をそのまま使い切る」方向に寄っています。v5 では 0-RTT ハンドシェイクに対応し、セッションを再利用する際に往復を1回省略できます。UDP 転送には2つのモード（native と quic）があり、前者は UDP パケットを直接カプセル化し、後者は QUIC ストリームを通します。回線の特徴に応じて選びます。輻輳制御アルゴリズムは bbr、cubic、new_reno から切り替えられ、Hysteria2 の固定レート戦略と対照的です。

TUIC の身元は UUID とパスワードの組み合わせで表し、設定項目の数は Vmess に近いです。クライアントへの要求はより高く、カーネルが QUIC スタックを完全に実装している必要があるため、現時点では mihomo 系カーネルのみが対応しています。サーバー側も UDP ポートを1つ用意するだけで、複数ユーザーが同じポートを共有しても互いに干渉しません。

QUIC 系に共通する代償

QUIC はユーザー空間で実装される点が最大のエンジニアリング上の代償です。暗号化、輻輳制御、再送のすべてをアプリケーション内で行うため、CPU 使用率はカーネル空間の TCP より高くなります。モバイルで継続的に通信すると、バッテリー消費の差は TCP 系プロトコルよりはっきり出ます。メモリ使用量も QUIC のバッファの分だけ増えます。デスクトップやサーバーではこのコストは通常許容範囲ですが、ルーターや低スペック機器、長時間のモバイル利用ではトレードオフが必要です。

もう一つの現実的な制約は UDP ポートそのものです。一部の企業ネットワークや公共 Wi-Fi は UDP を制限したり優先度を下げたりするため、その環境では QUIC 系プロトコルの性能が明確に落ち、TCP 系プロトコルへ戻す必要があります。だからこそ Hysteria2 と TUIC は唯一のノードではなく予備ノードとして向いており、サブスクに TCP 系ノードを1つ残しておくと切り替えのコストが最小になります。

3者の関係

オリジナル Clash カーネルは config.yaml の基本骨格を定義しました。proxies、proxy-groups、rules、proxy-providers、rule-providers、dns、tun といったセクション、そして mode、log-level、mixed-port、external-controller といったトップレベルフィールドです。この骨格は後にエコシステム全体の事実上の標準となり、ほぼすべてのクライアントがこれに沿って設定を組み立てています。オリジナルカーネルはすでにメンテナンスが終了していますが、そのフィールド命名は現在まで引き継がれています。

Clash.Meta はオリジナルをベースにした拡張ブランチで、新しいプロトコル、新しいルール種別、より完全な TUN 実装を追加しました。このブランチは後に mihomo へ改名され、リポジトリとドキュメントは MetaCubeX 組織の下へ移りました。現在も更新が続く GUI クライアント——Clash Verge Rev、Clash Meta for Android、FlClash、Clash Nyanpasu、ClashX Meta——はいずれも mihomo カーネルを使っています。Clash for Windows はオリジナルカーネルを使い、アーカイブされてメンテナンスが終了しています。オリジナルの設定は引き続き読み込めますが、後に追加されたフィールドは認識しません。

あるクライアントがどのカーネルを使っているかを判断する最も直接的な方法は、ログのバージョン行と設定の解析結果を見ることです。設定の読み込み時に未知のフィールドが通知されるなら、そのカーネルのフィールド集合は小さめです。sniffer、listeners、rule-set といったセクションを認識できるなら mihomo 系です。オープンソースエコシステムにおける各プロジェクトの関係は、技術ノート「Clash オープンソースエコシステムの全体像：カーネル、クライアント、ルールセットの関係」で解説しています。

機能差の対照表

設定の互換性と移行

オリジナルカーネルから mihomo への移行はほぼ無痛です。オリジナル設定のセクションとフィールドは mihomo でもすべて維持されているため、そのまま読み込めます。逆方向の移行には注意が必要で、mihomo の拡張フィールドはオリジナルカーネルで解析エラーを引き起こすため、1つずつ削除する必要があります。削除が必要になりやすいセクションには sniffer、listeners、sub-rules、および rule-providers の mrs 形式の宣言があります。

# 以下のセクションは mihomo 系カーネルのみが認識します。オリジナルカーネルでは未知のフィールドとしてエラーになります
sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080]
      override-destination: true
    TLS:
      ports: [443, 8443]

両方のカーネルの解析スタイルは厳格です。知らないフィールドに遭遇すると無視せず、そのままエラーを出します。この特性は移行時に利点になります。設定に問題があればすぐに表面化し、黙って機能が落ちることはありません。unknown field といったログを見かけたら、まずクライアントのフィールド集合を確認し、それからフィールドを削除するかクライアントを替えるかを決めてください。

もう一つ見落としやすい違いは DNS セクションです。mihomo は dns の設定項目を拡張しており（nameserver-policy、fallback-filter のマッチ方式、名前解決をルールに従わせるかどうかなど）、オリジナルカーネルの dns セクションはより単純です。移行時に古いフィールドを残した場合は、新しいカーネルがまだ受け付けるかを確認してください。逆に、拡張フィールドを含む dns セクションをオリジナルカーネルに持っていくと、そのまま解析に失敗します。

4つのサブスク形態

1つ目は完全な YAML サブスクです。サーバーが config.yaml をそのまま返し、proxies、proxy-groups、rules とポート設定を含みます。クライアントは読み込むだけですぐ使えます。この形態はユーザーにとって最も手間が少ないですが、ルール戦略をサブスク提供側が決めてしまうため、自分のルールは別途管理する必要があります。2つ目は共有リンクのリストです。base64 でエンコードされた複数行のテキストで、各行が ss://、vmess://、trojan://、vless://、hysteria2://、tuic:// のいずれかのリンクです。クライアントが解析してノード一覧を得て、ルールはクライアント側で決めます。

3つ目は変換サービスです。共有リンクのリストを Clash YAML に変換し、途中でルールテンプレートを適用できます。変換サービスはクライアントが共有リンクを認識できない問題を解決しますが、同時に新たな情報の欠落を持ち込みます。4つ目は proxy-providers です。クライアントがリモートアドレスからノード一覧を定期的に取得し、ローカルのルールと分離します。複数サブスクの統合に向いています。

proxy-providers：ノードとルールを分ける

proxy-providers を使うと、クライアントがリモートからノード一覧を定期的に取得し、ローカルのルールと分離できます。複数サブスクの統合やチームでの設定共有に向いています。ルールはローカルに書き、ノードはリモートから更新します。provider ごとに更新間隔、ヘルスチェックのアドレス、フィルタ式を個別に設定できます。

proxy-providers:
  provider-a:
    type: http
    url: "https://example.com/subscribe/xxxx"
    interval: 3600
    path: ./providers/provider-a.yaml
    filter: "(?i)(hk|sg|jp)"
    health-check:
      enable: true
      url: https://example.com/generate_204
      interval: 300

フィルタ式は provider の中で最も実用的な2つのフィールド、filter と exclude-filter で、ノード名を正規表現でマッチさせます。たとえば名前に特定の地域識別子を含むノードだけを残したり、一時的なノードを除外したりできます。注意したいのは、フィルタがクライアント側で行われることです。サーバーが返したノードはローカルファイルにダウンロードされますが、利用可能な一覧には入りません。「ノードが減った」という問題を調べるときは、まずフィルタ式を見て、次にサーバーが返した内容を確認してください。

変換と更新でよくある落とし穴

共有リンクを YAML に変換する過程で情報が失われるのが、最もよくある問題の源です。vless:// の flow パラメータ、hysteria2:// の難読化と検証スキップのオプション、tuic:// の輻輳制御と UDP 転送モードは、一部の変換ツールに対応するフィールドがなく、変換後に接続がデフォルトパラメータへ退化します。判断方法は「接続できるか」だけを見るのではなく、変換前後のノードパラメータを比較することです。

proxies:
  - name: "ss-a"
    type: ss
    server: 203.0.113.10
    port: 8388
    cipher: aes-256-gcm
    password: "your-password"
  - name: "vless-a"
    type: vless
    server: 203.0.113.11
    port: 443
    uuid: b831381d-6324-4d53-ad4f-8cda48b30811
    tls: true
    servername: example.com
    flow: xtls-rprx-vision
  - name: "hy2-a"
    type: hysteria2
    server: 203.0.113.12
    port: 443
    password: "your-password"
    sni: example.com
    up: "30 Mbps"
    down: "200 Mbps"

2つ目の問題は YAML の構文そのものです。ノード名にカンマ、コロン、引用符が含まれるとき、引用符で囲んでいないと設定全体の解析に失敗します。この種のエラーは通常「サブスクの更新は成功したのにノード一覧が空」という形で現れます。3つ目はサブスク内のポート設定です。一部のサブスクは port、socks-port フィールドを含みますが、クライアントは通常それらを無視してローカル設定を使います。ローカルのポートが変わっている場合は、まずクライアントのポート上書きオプションを確認してください。

サブスク更新に失敗したときの切り分け順序は固定しておくのがおすすめです。まずリンクがブラウザで直接開けるか（ログインページではなくテキストが返るか）を確認し、次にクライアントのログで HTTP ステータスコードを確認し、最後にサブスクがクライアントの知らないプロトコルを含んでいないかを確認します。未知のプロトコルを含むノードはスキップされ、残りのノードは正常に読み込まれます。サブスク関連の切り分け項目の詳細はよくある質問ページにまとめています。

クライアントがプロトコルの上限を決める

mihomo 系カーネルのクライアントはプロトコル一式に対応しています。Shadowsocks、Vmess、Trojan、VLESS、Hysteria2、TUIC をすべて認識できます。オリジナルカーネルを使う Clash for Windows はアーカイブされメンテナンスが終了しており、Shadowsocks、Vmess、Trojan、Snell、HTTP / SOCKS5 といった第1世代のプロトコルしか対応していません。Surfboard の対応範囲も Shadowsocks、Vmess、Trojan が中心です。サブスクに VLESS や Hysteria2 のノードが含まれている場合、アーカイブされたクライアントではそれらがそのままスキップされ、「ノード数がサブスクより少ない」という症状になります。

全プラットフォームで最初に勧められるクライアントは Clash Plus です。Windows、macOS、Android、iOS に対応版があり、iOS 版は App Store から入手します。公式サイトのドメインは clashplus.io で、サブスクの読み込みとルールによる振り分けの方法は他のクライアントと同じです。デスクトップではほかに Clash Verge Rev（Windows / macOS / Linux）、FlClash（全プラットフォーム）、Clash Nyanpasu（Windows）が選べます。Android では Clash Meta for Android と FlClash がよく使われ、macOS では Clash Verge Rev のほかにアーカイブ済みの ClashX Meta もあります。各プラットフォームのインストーラの入口はクライアントの入手ページにまとめています。

プラットフォームごとの違い

デスクトップはリソースに余裕があるため、QUIC 系プロトコルを安心して使え、CPU 使用率はボトルネックになりません。Android ではシステムのバックグラウンド省電力ポリシーに注意が必要です。省電力モードはバックグラウンドのネットワーク活動を制限し、QUIC の長い接続はバックグラウンドでシステムに一時停止されることがあり、「戻ってくると再接続が必要」という症状になります。こうした場面では TCP 系プロトコルのほうが安定するか、クライアントのキープアライブ設定を緩めにしてください。

iOS はネットワーク拡張をシステムが一元管理するため、クライアントの選択は App Store で配信されている版が基準になります。設定の読み込み手順はデスクトップと同じで、サブスクリンクを読み込む方式です。ルーターや低スペック機器では、ユーザー空間で実装された QUIC スタックの負荷がはっきり出るため、Shadowsocks のような軽量なプロトコルが適しています。機器のメモリにも注意が必要で、ルールセット自体も一定量を消費します。

用途別の選定表

プロトコル自体のほか、クライアントの選択は更新のペースにも影響されます。メンテナンスが続くクライアントはカーネルの新しいプロトコルとフィールドに追随しますが、アーカイブされたクライアントは既存の能力にとどまります。クライアント同士の横比較は、技術ノート「主要 Clash クライアントの横比較：プラットフォームと使い方から選ぶ」で解説しています。

移行前の準備

クライアントやプロトコルを替える前に、現在の設定をエクスポートしてバックアップします。プロファイルファイル、ルールファイル、サブスクリンクです。アーカイブされたクライアント（Clash for Windows、ClashX Meta）の設定は引き続き使え、エクスポートした config.yaml は mihomo 系クライアントでほぼそのまま読み込めます。削除が必要なのはカーネルが認識しない新しいフィールドで、方向としてはオリジナルから mihomo への移行と逆になります。

プロトコルを替えるときは3点を確認します。サーバーが目的のプロトコルに対応しているか、ポートが開放されているか（QUIC 系は UDP が必要）、サブスクにそのプロトコルのノードが含まれているか。どれか1つでも欠けると、クライアントに使える接続は現れません。サーバーが共有リンクしか提供していない場合は、まずリンクのプロトコル接頭辞がクライアントの対応範囲と一致するかを確認してから読み込んでください。

移行後の検証

検証はルールから始めるのがおすすめです。クライアントの接続ログを開き、通信が想定したルールとポリシーグループにヒットしているか、デフォルトの直結続やデフォルトのプロキシに落ちていないかを確認します。次に DNS を検証します。解決結果が設定の nameserver とポリシーに沿っているか、想定外の解決元が出ていないかを確認します。最後に UDP 転送を検証します。UDP が必要なアプリが正常に動くかどうかで、これは QUIC 系プロトコルでは通常ネイティブに対応しており、Shadowsocks ではサーバー側の設定次第です。

proxy-providers を使っている場合は、サブスクの定期更新が成功しているかも追加で確認します。ログには毎回の取得時刻と結果が記録されます。ノード一覧がフィルタ式で空になっていないかも合わせて確認してください。更新に失敗するよくある原因は、リンクの失効、返ってくる内容が YAML でない、フィルタ式がすべてのノードを除外している、の3つです。

よくある切り戻しの場面

QUIC 系プロトコルは UDP を制限するネットワークでは性能が落ちます。その場合は TCP 系プロトコルに戻せばよく、サブスクを替える必要はありません。証明書関連の問題はシステム時刻と証明書チェーンを優先して確認してください。具体的な手順は技術ノート「Clash 環境での HTTPS 証明書エラー：よくある原因と確認順序」にあります。サブスク更新の失敗はリンクの到達性とクライアントのログを優先して確認してください。よくある原因はよくある質問ページにまとめています。

移行の目的がメンテナンス終了済みクライアントの置き換えである場合、全体の流れ（設定のエクスポート、カーネルの置き換え、代替案の比較）は技術ノート「クライアントの更新停止後に：設定のエクスポート、カーネルの置き換えと代替案」で解説しています。移行が完了したら、新しい設定と古い設定をそれぞれ1部ずつ残し、1〜2週間様子を見てから古いファイルを削除することをおすすめします。