Clashを基礎から攻略：インストール、サブスクリプション、ルール、TUN

基礎概念：クライアント、コア、設定を区別する

Clashは単一のインストーラーではない

「Clash」は通常、ルールベースのプロキシを中心としたクライアントとコアのエコシステム全体を指し、固定された1つの画面を持つソフトウェアだけを意味するわけではありません。ユーザーが直接操作するのはClash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android、ClashX MetaなどのGUIクライアントです。実際にプロキシ接続を確立し、設定を解析してルールに照合するのはコアの役割です。現在よく使われるクライアントの多くはmihomoコアを採用しており、画面側はコアの機能をスイッチ、リスト、ステータス画面として整理して表示します。

この関係を理解することは重要です。画面が開かない、サブスクリプションを更新できない、特定のルールが機能しない、といった問題は別々の層に属することが多くあります。画面がクラッシュするなら、まずクライアント自体を確認します。プロトコルやルールの挙動がおかしい場合は、コアのログと設定を確認します。サブスクリプションの内容が不完全なら、先に配信元を確認します。3つを混同して調べると、原因に触れないまま再インストールを繰り返すことになります。

1つの接続はどのように処理されるか

アプリがネットワークリクエストを開始すると、通信はまずClashに入る必要があります。システムプロキシは、OSのプロキシ設定を提供し、それに対応するアプリへ通信経路を案内します。TUNモードは仮想ネットワークインターフェースを作成し、より広い範囲の通信をネットワーク層から受け取ります。コアはリクエストを受け取ると、対象ドメイン、対象IP、ポート、プロセスなどを識別し、設定ファイルのルールを上から順に照合します。照合結果はポリシーグループを指し、そこから具体的なノード、直接接続、接続拒否のいずれかが決まります。

ドメインリクエストにはDNSも関わります。DNSはドメインをIPに変換するだけでなく、ルールが元のドメインを認識できるか、DNS汚染が起きるか、IPv4とIPv6のどちらを選ぶかにも影響します。通常の経路は次のように整理できます：アプリがリクエストを開始 → システムプロキシまたはTUNが取り込む → DNSがアドレスを取得またはドメインをマッピング → ルール照合 → ポリシーグループが出口を選択 → ノードが接続を確立。以降の設定の多くは、この経路の一部を調整するものです。

サブスクリプション、設定ファイル、ノードの違い

サブスクリプションリンクは、設定内容を取得する入口です。クライアントがリンクへアクセスすると、サーバーは完全なYAMLを直接返す場合もあれば、エンコードされたノード一覧を返す場合もあります。完全な設定には通常、プロキシノード、ポリシーグループ、ルール、DNS、その他のコアパラメータが含まれます。ノード一覧だけのサブスクリプションでは、クライアントのテンプレートやサブスクリプション変換サービスによってポリシーグループとルールを補う必要があります。ノードは接続先の1つにすぎず、完全な設定の代わりにはなりません。

ローカルに保存する設定ファイルは、通常YAMLで記述します。YAMLはインデントに依存するため、階層にはスペースを使い、タブを混在させないでください。同じ階層のフィールドは同じインデントを保ち、リスト項目はハイフンで始めます。「設定の解析に失敗しました」というエラーは、プロトコルの非互換ではなく、コロンの後のスペース不足、インデントのずれ、同名フィールドの重複、特殊文字の引用漏れが原因であることも少なくありません。編集前に元ファイルを保存しておくほうが、後から記憶を頼りに復元するより安全です。

mixed-port: 7890
mode: rule
allow-lan: false
log-level: info

proxies:
  - name: "Example Node"
    type: socks5
    server: 192.0.2.10
    port: 1080

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - "Example Node"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,PROXY
  - MATCH,DIRECT

コントロールパネルでよく見るステータス

「システムプロキシ」は、クライアントがOSのプロキシ設定を変更していることを示しますが、すべてのプログラムが従うとは限りません。「TUN」は仮想ネットワークインターフェースによる取り込みが有効であることを示しますが、ルーティング、DNS、権限が正常かどうかも確認が必要です。「Rule」はルールモードで、ルールに従って通信を分岐します。「Global」はグローバルモードで、通常はすべてのリクエストを1つのポリシーグループへ渡します。「Direct」はできるだけ直接接続します。これらは別の次元の設定であり、どれか1つしか選べないわけではありません。たとえば、システムプロキシとRuleモードを同時に有効にしたり、TUNとRuleモードを組み合わせたりできます。

初めからすべてのフィールドを理解する必要はありません。まず、クライアントは操作を担当し、コアは実行を担当し、設定は動作を記述し、サブスクリプションは設定を更新し、ルールは出口を選ぶ、と覚えてください。機能を追加するたびに、この5つの位置に当てはめて考えられます。見慣れないクライアントでも、画面上の名称が違うだけで、機能から対応する設定を見つけやすくなります。

クライアントの選び方：プラットフォームと用途で決める

GUIクライアントとコア単体、どちらから始めるか

デスクトップやスマートフォンを使う人の多くは、GUIクライアントから始めるのが適しています。GUIクライアントは、設定の保存、システムプロキシ、スタートアップ、サブスクリプション更新、ポリシーグループの切り替え、ログ確認をまとめて処理するため、問題が起きても状態を確認しやすくなります。mihomoコアを直接動かす方法は、サーバー、ルーター、コンテナ環境、またはサービスプロセスを自分で管理したいユーザーに向いています。この方法では、設定、待受ポート、起動オプション、常駐サービスを手動で用意し、権限やログローテーションも自分で管理する必要があります。

当サイトのダウンロードページでは、Windows、macOS、Android、iOS、Linux、コア別に分類しています。Clash Plusは主要プラットフォーム向けの第一候補で、操作手順をそろえ、サブスクリプションを直接読み込みたいユーザーに適しています。Clash Verge Rev、FlClash、Clash NyanpasuはデスクトップGUIを提供します。Clash Meta for AndroidとSurfboardはAndroid向けです。ClashX Metaはメンテナンス終了済みのmacOS向けアーカイブクライアントで、Clash for Windowsも同様に開発が終了しています。旧設定の確認やデータ移行が必要な場合に限って利用してください。

WindowsとmacOSの選び方

