Clash 全プラットフォーム導入設定完全ガイド

第1章 · 始める前に：共通の準備作業

どのプラットフォームを使う場合でも、共通してやるべきことは3つあります。サブスクリプションURLの取得、ポートの基礎知識、適切なクライアント選び。この3つを先に済ませておけば、以降の各章がぐっと進めやすくなります。基本方針は同じです：まず手順を示し、理由はその流れの中で補足します。

1.1 サブスクリプションURLを準備する

サブスクリプションURL（サブスクリプションリンクとも呼ばれます）は https:// から始まるアドレスで、クライアントが定期的にアクセスしてノード一覧と振り分けルールを取得します。契約しているサービス提供元のダッシュボードにある「サブスクリプション」ページなどでコピーできます。Clash、Surge、Shadowrocket など複数形式が並んでいる場合は、Clash または mihomo 用のものを選んでください。

手順は2つだけです。サービス提供元のダッシュボードでサブスクリプションリンクをコピーし、クライアントのサブスクリプション入力欄に貼り付けます（各OSでの入力欄の位置は後述の各章で説明します）。サブスクリプションリンクには通常 token パラメータが含まれており、このリンクを持つ人は誰でもそのプランを利用できてしまうため、実質的にはIDとパスワードに相当する情報です。

1.2 よく使うポートを知る

Clash がトラフィックを引き受ける方法は、ローカルの 127.0.0.1 上にいくつかのポートを開き、OSやアプリからそこへ流量を送ってもらい、コア（内核）がルールに従って転送する、という仕組みです。そのため「ポート」はインストール後に最初に理解しておくべき概念です。よく使われる既定ポートは以下の通りです（クライアントごとに既定値は異なるため、実際の設定画面の表示を確認してください）。

インストール後に最初にやることは、クライアントの設定画面を開き「ポート / Port」の項目で実際のポート番号を確認することです。特定アプリに手動でプロキシを設定する場合も、「ポートが使用中」の問題を調べる場合も、この番号を使います。いわゆる「システムプロキシ」のスイッチは、要するにOSのプロキシサーバー設定を 127.0.0.1 とこのポート番号に書き換えているだけです。

1.3 適切なクライアントを選ぶ

5つのプラットフォームのクライアント一覧はダウンロードページと完全に一致しています。全OS共通で Clash Plus を第一候補として推奨し、各OSごとに代替候補もあります。開発が終了した旧クライアントはアーカイブとして掲載しているのみです。どれを選ぶか迷ったら、まずクライアント比較ページの結論を確認し、決まったらダウンロードページでOS別に入手してください。対応する入口は以下の通りです。

第2章 · Windows での導入設定

2.1 ダウンロードとインストール

手順：ダウンロードページの Windows セクションを開き、一番上のカードにある第一候補 Clash Plus の「インストーラをダウンロード」をクリックして .exe インストーラを取得します。対応OSは Windows 10 以降、64bit環境です。ダブルクリックで実行し、ウィザードの指示に従って進めるだけで、インストール先は既定のままで問題ありません。

初回起動時、Windows セキュリティが「このアプリのネットワークアクセスを許可しますか」と確認してくる場合があります。プライベートネットワークとパブリックネットワークの両方にチェックを入れて許可してください。クライアントはサブスクリプションの取得のためにネット接続が必要で、ローカルでポートを開く必要もあるため、ブロックするとどちらも機能しません。

2.2 サブスクリプションの導入

1. サブスクリプション管理を開くClash Plus はメイン画面左側の「サブスクリプション」から。Clash Verge Rev も同じく「サブスクリプション」ページに入り「新規追加」をクリックします。
2. サブスクリプションリンクを貼り付ける名前欄には識別しやすい名前（サービス提供元の名前など）を入力し、URL欄に第1章でコピーしたサブスクリプションリンクを貼り付けて保存します。
3. サブスクリプションを更新するサブスクリプションカードの更新ボタンをクリックすると、クライアントがノードとルールを取得します。一覧にノードが表示されれば成功です。ついでに自動更新間隔を24時間に設定しておきましょう。
4. ノードを選んで遅延を測定する「プロキシ」ページで、ポリシーグループ内のノードを1つ選び、雷アイコンをクリックして遅延テストを行います。遅延が低く、何度測定しても安定しているノードを優先しましょう。「自動選択」ポリシーグループは遅延に応じて自動で選んでくれるので、初心者はそのまま使うのがおすすめです。