Windowsでは、まずシステムのアーキテクチャを確認します。一般的なPCの多くはx64で、ARM Windowsデバイスには対応するアーキテクチャのパッケージが必要です。インストーラー版はショートカットの作成やアンインストールを処理しやすく、圧縮ファイル版は独立して保管しやすい一方、更新やファイル関連付けを手動で管理する場合があります。初回起動時にWindowsファイアウォールの確認が表示されたら、実際の利用範囲に応じてプライベートネットワークへのアクセスを許可するか決めます。LAN上の機器から本機のプロキシポートへ接続する必要がある場合のみ、LANアクセスも有効にします。

macOSではApple SiliconとIntelを区別します。Apple Silicon版はMシリーズチップ搭載機向けで、Intel版は以前のx86_64搭載機向けです。アーキテクチャを間違えると起動できない場合があり、互換レイヤーで動作しても別の問題が起きることがあります。クライアントが初めてシステムプロキシを変更したり、ネットワーク拡張を作成したり、TUNを有効にしたりすると、管理者の許可を求められます。これはネットワーク設定を書き込むための正常な手順です。サブスクリプションだけを先に確認したい場合は、TUNを有効にせず、システムプロキシで基本接続を確認できます。

モバイルプラットフォームでは機能の多さだけで選ばない

Androidクライアントは通常、システムVPNインターフェースで通信を取り込みます。インストール後はVPN接続の確立を許可し、端末メーカーの設定に応じてバッテリー最適化、バックグラウンド動作、自動起動の権限を調整します。バックグラウンドに移して数分後に接続が消える場合は、すぐにノードを変更せず、省電力設定を優先して確認します。アプリ単位のプロキシでは、トンネルに入れるアプリを制御できますが、クライアントによって「包含モード」と「除外モード」の意味が逆になるため、保存前に説明を確認してください。

iOSとiPadOSもシステムVPN構成を通じて動作します。初回接続時にはシステムの許可画面が表示され、承認後にトンネルを確立できます。Wi-Fiとモバイル通信を切り替えた際の短い再接続は、ネットワーク経路が変わったことによるものです。復旧しない場合は、いったん切断して再接続し、サブスクリプション内のノードが利用可能か確認します。モバイル端末はリソースに限りがあるため、最初から大規模なルールセットや大量の設定コピーを読み込むことはおすすめしません。

メンテナンス終了済みクライアントの扱い

メンテナンス終了は、既存の設定がすぐ無効になることを意味しません。ただし、今後のシステム更新、プロトコル変更、セキュリティ問題に対応されない可能性があります。Clash for WindowsとClashX Metaは旧環境からの移行には使えますが、新規インストールの長期的な第一候補には向きません。移行時は、まず既存の設定ディレクトリをエクスポートまたは特定し、よく使うポリシーグループの選択を記録します。その後、新しいクライアントでサブスクリプションを読み込み直してください。旧クライアントのプログラムディレクトリ全体を新クライアントのディレクトリへ上書きするのは避けます。データ構造や設定フィールドが異なる場合があります。

クライアント選びで設定項目の多さを追求する必要はありません。サブスクリプションを安定して更新でき、システムプロキシまたはTUNを正しく有効にでき、ログを確認しやすければ、多くの用途を満たせます。特定のインストーラーが必要な場合はダウンロードセンターでプラットフォームのタグを選んでください。先にプラットフォームとアーキテクチャを確認してから対応ファイルをダウンロードすれば、実際にはパッケージの不一致にすぎない問題を避けられます。

インストールと初回起動：まず基本経路を通す

インストール前に旧環境を整理する

同じ端末に複数のクライアントを保存することはできますが、同時にシステムプロキシを変更したりTUNを作成したりするのは避けてください。新しいクライアントをインストールする前に、旧クライアントでシステムプロキシとTUNを無効にし、完全に終了します。Windowsではシステムのネットワークプロキシ設定で手動プロキシが無効か確認します。macOSでは現在のネットワークサービスのプロキシ画面でHTTP、HTTPS、SOCKSの項目を確認します。モバイル端末では、旧VPNが切断されていることを確認します。これにより、2つのクライアントがポートを奪い合ったり、システム設定を繰り返し上書きしたりするのを防げます。

旧設定を移行する場合は、まず設定ディレクトリをコピーするかYAMLをエクスポートします。残すべきなのは、サブスクリプションアドレス、自分で変更したルール、ポリシーグループの選択、DNSの調整であり、キャッシュ、ログ、一時データベースではありません。サブスクリプションアドレスは個人利用情報なので、公開スクリーンショット、フォーラム、コードリポジトリに載せないでください。バックアップ後、ダウンロードセンターからプラットフォームに対応するインストーラーを選びます。

Windowsのインストールと初回確認

Windowsのインストーラーをダウンロードしたら、ウィザードでインストール先を選び、クライアントを起動します。ネットワークコンポーネントのインストールや管理者権限を求められた場合は、操作しているものが確かにダウンロードしたクライアントか確認してから続行します。起動後はすべてのスイッチを急いで有効にせず、まず「設定」または「サブスクリプション」画面が正常に表示されるか確認します。その後、設定画面で混合ポート、システムプロキシ、TUNの状態を確認します。

ローカルの混合ポートには7890がよく使われますが、必ずこの値に固定する必要はありません。他のプログラムが使用しておらず、手動でプロキシを設定するアプリが同じポートを使えば問題ありません。ログに「address already in use」と表示される場合は、待受ポートが競合しています。他のプロキシプログラムを終了するか、mixed-portを未使用のポートへ変更してください。ポートを変更したら、ブラウザー拡張、開発ツール、コマンドライン環境のプロキシアドレスも合わせて変更します。

netstat -ano | findstr :7890

curl.exe -x http://127.0.0.1:7890 https://example.com/

1つ目のコマンドはWindowsで7890ポートを使用しているプロセスを確認し、2つ目はローカルHTTPプロキシ経由で明示的にリクエストを送ります。テストアドレスはプロキシポートが接続を受け付けられるかを確認するためのもので、実際のサービスサイトにアクセスできるかを示すものではありません。curlが127.0.0.1へ接続できない場合は、遠隔ノードではなく、まずクライアントのコアが起動しているか確認します。

macOSのインストールとシステム許可

macOSでは、ダウンロード後にアプリを通常「アプリケーション」フォルダへ移し、その場所から起動します。初回起動時に開発元の確認や権限に関する通知が出た場合は、システムのセキュリティ設定から確認を完了します。システムプロキシを変更するときは管理者の許可を求められる場合があります。TUNやネットワーク拡張を有効にすると、新しいVPN構成の追加を許可するよう求められることもあります。許可後にクライアントへ戻り、スイッチが本当に有効になっているか確認してください。通知が消えただけで成功と判断しないことが大切です。

メニューバーに別のプロキシクライアントのアイコンがある場合は、先に旧プログラムを終了します。システムプロキシが有効と表示されているのにブラウザーへまったく反映されない場合は、「システム設定 → ネットワーク → 現在のネットワーク → 詳細 → プロキシ」で、アドレスが127.0.0.1を指し、ポートがクライアントと一致しているか確認します。クライアントを終了する前にシステムプロキシを無効にし、クライアント自身に設定を解除させるのがおすすめです。異常終了でプロキシが残った場合は、システムのネットワーク設定から手動で解除できます。

Android、iOS、Linuxの初回起動

Androidでは、インストール後にVPN接続の確立に必要な権限を許可します。「常時接続VPN」が有効で別のアプリに割り当てられている場合は、先に設定を変更してください。そうしないと新しいクライアントが通信を取り込めません。一部の端末ではバックグラウンド通信やバッテリー使用が制限されます。接続は確立するのに画面ロック後に切れる場合は、バックグラウンド動作を許可する対象へクライアントを追加します。初回テストでは複雑なアプリ単位のルールを無効にし、すべてのアプリが通ることを確認してから除外項目を少しずつ追加します。

iOSまたはiPadOSでApp StoreからClash Plusをインストールした後、初回接続時に新しいVPN構成の追加を許可します。ステータスバーにVPNアイコンが表示されても、トンネルが確立したことを示すだけで、サブスクリプション内のすべてのノードが利用できるとは限りません。クライアントに戻って接続ログを確認し、一般的なウェブページでテストしてください。モバイル通信では使えるのにWi-Fiでは使えない場合は、現在のWi-FiのDNS、認証ページ、ルーターの制限を確認します。

LinuxのGUIクライアントは、パッケージ形式とディストリビューションによってインストール方法が異なります。Debian、Ubuntuとその派生環境ではdebパッケージを使用できます。その他のディストリビューションでは、対応するパッケージ形式を選びます。インストール後にトレイアイコンが表示されなくても、コアが動いていないとは限りません。アプリのウィンドウとプロセス一覧から確認できます。mihomoコアを単独で動かす場合は、設定ディレクトリを明示し、先に設定テストを実行します。

mihomo -t -d ./clash-config
mihomo -d ./clash-config

-tは設定を解析できるか確認し、-dは設定ファイルと実行データを含むディレクトリを指定します。起動前にテストを行うと、YAMLの形式エラーとネットワーク接続エラーを切り分けられます。長期的なサービスとして動かす場合は、システムのサービスマネージャーで自動起動、クラッシュ時の再起動、ログを管理し、ターミナルを常に前面に置く方法は避けます。

初回起動後の最小限の受け入れ確認

インストール後は決めた順番で確認します。クライアント画面が正常に開くこと、コアが実行中と表示されること、ローカルポートが正常に待ち受けていること、システムプロキシまたはVPN/TUNの少なくとも1つで通信を取り込んでいること、設定を読み込んだ後にポリシーグループが表示されること、利用可能なノードを選ぶと接続ログが出ることを確認します。「特定のサイトが開くか」だけを唯一の基準にしないでください。サイト自体、DNS、ルール、ノードの出口が結果に影響するためです。

基本経路が通っていない場合は、まずFake-IP、ルールセット、スクリプトを調整しないでください。初期設定を保つほうが原因を特定しやすくなります。ダウンロードとインストールに関するよくある疑問はダウンロードページのFAQで確認できます。最短の手順だけを進めたい場合は、使い方ガイドに戻ってください。

サブスクリプションの読み込み：リンクを利用可能な設定へ

読み込み前にサブスクリプションの返却内容を確認する

サブスクリプションリンクは通常、サービス提供者が発行し、識別用パラメータを含む場合があります。アカウント情報と同じように管理してください。完全なURLを公開スクリーンショット、ブラウザーの同期メモ、公開リポジトリに載せないでください。読み込む前に、リンクの有効期限が切れていないか、サービス側がClashまたはmihomo形式を明示的に提供しているか確認できます。ブラウザーで開けても、クライアントが解析できるとは限りません。ブラウザーでテキストをダウンロードできても、それが完全なYAMLとは限りません。

完全な設定には少なくともプロキシノードとポリシーグループが含まれ、一般的なフィールドとしてproxies、proxy-groups、rulesがあります。返却内容がエンコードされた文字列だけの場合、クライアントで汎用サブスクリプションとして認識した後、Clash設定へ変換する必要があります。変換をリモートサービスで行う場合、そのサービスがサブスクリプションアドレスを読み取ることを理解しておいてください。サービス提供者が明示的に対応している形式を優先し、経由するサービスを減らすほど障害点も減ります。

クライアントにサブスクリプションを追加する

クライアントによって入口は「サブスクリプション」「設定」「Profiles」「リモート設定」など異なりますが、操作の流れはほぼ同じです。リモート設定を新規作成し、リンクを貼り付け、識別しやすい名前を入力して保存し、更新を実行します。更新に成功したら、その設定を現在の設定に切り替え、ポリシーグループ画面で出口を選びます。リンクをリストに追加しただけで現在の設定へ切り替えていない、というのは初回利用でよくある見落としです。

設定名は「日常用サブスクリプション」や「予備設定」のように用途を表す名前にします。アクセス情報を名前へ書く必要はありません。自動更新の間隔を短くしすぎないでください。サブスクリプションの内容は数分単位で変わるものではなく、頻繁な更新はリクエストを増やし、サービス側の制限を招く可能性があります。1日ごと、またはサービス提供者の推奨頻度で更新し、変更をすぐ取得したいときだけ手動更新します。

更新に失敗したらレスポンスの段階で切り分ける