2.3 システムプロキシを有効にする

手順：メイン画面の「システムプロキシ」スイッチを見つけてオンにするだけで、3番目のステップはありません。理由：スイッチをオンにすると、クライアントは Windows のプロキシ設定（設定 → ネットワークとインターネット → プロキシ）を 127.0.0.1:7897 のようなローカルアドレスに書き換えます。これにより、Edge、Chrome、多くのオフィスソフトなどシステムプロキシに従うすべてのアプリの通信が自動的に Clash 経由で転送されます。

確認方法：ブラウザで自分のグローバルIPを表示するサイトを開き、表示されるアドレスがノードの所在地に変わっていれば、通信経路は正常に確立されています。遅延測定や「見かけ上だけ通っている状態」の見分け方など、より詳しい確認手順はブログの初回接続確認ガイドをご覧ください。

2.4 TUN モード（仮想ネットワークアダプタ）

システムプロキシには死角があります。システムプロキシの設定を無視するアプリ（一部のゲーム、コマンドラインツール、UWPアプリ）は引き受けられません。TUN モードは仮想ネットワークアダプタを作成し、ネットワーク層でマシン全体の通信を Clash に取り込む方式で、アプリ側の対応状況に関係なく機能します。

手順：設定内で「TUN モード / 仮想ネットワークアダプタ」をオンにします。初回はネットワークアダプタ用ドライバのインストールと、クライアントを管理者権限で実行することが求められるので、表示に従って許可してください。以後はマシン全体の通信が Clash 経由になります。

2.5 Windows 特有の注意点

• UWP アプリが接続できない。Windows ストアアプリ（UWP）は既定で 127.0.0.1 へのアクセスが禁止されており、システムプロキシは効きません。クライアントには通常「UWP ループバック解除」ツールが付属しているので、対象アプリにチェックを入れて制限を解除してください。あるいは TUN モードをオンにして丸ごと回避することもできます。
• ポートが使用中。起動時に「ポートが使用中」または bind エラーが出た場合、そのポートを他のプログラムが使っています。以下の2つのコマンドで占有プロセスを特定できます。

netstat -ano | findstr :7897
tasklist | findstr "PID番号"

占有しているプロセスを終了させるか、設定でポートを空いている値（例：7899）に変更してください。システムプロキシは新しいポートに追従します。より詳しい調査手順は第8章をご覧ください。

• 起動時に自動起動しない。設定で「起動時に自動起動」にチェックを入れ、必要なら「サイレント起動 / 最小化してトレイに常駐」もオンにすると、起動後すぐにプロキシが使える状態になり、毎回手動で立ち上げる必要がなくなります。

第3章 · macOS での導入設定

3.1 ダウンロードとインストール

ダウンロードページの macOS セクションへ。第一候補は Clash Plus、代替候補は Clash Verge Rev、FlClash です。ClashX Meta は開発が終了しており、アーカイブとしての参考掲載のみなので、新しいマシンへの導入は推奨しません。ダウンロード前にチップの種類を確認してください：左上のAppleメニュー →「このMacについて」で、チップが Apple M シリーズなら arm64 版、Intel なら x64 版を選びます。選択を間違えると起動できません。

インストール：ダウンロードした .dmg をダブルクリックしてマウントし、アプリを「アプリケーション」フォルダにドラッグします。初回起動時に「開発元が未確認のため開けません」と表示された場合は、システム設定 → プライバシーとセキュリティ で対応する項目を探し「このまま開く」をクリックしてください。これは App Store 経由でないアプリに対する macOS の標準的な確認であり、ソフト自体に問題があるわけではありません。

3.2 サブスクリプションの導入とシステムプロキシ

導入：クライアントを開いてサブスクリプション管理を探します（Verge系は「サブスクリプション」ページ、ClashX系はメニューバーアイコン →「設定（Config）」→「管理対象設定」→「管理」）。リモート設定を追加し、サブスクリプションリンクを貼り付けて更新します。ノードが表示されたら、プロキシページでノードを選び遅延を測定する流れは Windows と同じです。

システムプロキシを有効にする：「システムプロキシとして設定」にチェックを入れます。仕組みは Windows と同じで、クライアントが macOS の Webプロキシ（HTTP）と セキュリティ Webプロキシ（HTTPS）を 127.0.0.1 とポート番号に向けて書き換えます。書き込み結果は システム設定 → ネットワーク → 詳細 → プロキシ で確認できます。チェックを外すと、クライアントが自動的に設定を消去します。

3.3 拡張モードと TUN

macOS ではクライアントによって呼び方が異なります。ClashX 系は「拡張モード」、Verge 系は「TUN モード」と呼びますが、いずれも仮想ネットワークアダプタでマシン全体を引き受けるという点で本質は同じです。初回オン時にはヘルパーツールのインストールとログインパスワードの入力による許可が求められ、以後の動作は Windows の TUN と同様です。普段はシステムプロキシだけで十分で、プロキシに従わないアプリに遭遇したときだけオンにしましょう。

3.4 macOS 特有の注意点

• パスワード入力の確認が多い。ヘルパーのインストールやシステムプロキシの変更時には許可ダイアログが表示されますが、これは正常な流れなので、ログインパスワードを入力してください。
• メニューバーにアイコンが見つからない。ノッチ搭載モデルはメニューバーの表示領域が狭く、アイコンが押し出されて隠れることがあります。使っていない常駐アイコンを終了するか、メニューバー管理ツールで整理してください。
• スリープ復帰後にプロキシが異常になる。ごく稀にシステムプロキシの状態が失われることがあります。システムプロキシのスイッチを一度オフにしてから再度オンにするか、クライアントを再起動すれば復旧します。
• ターミナルはシステムプロキシを経由しない。macOS のシステムプロキシはGUIアプリのみが対象で、git、curl、brew などのコマンドラインツールは手動で指定する必要があります。一時的に有効にする場合：

export http_proxy=http://127.0.0.1:7897
export https_proxy=http://127.0.0.1:7897
export all_proxy=socks5://127.0.0.1:7891

~/.zshrc に書き込めば永続的に有効になります。ポート番号は自分のクライアントの設定画面に表示されている実際の値に置き換えてください。

第4章 · Android での導入設定

4.1 ダウンロードとインストール

ダウンロードページの Android セクションへ。第一候補は Clash Plus、代替候補は Clash Meta for Android、FlClash、Surfboard です。APKをダウンロードしてタップすると「不明なソースからのアプリのインストールが禁止されています」と表示される場合があります。案内に従って設定画面に進み、いま使っているブラウザまたはファイル管理アプリに対してその場限りの許可を与えてください。「すべての提供元を許可」のような全体設定はオンにしないでください。

アーキテクチャの選び方：最近のスマートフォンはほぼすべて arm64 なので、通常は arm64 版を選べば問題ありません。インストールできない、またはインストール後にすぐ落ちる古い端末では arm 版や universal 版を試してください。

4.2 サブスクリプションの導入と起動

手順：クライアントを開いて「設定」ページに進み、プラスボタンをタップして「URLから読み込み」を選択し、サブスクリプションリンクを貼り付けて保存し、その設定を選択状態にします。メイン画面に戻って起動ボタンをタップすると、OSが「接続のリクエスト」ダイアログを表示し、VPN接続の確立を許可するか聞いてきます。「OK」をタップしてください。

理由：Android では一般のアプリが直接システムプロキシを書き換えることを許可していないため、Clash は Android 上では統一して OS の VPNService インターフェースを利用します。OSがマシン全体の通信をクライアントに引き渡す仕組みで、デスクトップ版の TUN モードに相当します。起動に成功するとステータスバーに鍵アイコンが表示され、通知欄に常駐通知が出ます。プロキシを停止する場合は通知欄から「停止」をタップしてください。

4.3 アプリ単位のプロキシとバックグラウンド常駐対策

アプリ単位のプロキシ設定。「アクセス制御 / アプリ単位のプロキシ」で、どのアプリをプロキシ経由にし、どのアプリを直接接続にするかを選択できます。よく使う日本国内向けアプリを直接接続、それ以外をプロキシ経由にするのが一般的なやり方で、ノードの通信量を節約できるほか、銀行系アプリなどでの不正アクセス判定を減らせます。