「接続できません」は通常、リクエストが有効なレスポンスをまだ受け取れていないことを示します。現在のネットワーク、ドメイン解析、システム時刻、リンク全体を確認します。「リクエストが拒否されました」やHTTP認証系のエラーは、リンクの期限切れ、パラメータ不足、アクセス条件が原因であることが多くあります。「解析に失敗しました」は内容を受け取ったものの、形式がクライアントの想定と異なることを示します。ウェブページが返っている、エンコードされたサブスクリプション、YAMLのインデントミス、クライアントが未対応のフィールドなどがよくある原因です。「更新成功なのにノードが空」の場合は、サブスクリプション自体にノードが含まれているか、フィルターですべて除外されていないか確認します。

切り分けでは、まず現在の端末のブラウザーのアドレス欄へリンクを貼り付け、レスポンスの種類だけを確認します。他人へ転送しないでください。ログインページ、エラーページ、認証ページへ移動するなら、クライアントが設定として解析できないのは当然です。ブラウザーでファイルをダウンロードした場合は、テキストエディターで先頭部分を確認できます。完全なYAMLならキー名とインデントが見えることが多く、ウェブページはHTMLタグで始まることが多く、エンコードされたサブスクリプションは連続した1行の文字列になる場合があります。

サービスによっては、リクエストのUser-Agentに応じて異なる形式を返します。クライアント設定にサブスクリプション用User-Agentの項目がある場合は、サービス提供者の指定値を優先し、思いつきで複数の偽装名を試さないでください。サブスクリプションの解析、キャッシュ、形式変換をさらに詳しく切り分ける場合は、Clashサブスクリプションリンクが無効なときの確認手順を参照してください。

ローカル編集とリモート更新の上書き関係

リモートサブスクリプションを更新すると、通常は設定が再書き込みされるため、生成されたYAMLへ直接追加したルールは次回更新時に消える可能性があります。長期的に残す変更は、クライアントが提供するオーバーライド、マージ、スクリプト機能を使います。対応していないクライアントなら、独立したローカル設定を保存し、明確な更新手順を作ってください。リモート設定を自動更新しながら、恒久的な手書きファイルとして扱うのは避けます。

マージの仕組みは通常、前方への挿入、後方への追加、フィールドの上書きに分かれます。ルールには順序があるため、カスタムルールを優先するなら一般的なルールより前へ挿入します。DNS、ポート、モードなどの単一値フィールドは、後から書き込まれた値で上書きされるのが一般的です。オーバーライド構文の実装はクライアントによって完全には一致しないため、クライアントを移行するときは旧スクリプトをそのまま使えると決めつけず、再確認してください。

prepend-rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - DOMAIN,api.example.net,PROXY

append-rules:
  - MATCH,PROXY

上の構成は、「特定のルールを前へ置き、最後のフォールバックを残す」という考え方を示すものです。実際のフィールド名はクライアントのオーバーライド機能に従ってください。標準Clash設定を直接編集する場合は、ルールをrulesリストへ記述し、最後のフォールバックが1つだけになるようにします。複数のMATCHがある場合、最初に現れるものだけが意味を持ちます。

サブスクリプション変換で解決できること

サブスクリプション変換は主に、ノード一覧をクライアントが読み込める設定へ整理したり、ルールやポリシーグループのテンプレートを適用したりするために使います。失効したノードを修復したり、接続品質を自動的に高めたりするものではありません。変換後はノード名、ポリシーグループ、ルールが変わる可能性があるため、更新前に旧設定を保存します。変換結果でノードが突然減った場合は、リンクが開くかだけでなく、テンプレートのフィルター条件、プロトコル対応、ノード名の正規表現を確認します。

読み込みが完了したら、まずRuleモードで明確なノードを1つ選び、システムプロキシを有効にしてログを確認します。基本接続が正常になってから、自動選択、複雑なルール、TUNを有効にします。検証手順を分けておけば、問題がサブスクリプション、ポリシー選択、取り込み方式のどこにあるか判断できます。

プロキシモード：Rule、Global、Directの選び方

Ruleモードは日常利用に適している

Ruleモードでは、設定内のルールを上から順に確認し、リクエストをどのポリシーグループへ送るか判断します。結果にはPROXY、DIRECT、REJECT、カスタムポリシーグループなどがあります。利点は「自動的に速くなる」ことではなく、用途に応じて通信の出口を選べることです。ローカルサービスは直接接続し、プロキシが必要なドメインはプロキシグループへ送り、広告や既知の不要なリクエストは拒否できます。ルールが適切なら、クライアント全体のスイッチを頻繁に切り替える必要がありません。

ルールは上から順に照合され、命中すると検索を停止します。そのため、具体的なルールを広範囲のルールより前へ置きます。たとえば単一ドメインのルールは、より広いドメインサフィックスやルールセットより前に置きます。LANや予約済みアドレスは、最後のプロキシフォールバックより前に処理するのが一般的です。最後にMATCHを置いてフォールバックとし、前のルールで識別されなかった接続にも明確な行き先を与えます。

Globalモードは一時的な検証に使う

Globalモードでは通常、取り込み可能なすべての通信をグローバルポリシーグループへ渡し、ユーザーがノードまたは出口を選びます。「問題の原因はルールか」を判断するのに適しています。Ruleモードでは開けないサイトがGlobalへ切り替えるとすぐ開く場合、ノードと取り込み経路はおそらく利用可能です。次にドメインルール、IPルール、DNSを確認すべきで、クライアントの再インストールを急ぐ必要はありません。

グローバルモードでも、端末上のすべてのパケットが自動的にプロキシへ入るわけではありません。取り込まれるかどうかは、システムプロキシまたはTUNに依存します。Globalへ切り替えただけで取り込み方式を有効にしていなければ、多くのアプリは直接接続します。逆にTUNを有効にしてもDirectモードを選んでいれば、通信はコアを通っても直接接続として処理されます。モードと取り込み方式は分けて考えてください。

Directモードは素早い迂回に使う

Directモードでは通信をできるだけ直接接続します。一時的にプロキシ判断を止めたり、直接接続とプロキシの違いを比較したり、クライアントを動かしたままローカルネットワークを確認したりする際に使えます。完全にクライアントを終了した状態と同じとは限りません。ローカルポートが待ち受けを続けたり、TUNが通信を取り込んだ後で直接接続したりする場合があります。元のネットワーク状態へ完全に戻すには、システムプロキシとTUNを無効にしてからクライアントを終了します。

クライアントによってはScriptなどの拡張モードもありますが、動作はスクリプトの実装に依存します。初心者の段階では、スクリプトモードを標準設定にするのはおすすめしません。スクリプトのエラー、実行環境、返り値が切り分けの層を増やすためです。ルールで明確に表現できる処理は、標準ルールを優先してください。

モードの後に実際の出口を決めるのはポリシーグループ

ルールは通常、特定のノードを直接固定せず、ポリシーグループを指定します。selectグループはユーザーが手動で選択し、url-testはテスト結果に応じて候補ノードを選び、fallbackは利用可能なノードを順番に試し、load-balanceはポリシーに従って複数ノードへ接続を分配します。グループごとに解決する問題は異なるため、名前に「自動」と入っているかだけで優劣を判断しないでください。

自動テストは指定したテストアドレスと間隔を使い、そのアドレスへの接続状況だけを反映します。テスト結果が良くても、すべてのサービスへ同じように接続できるとは限りません。ノードの出口位置、ルーティング、対象サイトの制限、接続の再利用が実際の使用感に影響します。日常利用では、手動選択グループと自動テストグループを1つずつ残すと便利です。自動グループを通常の閲覧に使い、特定サービスで問題が起きたら手動グループへ戻して確認します。

proxy-groups:
  - name: "手動選択"
    type: select
    proxies:
      - "ノード A"
      - "ノード B"
      - DIRECT

  - name: "自動選択"
    type: url-test
    proxies:
      - "ノード A"
      - "ノード B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

intervalはテスト間隔を秒単位で指定します。短すぎると余分なリクエストが発生します。toleranceはノード間の差が小さいときに頻繁な切り替えを避けるために使います。テストアドレスには、軽量なレスポンスを安定して返すものを指定します。現在のネットワークからテストアドレスへアクセスできない場合、自動グループがすべてのノードを異常と判定することがあります。その場合は環境に合った検出アドレスへ変更します。

モード切り替え時の確認方法

まず、利用可能と分かっているノードを1つ固定し、システムプロキシまたはTUNを有効にしてから、RuleとGlobalをそれぞれテストします。どちらも失敗する場合は、ローカルの待受、ノード接続、DNSを確認します。Globalは成功してRuleが失敗する場合は、ログで命中したルールとポリシーグループを確認します。ブラウザーは成功するのにコマンドラインだけ失敗する場合は、コマンドラインのプログラムがシステムプロキシを読み取るか確認し、必要なら明示的なプロキシオプションまたはTUNを使います。

現在のモードを判断する際、ホーム画面のボタンの色だけを見ないでください。ログに出る命中ルールと出口名のほうが信頼できます。完全な記録には、対象ドメインまたはIP、照合されたルール、ポリシーグループ、最終ノードを含めます。この4項目を押さえれば、「特定のアプリが接続できない」という問題を確認可能な手順へ分解でき、すべてのスイッチを何度も切り替える必要がなくなります。

ルール分岐とDNS：リクエストを正しい出口へ送る

ルールの種類と照合順序

ドメインルールは最も読みやすい種類です。DOMAINは完全一致のドメインだけを照合し、DOMAIN-SUFFIXは指定したサフィックスとサブドメインを照合し、DOMAIN-KEYWORDはドメイン内のキーワードで照合します。IPルールは対象アドレスで判断し、IP-CIDR、IP-CIDR6、地理データベースルールなどがあります。プロセスルールではプログラム名やパスで分岐できますが、対応状況と権限要件はOSによって異なります。ルールセットは大量のルールを独立したファイルへ分け、更新と再利用を容易にします。

ルールが広範囲であるほど、後ろへ置きます。たとえば先にDOMAIN-SUFFIX,example.com,PROXYを書き、その後にDOMAIN,internal.example.com,DIRECTを書くと、内部ドメインは先にサフィックスルールへ命中し、後の直接接続ルールは実行されません。具体的な例外を一般的なルールより前へ置くのが正しい方法です。最後はMATCHでフォールバックし、リクエストが不明確な状態へ落ちないようにします。

rules:
  - DOMAIN,internal.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,PROXY

no-resolveは、このIPルールを照合する際に、IPを得るための追加のドメイン名前解決を行わないことを示します。すでに対象IPを取得している接続や、IPルールが早い段階で名前解決を発生させるのを避けたい場合に適しています。ただし、すべてのIPルールへ機械的に追加するものではありません。ドメインの名前解決結果を判断に使うルールでは、名前解決を許可する必要があります。

ルールセット、GeoIP、GeoSite

ルールセットは、ドメイン、IP、クラシックルールを独立したリソースにまとめ、メイン設定からRULE-SETで参照します。ルールを個別に更新できるため、サブスクリプション全体を毎回置き換える必要がありません。利用時は、ルールセットの動作タイプと内容が一致しているか確認します。domainタイプはドメイン系の動作のみ、ipcidrタイプはネットワーク範囲、classicalタイプは完全なルール行を扱えます。タイプを間違えると読み込みに失敗したり、ルールが命中しなかったりします。

GeoIPはIPの地理データベースで分類し、GeoSiteはドメインの集合で分類します。どちらもローカルデータベースに依存するため、長期間更新しないと新しいドメインが欠落したり、アドレスの分類がずれたりします。設定は正常に解析できるのに分岐の精度が徐々に落ちた場合は、データベースの更新日時と取得元を確認します。具体的な更新方法はGeoIPとGeoSiteデータベースの更新ガイドを参照してください。

DNSがルールに影響する理由

アプリがドメインへアクセスすると、アプリ自身が先に名前解決してから、IP接続をプロキシへ送る場合があります。反対に、ドメインをそのままプロキシへ渡す場合もあります。前者ではコアにIPしか見えず、ドメインルールが適用しにくくなります。後者ではコアがドメイン情報を保持し、ドメインルールで分岐できます。システムプロキシ、SOCKS、TUN、ブラウザーのセキュアDNS、アプリ内蔵の名前解決方式によって、この経路は変わります。