バックグラウンド常駐対策。これはAndroid特有の作業です。多くの国産カスタムROMはバックグラウンドプロセスを積極的に終了させる傾向があり、プロキシプロセスが強制終了されると「画面ロック後しばらくすると通信が切れる」という症状になります。固定の3ステップとして、OSの設定でクライアントのバッテリー最適化をオフにする、自動起動管理でこのアプリの自動起動を許可する、マルチタスク画面でクライアントのカードにロック（固定）をかける、を行ってください。

プライベートDNS。OSの「プライベートDNS（Private DNS）」がオンになっていて、利用できないサーバーを指定している場合、プロキシ側のDNS解決と競合し、ノードは正常なのにWebページが開かないという症状が出ます。この設定を「オフ」または「自動」に変更してください。

第5章 · iOS での導入設定

5.1 App Store からのインストール

iOS では第一候補は Clash Plus で、App Store から直接インストールします。ダウンロードページの iOS セクションを開いてストアリンクから遷移するか、App Store で直接検索してください。クライアント公式サイトは clashplus.io で、更新履歴や利用に関する告知はこちらの公式サイトの情報が正となります。

補足として：iOSのプロキシクライアントはいずれもOSの「ネットワーク拡張機能」の形で動作し、インストール後の初回起動時にVPN設定の追加が求められます。これはこの種のアプリ全体に共通する仕組みであり、特定のアプリが追加の権限を要求しているわけではありません。

5.2 サブスクリプションの導入と接続

手順：Clash Plus を開き、設定 / サブスクリプションページでサブスクリプションを追加し、リンクを貼り付けて更新してノードを取得します。ホーム画面でポリシーグループ内のノードを選んでから、上部の接続スイッチをオンにします。初回接続時にOSが「VPN設定の追加」を表示するので「許可」をタップし、Face IDまたは画面ロックのパスコードで確認します。ステータスバーにVPNアイコンが表示されれば接続完了です。

「オンデマンド接続（On Demand）」もついでにオンにしておくのがおすすめです。Wi-Fiとモバイル通信の切り替えや画面ロック解除後に自動で再接続され、毎回手動でオン・オフする必要がなくなります。

5.3 iOS 特有の注意点

• VPN設定が競合して上書きされる。iOSでは同時に有効化できるVPN設定は1つだけです。複数のプロキシ系アプリを入れている場合、片方をオンにすると別のアプリの接続が切れます。接続できないときは、まず 設定 → 一般 → VPNとデバイス管理 で現在どちらが有効になっているか確認してください。
• ネットワーク切り替え時に一瞬通信が途切れる。Wi-Fiとモバイル通信を切り替える瞬間には接続が再構築されるため、これは正常な現象です。数秒待てば自動的に復旧するので、繰り返しオン・オフする必要はありません。
• バックグラウンド更新。OSの設定でクライアントの「バックグラウンドAppリフレッシュ」を許可しておくと、長時間接続がより安定します。

第6章 · Linux での導入設定

Linux での使い方は2つに分かれます。デスクトップ環境ではGUIクライアントを使い、サーバーやルーター機器では mihomo コアを直接動かします。この章は前半でデスクトップ環境、後半でサーバー環境について説明します。

6.1 デスクトップ用GUIクライアント

ダウンロードページの Linux セクションでは Clash Verge Rev（.deb と .rpm を提供）を推奨し、FlClash（.deb を提供）を代替候補としています。ディストリビューションに応じてパッケージを選んでください。Debian、Ubuntu およびその派生系は .deb、Fedora、openSUSE 系は .rpm を使います。

Debian系でのインストール（ファイル名は実際にダウンロードしたものに合わせてください）：

sudo dpkg -i clash-verge-rev_amd64.deb
sudo apt -f install

2行目の役割：dpkg 自体は依存関係の解決を行わないため、依存関係エラーが出た場合は apt で自動的に補完します。Fedora系：

sudo dnf install ./clash-verge-rev.x86_64.rpm

6.2 サブスクリプションの導入とシステムプロキシ

サブスクリプションの導入方法はデスクトップ版と同じです。サブスクリプションページでリンクを追加し、更新してノードを選び遅延を測定する、という流れなので、ここでは繰り返しません。

システムプロキシのスイッチは GNOME デスクトップでは 設定 → ネットワーク → ネットワークプロキシ に書き込まれますが、KDE、タイル型ウィンドウマネージャ、軽量デスクトップ環境では、この設定が反映されない場合があります。その場合の対処法は2つです。1つ目は、デスクトップ環境のネットワーク設定でHTTP、HTTPS、SOCKSプロキシに手動で 127.0.0.1 と対応するポートを入力する方法。2つ目は、シェルに環境変数を設定してコマンドラインツールに直接反映させる方法です。

export http_proxy=http://127.0.0.1:7897
export https_proxy=http://127.0.0.1:7897
export all_proxy=socks5://127.0.0.1:7891

~/.bashrc または ~/.zshrc に書き込めば永続的に有効になります。GUIアプリはシステムプロキシ経由、コマンドラインは環境変数経由という形で、両者は互いに干渉しません。

6.3 サーバー用途：mihomo コアを直接動かす

GUIのないサーバーやルーター機器では、コアを直接利用します。ダウンロードページの「コア」セクションからアーキテクチャに応じたパッケージを取得してください。x86サーバーは linux amd64、Raspberry Pi やARM機器は arm64 または armv7 を選びます。手順は4ステップです。

1. 実行ファイルを配置するダウンロードした圧縮ファイルを展開し、mihomo を /usr/local/bin/ に配置して、実行権限を付与します（chmod +x）。
2. 設定用ディレクトリを準備する/etc/mihomo を作成し、サブスクリプションの内容を config.yaml として保存します。

sudo mkdir -p /etc/mihomo
curl -L "https://example.com/sub?token=xxxx" -o /tmp/config.yaml
sudo mv /tmp/config.yaml /etc/mihomo/config.yaml

サンプルのリンクはダミー値なので、自分のサブスクリプションリンクに置き換えてください。サービス提供元から発行される Clash 用サブスクリプションは、そのまま完全な mihomo 設定として使えます。

1. 主要な設定項目を確認するconfig.yaml を開き、以下の項目が期待通りになっているか確認します。

mixed-port: 7897        # ローカルプロキシの入口
allow-lan: false        # LAN内の他デバイスからの接続を許可するか
mode: rule              # ルールモード
log-level: info
external-controller: 127.0.0.1:9090   # 管理用インターフェース。ローカルのみにバインド

1. systemd で管理する/etc/systemd/system/mihomo.service を新規作成します。

[Unit]
Description=mihomo proxy service
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
Restart=on-failure
LimitNOFILE=1048576

[Install]
WantedBy=multi-user.target

続けて有効化し、ログを追跡します。

sudo systemctl daemon-reload
sudo systemctl enable --now mihomo
journalctl -u mihomo -f

以後サブスクリプションを更新するには、手順2の curl を再実行してから systemctl restart mihomo を実行します。自動化したい場合は crontab に1日1回の実行を登録してください。

6.4 Linux 特有の注意点

• アーキテクチャの選択ミス。ARM機器で amd64 のバイナリを実行すると Exec format error になります。まず uname -m でアーキテクチャ（x86_64、aarch64、armv7l）を確認してからパッケージを選んでください。
• LAN共有は既定でオフ。allow-lan は既定で false です。同一ネットワーク内の他デバイスに共有する場合は true に変更し、ファイアウォールで該当ポートを開放してください。また、信頼できるネットワークでのみ行うようにしてください。
• 管理用インターフェースを外部に公開しない。external-controller は必ず 127.0.0.1 にバインドしてください。0.0.0.0 にバインドしたうえで secret を設定していないと、プロキシの制御権を丸ごと公開してしまうことになります。
• GeoIP / GeoSite データベース。コアの振り分け機能はこの2つのデータに依存しており、GUIクライアントは通常自動的に更新されます。手動更新やカスタムソースの指定方法はブログのGeoIP・GeoSite解説記事をご覧ください。

第7章 · システムプロキシ、TUN、ルールによる振り分け

これまでの章で「システムプロキシ」と「TUN」が何度も出てきました。この章では3つの通信引き受け方式をまとめて比較し、さらに Clash に入った通信がルールによってどのように振り分けられるかを説明します。仕組みを理解しておくと、トラブルシューティングの際にどこを見ればよいかが分かるようになります。

7.1 3つの通信引き受け方式の比較