DNS設定には通常、待受、IPv6、拡張モード、デフォルトリゾルバー、主要nameserverが含まれます。デフォルトリゾルバーは他のDNSサーバー自身のドメインを解決するため、現在のネットワークから直接アクセスできるアドレスを選びます。「DNSへプロキシ経由でアクセスする必要があるのに、プロキシノードのドメインを先に解決しなければならない」という循環を避けるためです。主要nameserverは通常の問い合わせを担当し、ネットワーク環境に応じてUDP、TCP、DoH、DoTに対応するサービスを選びます。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"

この設定例はフィールドの関係を示すもので、すべてのネットワーク環境へそのまま適用するものではありません。0.0.0.0で待ち受けると、本機のすべてのインターフェースからポートへアクセスできる可能性があります。信頼できないネットワークに接続する端末では、ファイアウォールを併用するか、ローカル待受へ変更してください。IPv6を無効にするとClash DNSはIPv6の結果を返さなくなりますが、OSや他のアプリがIPv6リクエストを送るかどうかは、取り込み方式とシステムネットワークにも左右されます。

Fake-IPとRedir-Hostの違い

Fake-IPモードでは、まずアプリへ予約済みアドレスを返し、コアがそのアドレスと元のドメインの対応関係を管理します。アプリが予約済みアドレスへ接続すると、コアは元のドメインを把握しているため、早い段階でドメインルールを判断でき、重複した名前解決を減らせる場合があります。予約済みアドレスは対象サイトの実アドレスではなく、本機内のマッピング処理だけで使われます。詳しい仕組みとフィルター方法はClash Fake-IPモード解説を参照してください。

一部のLAN検出、プリンター、ゲーム、時刻同期、実IPの返却値に依存するアプリはFake-IPに適さないため、fake-ip-filterへ追加できます。フィルター項目を最初から広範囲のドメインで大量に追加すると、Fake-IPのドメインマッピングの利点が弱まります。特定のアプリだけに問題がある場合は、まずログでドメインを確認し、最小限の範囲でフィルターを追加して再テストします。

Redir-Hostは、実アドレスを先に解決してから接続を処理する方式に近く、実際のDNS結果に依存するプログラムと互換性がある一方、DNS経路の品質に左右されやすくなります。どちらのモードが絶対に優れているわけではありません。デスクトップの日常利用ではクライアントの初期値を維持し、LAN機器の検出失敗、特定アプリのログイン異常、ドメインルールの欠落が起きた場合に、ログを見て調整を判断します。

ルールが命中しないときの確認方法

最初に、接続ログでドメインとIPのどちらが表示されているか確認します。IPしかない場合、ドメインルールが命中しないのは自然です。アプリの名前解決方式、TUNのスニッフィング、DNSの取り込みを確認してください。次に、対象ルールがより広範囲のルールより前にあるか確認します。続いて、ルールが指すポリシーグループ名が大文字・小文字、空白、記号を含めて完全に一致しているか確認します。さらに、ルールセットが正常にダウンロードされ、動作タイプが一致しているか確認します。データベースとキャッシュを調べるのは最後です。

変更後は設定を再読み込みし、新しい接続を作ってテストします。既存の接続は古い出口を再利用する可能性があり、ウェブページを更新しても新しい接続が作られるとは限りません。対象アプリを終了したり、接続記録を消去したり、接続が終了するまで待ってから再試行します。ルール順、DNSモード、TUNパラメータを同時に変更すると、復旧してもどの変更が効いたのか分からなくなります。

TUNモード：システムプロキシを読まない通信を取り込む

TUNが必要になる場面

システムプロキシは、OSのプロキシ設定を自ら読み取るプログラムにだけ有効です。ブラウザーは通常よく対応していますが、コマンドラインツール、ゲームランチャー、一部のデスクトップアプリ、コンテナ、独自のネットワークスタックを使うソフトウェアは無視することがあります。TUNモードは仮想ネットワークインターフェースを作り、システムルートを通じてより広い範囲のIP通信をコアへ送るため、システムプロキシの対象外となるアプリに適しています。

TUNは「高度だから必ず有効にする」スイッチではありません。ブラウザーやシステムプロキシに従うアプリだけを使うなら、システムプロキシのほうが構成が簡単で、切り分けもしやすくなります。取り込まれていないプログラムに明確に遭遇した場合や、UDP、コマンドライン、複数アプリを一括で処理したい場合にTUNを有効にします。仮想ネットワークインターフェース、ルート、DNSハイジャック、権限などの要素が増えるため、設定を誤ると他のVPN、仮想マシンのネットワーク、セキュリティソフトと競合しやすくなります。

主要パラメータの読み方

enableはTUNの有効・無効を制御します。stackはユーザー空間とシステムネットワークスタックの間でパケットを処理する方法を決め、一般的な値にはsystem、gVisor、mixedがあります。対応状況は現在のコアとクライアントに従ってください。auto-routeはルートを自動的に書き込み、auto-detect-interfaceはデフォルトの出口インターフェースを識別し、dns-hijackは指定したDNSリクエストをClashへ渡します。GUIクライアントのスイッチは通常、これらのフィールドを生成または上書きします。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
  strict-route: false

mixedは通常、異なる通信処理経路を両立するために使いますが、すべての端末で選ぶ必要があるわけではありません。クライアントにstackの選択肢がある場合は、まず初期値を使います。strict-routeはルート漏れをより厳格に制限しますが、一部のOSではLAN、テザリング、仮想ネットワークに影響することがあります。初回有効化では無効のままにすると確認しやすく、基本通信が正常になってから必要に応じてテストできます。

デスクトップOSで有効にする手順

まず他のVPNと旧クライアントのTUNを無効にし、現在のクライアントだけを動かします。システムプロキシモードで利用できることを確認した設定を読み込み、使用可能なノードを1つ固定してからTUNを有効にします。システムが管理者権限を求めたら許可し、その後、コアの実行、仮想ネットワークインターフェースの作成、ルートの書き込みが成功したかをクライアント画面で確認します。この時点でシステムプロキシを一時的に無効にし、従来システムプロキシを読まないコマンドラインツールでテストすると、通信が本当にTUN経由か確認できます。

Windowsで有効化後に完全に通信できなくなった場合は、まずTUNを無効にし、残った仮想ネットワークインターフェース、サードパーティVPN、Hyper-V、セキュリティソフトのネットワークフィルターを確認します。再度有効にする前に、クライアントを再起動して自動ルートを初期状態へ戻す方法もあります。macOSではネットワーク拡張またはVPN構成の許可を確認します。権限が拒否されるとスイッチがすぐ無効へ戻ることがあります。LinuxではTUNデバイスの作成とルート変更の権限が必要で、サービスプロセスにも設定の読み取りと実行ディレクトリへの書き込み権限が必要です。

curl https://example.com/
curl --noproxy "*" https://example.com/

TUNが正しく通信を取り込んでいる場合、2つ目のコマンドでcurlに従来のプロキシ環境変数を使わせなくても、通信はシステムルートからTUNへ入る可能性があります。このテストは「プログラムがHTTPプロキシを読み取った」のか「通信が仮想ネットワークインターフェースに取り込まれた」のかを区別するのに役立ちます。テスト中はClashのログに対応する接続が出ているかも確認し、ウェブページの結果だけで判断しないでください。

DNSハイジャックとFake-IPの組み合わせ

TUNでIP通信を取り込んでも、DNSをアプリがLANのリゾルバーへ直接送っていると、コアには名前解決後のIPしか見えず、ドメインルールとFake-IPのマッピングに影響します。dns-hijackは、一般的なDNSリクエストをClash DNSへ送るために使います。最新のブラウザーや一部のアプリは暗号化DNSを使うため、通常の53番ポートのハイジャックでは直接読み取れません。アプリ側で独自のセキュアDNSを無効にするか、その通信自体がルールで正しく処理されるようにします。

DNSハイジャックを有効にした後、LAN内のドメインを解決できなくなった場合は、そのドメインをルーターのDNSで処理する必要があるか確認し、nameserver-policyまたは適切なフォールバック経路を設定します。プリンター、NAS、社内ドメインは特定ネットワークのDNSにしか存在しないことが多く、公共DNSでは回答できません。すべてのDNSを直接接続へ戻すのではなく、対象ドメインを正しいローカルリゾルバーへ渡すのが解決方法です。

LAN、仮想マシン、コンテナの境界

TUNでルートを書き換えると、LANへのアクセスもコアを通る場合があります。設定にはプライベートネットワークを直接接続するルールを残し、IPv6のローカルアドレスにも注意します。他の端末から本機のプロキシを使わせる場合は、allow-lanを個別に有効にし、適切なインターフェースで待ち受け、ファイアウォールを設定します。これは本機のTUNとは別の話です。本機の通信を取り込むためだけに、プロキシポートをすべてのネットワークへ公開しないでください。

仮想マシンとコンテナには、それぞれ固有の仮想ネットワークインターフェースとネットワークセグメントがあります。TUNの自動ルートが、Docker、仮想マシンのブリッジ、WSL、企業VPNのルートを上書きすることがあります。問題が仮想環境だけで起きる場合は、TUNの有効・無効でルーティングテーブルを比較し、対象ネットワークをどのインターフェースが処理しているか確認します。必要なら仮想ネットワークを除外ルートまたは直接接続ルールへ追加し、すべてのルールを無効にする方法は避けます。

TUN失敗時の固定された確認順序

まず、同じノードがシステムプロキシで利用できることを確認し、ノードの問題を除外します。次に、TUNスイッチが実際に有効なままで、仮想ネットワークインターフェースが作成されているか確認します。その後、自動ルートとデフォルトインターフェースの識別を確認し、DNSが取り込まれているか、ログにリクエストが出ているかを調べます。最後に、他のVPN、セキュリティソフト、仮想ネットワークインターフェース、ファイアウォールを確認します。各段階では変数を1つだけ変更し、変更後に新しい接続を作ってください。

システムプロキシは正常でTUNだけが正常でない場合、サブスクリプションを再読み込みする必要は通常ありません。権限、ルート、DNS、ネットワーク競合を重点的に確認します。仕組み、stackの選び方、プラットフォームごとの差異は、Clash TUNモード有効化ガイドで詳しく解説しています。

日常メンテナンスと上級設定への道筋：復元できる設定を保つ

安定した日常確認のリズムを作る

Clashが正常に動作しているときは、頻繁に設定を変更する必要はありません。日常的には、サブスクリプションを更新できるか、よく使うポリシーグループに利用可能なノードがあるか、ルールと地理データベースが古くなっていないか、クライアント更新後も主要設定が維持されているかを確認します。サブスクリプションは毎日、またはサービス提供者の推奨頻度で更新し、ルールセットとデータベースは実際の更新周期に合わせます。自動テストやサブスクリプション更新を過度に頻繁に行うと、リクエストが増え、ノード選択も落ち着かなくなります。

クライアント起動後に設定が初期値へ戻っていた場合は、設定を切り替えていないか、ポータブルディレクトリを使っていないか、設定ディレクトリへ書き込めるかを確認します。システム更新後にTUNの権限が失われた場合は、ネットワーク拡張または仮想ネットワークインターフェースの許可を再確認します。スリープ復帰後の短い切断なら、まずネットワークインターフェースの復旧を待ってからコアへ再接続します。毎回自動復旧しない場合は、デフォルトインターフェースの識別とクライアントのバックグラウンド動作を確認します。

何をバックアップすると役立つか

優先してバックアップするのは、サブスクリプションアドレス一覧、カスタムルール、オーバーライドスクリプト、DNSの調整、独立したローカル設定です。キャッシュデータベース、一時的な接続記録、通常の実行ログは長期保存する必要がないことが多くあります。バックアップにはサブスクリプションのパラメータ、ノード認証情報、LANアドレスが含まれる可能性があるため、管理された場所に保存し、公開コードリポジトリへ直接アップロードしないでください。

複数の端末で同期する場合、サブスクリプションリンクを一元配布する方法が最も管理しやすい一方、端末固有の設定を無理に共用してはいけません。たとえばデスクトップのTUN stack、Androidのアプリ単位プロキシ、macOSのネットワーク拡張はプラットフォームごとに異なります。ノードと基本ルールは共有し、システム固有のフィールドはローカルのオーバーライド層に残す方法が適しています。サブスクリプション、WebDAV、手動エクスポートの使い分けは、Clashの複数端末設定同期方法を比較してください。

ログの読み方