選択の原則を一言で言えば：システムプロキシで済むならTUNは使わない、アプリ単位の指定で済むならグローバル設定はいじらない、ということです。引き受ける範囲が小さいほど、トラブル発生時に調べる範囲も小さくなります。これが、これまでの各章で常にシステムプロキシをTUNより先に説明してきた理由です。

7.2 ルールによる振り分けの判定順序

通信が Clash に入ると、設定ファイル内の rules リストを上から順に照合していきます。最初に一致したルールのポリシーに従い、それ以降のルールは確認されません。すべて一致しなかった場合は、最後の MATCH で兜底（フォールバック）処理されます。典型的な記述例：

rules:
  - GEOSITE,private,DIRECT      # プライベートアドレスは直接接続
  - GEOIP,CN,DIRECT             # 中国本土のIPは直接接続
  - GEOSITE,gfw,PROXY           # 通信規制の対象サイトはプロキシ経由
  - MATCH,PROXY                 # それ以外はすべてプロキシ経由

順序そのものが1つの戦略です。直接接続のルールを前に、プロキシ経由のルールを後ろに置き、MATCH は必ず最後に置きます。GEOSITE はドメインデータベースによる照合、GEOIP はIPの所在地による照合です。両データベースの更新方法はブログの専門記事をご覧ください。DIRECT は直接接続、PROXY は選択中のノードに転送、REJECT はそのまま遮断（広告ブロックルールなどで多用されます）を意味します。

クライアント画面上の「ルール / グローバル / 直接接続」の3モードは、これらのルール全体に対するオン・オフの切り替えです。ルールモードでは上記のリストに従って判定し、グローバルモードではルールを無視してすべて選択中のノードへ、直接接続モードではすべて DIRECT になります。3つの使い分けについては、プロキシモード入門記事に詳しい比較がありますので、ここでは詳述しません。

7.3 ポリシーグループ：ルールとノードの間にあるもう1つのスイッチ

ルールが一致した先は、多くの場合特定のノードそのものではなく「ポリシーグループ」です。ポリシーグループは複数のノードを1つのグループにまとめ、グループ内での選び方を決めます。select は手動選択で、クライアントのホーム画面で選んだノードがそのまま使われます。url-test は遅延を自動測定し、常に最速のノードを使います。fallback は順番に可用性チェックを行い、先頭のノードが落ちたら自動的に次のノードに切り替わります。サブスクリプションでよく見る「自動選択」「フェイルオーバー」は、それぞれ後者2つの日本語表記に相当します。

この仕組みを理解すると、多くの現象に説明がつきます。なぜクライアントのホーム画面でノードを選べるのか——それは select グループがユーザーの選択を待っているからです。なぜ何も操作していないのに経路が変わることがあるのか——それは url-test グループが測定結果に応じて自動的に切り替えたからです。「意図しないノードを通っている」といった問題を調べるときは、まずログでどのグループにルールが一致したかを確認し、次にホーム画面でそのグループが現在どのノードを選んでいるかを見れば、2ステップで特定できます。

第8章 · 設定に関するよくある質問

発生頻度の高い順に並べ、各項目は「現象 → 対処の順序」の形式で記載しています。より詳しいエラーの調べ方はブログのログエラー解析記事を、初心者からの頻出質問は初心者向けFAQ10選にまとめています。

8.1 サブスクリプションの更新に失敗する

現象：更新をクリックすると失敗、タイムアウト、または「解析できません」と表示される。対処順序：①サブスクリプションリンクをブラウザのアドレスバーに直接貼り付けて開いてみて、テキストがダウンロードできるか確認する（開けない場合はリンク自体が失効しているか、サービス提供元側の問題なのでダッシュボードでリセットする）。②モバイルのテザリングに切り替えて更新してみて、ローカルネットワークによるサブスクリプション用ドメインへの干渉を排除する。③システムの時刻を正しく合わせる（時刻のずれが大きいとhttps証明書の検証に失敗する）。④クライアント設定で「プロキシ経由でサブスクリプション更新 / 直接接続で更新」を切り替えて再試行する。⑤いずれも解決しない場合は、クライアントのログを開いてエラー行を確認し、ログ解析記事の方法で原因を特定する。

8.2 ポートが使用中

現象：起動時に「ポートが使用中」またはbind系のエラーが表示される。Windows は第2章の netstat で調べます。macOS と Linux は以下を使用します。

lsof -i :7897

占有プロセスを見つけたら、そのプロセスを終了するか、クライアントの設定でポートを空いている値（7899、17890 など）に変更してください。ポート変更後は、システムプロキシのスイッチを一度オフにしてから再度オンにし、システム設定が新しいポートを指すようにしてください。

8.3 システムプロキシはオンだが、ブラウザがプロキシ経由にならない

まずブラウザのプロキシ切り替え系拡張機能を確認してください。この種の拡張機能はシステム設定を上書きするため、有効になっているとそちらが優先されます。次にブラウザ自体のプロキシ設定を確認します。Firefox は既定で「システムプロキシ設定を使用」になっており、「手動設定」に変更されていると独立して動作します。コマンドラインツールはもともとシステムプロキシの管理対象外なので、macOS、Linux の章で説明した環境変数の方法で個別に設定してください。

8.4 起動時に自動起動しない

クライアント設定で「起動時に自動起動」にチェックを入れたあと、Windows では タスクマネージャー → スタートアップ でその項目が「有効」になっているか確認してください。macOS では システム設定 → 一般 → ログイン項目 を確認します。チェックしても自動起動しない場合は、セキュリティ系ソフトが自動起動項目をブロックしていることが多いので、クライアントをホワイトリストに追加してください。

8.5 LAN内の他デバイスとプロキシを共有する

手順：クライアント設定で「LAN接続を許可（allow-lan）」をオンにし、このマシンのLAN内IPを確認します（Windowsは ipconfig、macOSとLinuxは ip addr を使用）。他のデバイスのプロキシ設定にこのマシンのIPとポートを入力します。注意点は2つです。ファイアウォールで該当ポートを開放すること、そして家庭内などの信頼できるネットワークでのみ有効化すること。公共Wi-Fiで開放すると、同じネットワーク上の全員にプロキシを開放してしまうことになります。

8.6 設定ファイルを誤って編集し、クライアントが起動しなくなった

設定ファイルを手動編集した後にクライアントが起動しない、または画面が空白になる場合、9割は YAML の構文エラーです。インデントには必ずスペースを使い、タブは使えません。また、コロンの後には半角スペースが1つ必要です。対処法：クライアント付属の「初期設定に戻す」機能を使うか、サブスクリプションを再導入して上書きしてください。自分で加えた変更を残したい場合は、エラー表示に出ている行番号を見ながら1行ずつ修正してください。設定を変更する前にバックアップを取っておくのが、最も手間のかからない保険です。

8.7 ログはどこで確認できるか

各クライアントには「ログ」ページがあり、info、warning、error の各レベルで絞り込めます。トラブルシューティングの基本動作は、問題を再現する → すぐにログの末尾数行を確認する → エラーのキーワードをログエラー解析記事の対照表と照らし合わせる、という流れです。設定の構文エラー、サブスクリプションの解析失敗、ポートの競合の3種類が、初心者のエラー報告の大半を占めています。

8.8 ノードは正常だが、特定のサイトだけ開けない

現象：大半のサイトは問題なく開けるが、一部のサイトだけずっと読み込み中のまま。これは多くの場合ノード自体の不具合ではなく、そのドメインの通信が正しい経路を通っていないことが原因です。対処順序：①クライアントのログを開いてから該当サイトに再度アクセスし、そのドメインがどのルールに一致し、どのポリシーに振り分けられたかを確認する（DIRECTで直接接続になっている場合は、ルールデータベースに未収録ということなので、そのドメインをプロキシ経由にするルールを手動で1つ追加する）。②グローバルモードに切り替えて再度試す（それで開ければ振り分けの問題だと確定するので①の方法でルールを補う。グローバルモードでも開かない場合はノードを変えて再テストする）。③一部のサイトはIPの所在地に敏感なので、別の地域に配置されたノードに変更すると、すぐに復旧することが多い。

本ページで扱っていない用語（サブスクリプション、ノード、ポリシーグループ、混合ポートなど）は用語集で確認してください。全体の流れを最短で把握したい初心者の方は、使い方ガイドに戻って3ステップの本線を一通り試したうえで、改めて各プラットフォームの章を参照することをおすすめします。