ログレベルには通常、silent、error、warning、info、debugがあります。日常利用ではinfoで十分です。短時間の問題を調べるときだけdebugへ切り替え、再現後はすぐ戻してログの急増を防ぎます。読むときは、まず障害が起きた正確な時刻を特定し、対象ドメインまたはIP、命中ルール、ポリシーグループ、最終出口、エラー種別を確認します。大量のログからランダムに1件のエラーを選び、結論を出さないでください。

接続タイムアウトは通常、リクエストが送信されたものの時間内に完了しなかったことを示します。ノード、ルート、対象サービス、ネットワーク制限が原因になる可能性があります。接続拒否は対象アドレスが明確に拒否したことを示します。DNSエラーは名前解決段階の失敗です。TLSエラーはシステム時刻、証明書チェーン、ドメイン不一致、中間ネットワークが関係することがあります。設定解析エラーなら、YAMLの行番号とフィールドへ戻って確認します。エラーが発生した層によって、次に調べる場所が決まります。

一般的な障害ツリー：範囲の小さいところから確認する

すべてのサイトに接続できない場合は、まずクライアントのコア、ローカルポート、取り込み方式、ノードを確認します。1つのサイトだけ接続できない場合は、命中ルール、DNS、ノードの出口、サイト側の制限を確認します。1つのアプリだけ接続できない場合は、システムプロキシを読むか、独自DNSやQUICを使っているかを確認します。TUNだけが接続できない場合は、権限、ルート、競合を確認します。サブスクリプション更新だけが失敗する場合は、プロキシルールを変更せず、リンクのレスポンスと形式を直接確認します。

システムプロキシを無効にしても直接接続へ戻れない場合は、OSのプロキシ設定が残っていないか、環境変数が残っていないか、ブラウザーに独自プロキシが設定されていないか確認します。TUNを無効にしても異常が続く場合は、仮想ネットワークインターフェースとルートが削除されたか確認し、必要なら通常の手順でOSを再起動してネットワークスタックを再構築します。出所不明の「ワンクリックネットワーク修復」スクリプトは使わないでください。DNS、ファイアウォール、ネットワークインターフェースを同時にリセットし、調査に必要な情報を消してしまう可能性があります。

# macOSとLinuxで一般的なプロキシ環境変数を確認
env | grep -i proxy

# 現在のターミナルセッションからプロキシ変数を一時的に削除
unset HTTP_PROXY HTTPS_PROXY ALL_PROXY
unset http_proxy https_proxy all_proxy

# ローカルプロキシポートをテスト
curl -x http://127.0.0.1:7890 https://example.com/

環境変数は、それを読み取るプログラムと現在のセッションにだけ影響します。GUIクライアントがシステムプロキシを変更しても、ターミナルで手動設定した変数が自動的に消えるわけではありません。反対に、ターミナルでHTTPS_PROXYを設定しても、他のデスクトップアプリがそれを使うとは限りません。各アプリがどの方式で通信を取り込むのかを把握することが、安定運用の重要な習慣です。

クライアントの更新と設定の移行

更新前にクライアントのリリースノートを確認し、設定ディレクトリ、コアのフィールド、ネットワーク拡張に変更がないか確認します。まず重要な設定をエクスポートし、旧バージョンを正常に終了してから新バージョンをインストールします。更新後は、設定が読み込まれるか、サブスクリプションを更新できるか、システムプロキシとTUNの権限が維持されているかを確認してから、複雑なオーバーライドを戻します。更新と同じ日にサブスクリプション、ルールテンプレート、DNS設定まで変更しないでください。複数の変更が重なると原因を追跡しにくくなります。

メンテナンス終了済みのClash for WindowsまたはClashX Metaから移行する場合は、データベース全体をコピーせず、リモートサブスクリプションを読み込み直すのがおすすめです。手書きのルールは個別に移行し、ポリシーグループの選択は改めて確認します。新しいクライアントがmihomoコアを採用している場合、拡張フィールドが増えていることがありますが、旧フィールドの互換性は設定テストとログで確認してください。

日常利用から上級設定へ進む

基本接続が完了したら、依存関係に沿って学習を進めます。第1段階は接続ログとルール順を読み、リクエストがなぜ特定の出口へ向かったか説明できるようにします。第2段階はポリシーグループを理解し、手動選択、自動テスト、障害時のフォールバックを使い分けます。第3段階はDNS、Fake-IP、ルールセットを理解し、ドメイン識別と分岐の精度を高めます。第4段階でTUN、プロセスルール、LAN共有、マルチデバイス同期へ進みます。

サーバーやルーターでは、サービス管理、設定ディレクトリの権限、ログローテーション、待受アドレス、ファイアウォールも学ぶ必要があります。制御インターフェースやプロキシポートを直接公開するとアクセス範囲が広がるため、制御ポートは信頼できるインターフェースに制限し、適切な認証を設定します。設定のLANアクセス機能は本当に必要な場合だけ有効にし、OSのファイアウォールで接続元を制限してください。

Clashを本当に理解しているかは、設定ファイルの長さではなく、4つの質問に答えられるかで判断できます。通信はどのようにコアへ入るのか、このリクエストはどのルールに命中したのか、そのルールはどのポリシーグループを指すのか、ポリシーグループは最終的にどの出口を選んだのか。この経路に沿って切り分けられれば、クライアントやプラットフォームを変えたり設定を調整したりしても、最初から手探りする必要はありません。

このマニュアルの次に読む順番

まだ初回接続が完了していない場合は、使い方ガイドへ戻って手順に従います。クライアントを変更したりシステムアーキテクチャを確認したりする場合は、ダウンロードセンターへ進みます。略語やフィールド名で迷ったら、用語マニュアルを開いてください。サブスクリプション解析、TUN、Fake-IP、データベース更新、マルチデバイス同期にはそれぞれ独立した技術ノートがあります。現在の問題に合わせて読み進めればよく、高度な設定を一度にすべて読む必要はありません。

安定した設定の原則はシンプルです。まず接続を通し、その後で分岐する。まずログを確認し、その後でパラメータを変更する。一度に変更する変数は1つだけにする。変更前に復元可能な版を保存する。この順番なら、Clashの設定項目が多くても、各問題を明確な工程へ落とし込めます。複雑に絡み合ったケーブルのような状態にはなりません。