症状とログ上の表記:ノード障害とどう違うか
起動直後に止まる、トレイアイコンがすぐ消える、ダッシュボードに「listen」「bind」とポート番号が出る——といった挙動は、多くの場合 ローカル待受 の問題です。リモートのノードが遅い・TLS で落ちるといった 接続ログ上の timeout/TLS と層が異なります。起動さえ通れば以降の通信失敗を疑う前に、まず「指定番号のソケットを開けたか」に視点を戻すと切り分けが早いです。GUI クライアントの種類によってはエラー行が要約表示になるため、内蔵ログビューがあれば フルの一行を確認し、7890 や 7891 など、衝突した 数字をメモしてください。導入形態が多い端末では、クライアントの選び方で「作業ディレクトリに生成される config.yaml の場所」も押さえておくと、同じ衝突を再び踏みにくくなります。
典型原因は、前回の Clash コア(または同梱 helper)がゾンビ化してまだ同じ口を掴んでいる、別のプロキシ/VPN/開発サーバ(ローカルで立てた 8080 等)が先に LISTEN している、二重起動、といった「ローカル 1 台の中での取り合い」です。購読 URL まわりの 404/403 類は、口が開いていてから出る層の話なので、購読更新失敗の手順と混同しないよう、時間順に整理してください。
まず衝突しているポート番号を特定する
設定上は mixed-port: 7890 の一行で済むことが多い一方、GUI が「システムプロキシをこの番号に合わせる」スイッチを持っていると、実際の LISTEN と OS のプロキシ参照先の両方を揃える必要があります。external-controller を有効にしている場合、ダッシュ用の 9090 など 別番号も同時に使う設計がよくあります。まずログに出た番号を 正 にし、余計な行がないか(古い port と新しい mixed-port の重複など)を、エクスポートした YAML でざっと眺めます。Docker や WSL から同じ口を奪い合うケースの整理は、Docker・CLI からの mixed-port 利用と役割が近く、併用時は衝突が出やすい点だけ押さえておけば足ります。
listen tcp や bind、:7890 のように :+数字が並んでいるときは、次節以降の PID 調査に進みます。番号がログに出ないクライアントは、一時的に log-level: debug を上げて起動直後の数行を保存してください。
Windows 11:PID を netstat や PowerShell で追う
管理者 PowerShell か コマンド プロンプトを開き、例として衝突が疑われる 7890 について、次の形で 待受と PID を出します。ビルドや言語パックの違いで表記は多少変わりますが、LISTENING 行の末尾に 数値(PID) が出る点は共通です。
netstat -ano | findstr :7890
findstr の行に LISTENING がある行の 最後列が PID です。タスク マネージャーの「詳細」タブで PID 列を表示し、該当する イメージ名を確認します。心当たりのない古い clash 系、別の v2ray 系、あるいは開発用の node など、用途に合わないプロセスのときは、当該アプリの公式な終了手順(トレイから終了、サービスなら管理ツール)を先に試し、強制終了は他の作業中データが飛ばない範囲に留めてください。初回インストールで手順の全体感を掴みたい場合、Windows 11 上の Clash Verge Rev 手順では「TUN やファイアウォール周りの確認」とつながり、待受周りの迷いを減らしやすいです。
PowerShell 5/7 なら、次の例のように 局所アドレスで絞ることもできます(ファイアウォール方針や IPv6 有効化で表記は変化します)。ここで得た OwningProcess が、前述の netstat -ano の PID と同じ作用です。
Get-NetTCPConnection -LocalPort 7890 -State Listen -ErrorAction SilentlyContinue |
Select-Object -First 1 LocalAddress,LocalPort,OwningProcess
macOS:lsof とアクティビティモニタで紐づける
ターミナルで lsof -nP -iTCP:7890 -sTCP:LISTEN のように、衝突番号に読み替えて実行します。出てくる COMMAND と PID が手がかりです。続けて macOS 側の TUN・システム拡張とプロキシ衝突の整理も併せて読むと、以前の 同名プロセスの残骸や、システムプロキシとクライアント表示の食い違いに気づきやすくなります。GUI で確認するなら、ユーティリティの アクティビティモニタ「ネットワーク」タブで、該当した PID/プロセス名を辿る方法が直感的です。
sudo kill -9 は他アプリの未保存作業を壊し得るため、まず安全な「終了」、必要なら「強制終了」で十分かを見極めてください。原因が不明な 常駐プロセスの場合、ベンダ文書の削除/アンインストール手順の方が安全なことがあります。
対処 A:原因プロセスの終了/対処 B:mixed-port などを変更
対処 A:不要な 二重起動や、旧バージョンの 別クライアントが同じ口を掴んでいるなら、完全終了(メニューから quit)が基本です。Windows のサービス登録形態や macOS の LaunchAgent 型では、一度終了しても次の起動で戻るため、作業中でなければ該当する自動起動設定を見直します。対処 B:一時的に衝突を避けるには、config.yaml ベース(またはクライアントの設定画面)で mixed-port を、例えば 7890 から 17890 など、手元で空いていそうな 非特権帯へ移します。同時に、クライアントの「システムプロキシを設定」系オプションが有効なら、新端口番号に合わせ直します。HTTP と SOCKS を分けた設定にしているなら、port(HTTP)と socks-port の 両方の重複に注意し、終了後にインターネットが戻らない系の不整合と混ざると混乱しやすいので、いま参照している口はどれかをメモに残すと次回が楽です。
外部の Web ダッシュ(外部コントローラー)のポートを変えた場合、ブックマークや secret 付き URL も合わせて更新してください。チーム内で「全員 7890」にしていると衝突が起きにくい反面、ローカルで他ツールと衝突しやすい、というトレードオフがあります。長期的には、自分専用の空き番号に固定し、他セッション(開発サーバ、別 VPN クライアント)の予約帯と被らないよう運用表を一つ持つのが安定です。変更後にコアが落ち着いたら、不要になった一時的な上書きを消し、再現手順だけを所定の config に残すと次回の雑音が減ります。セキュリティ上の都合で任意の高番号を掴めない職域端末なら、IT 部門のガイドに従い、許可された待受帯に寄せるのが最優先です。
# 例:mixed-port だけ上げる(他キーは既定のまま想定)
mixed-port: 17890
# HTTP/SOCKS を分ける構成なら、該当行が重複してないかも確認
# port: 0
# socks-port: 0
疎通確認:システムプロキシとクライアント表記の揃え
再起動してエラー行が出なくなったら、127.0.0.1 または localhost に対し、新しい HTTP/SOCKS ポートを指定して curl 等で到達性を見ます。ブラウザの拡張プロキシと OS のシステムプロキシ、Clash クライアントの「システムプロキシ」は別レイヤーなので、三つ全てが同じ数字を指す必要は必ずしもありませんが、混在すると挙動が紛らわしいです。少なくとも「ブラウザが向けている口」と「今 LISTEN している口」は一致していなければなりません。ルール層の話に進む前に、ここを合わせると、ルール分流の微調整に迷いがちな時間を減らせます。ローカルマシン外へ出る接続性は、TUN モードとポートプロキシの切り分け方にも影響するため、TUN 使用時は仮想インタフェースまで含め、クライアント表示と OS の状態を併せて観測します。
まとめ
Address already in use は、多くの場合 番号取り合いが原因であり、遠方ノード品質の問題と混同しやすい層の手前にあります。まず衝突番号をログから抜き、Windows 11 では netstat -ano/Get-NetTCPConnection、macOS では lsof とアクティビティモニタで PID を突き止め、当該プロセスを正規の手順で止めるか、mixed-port など待受定義をずらし、システムプロキシ表示を再同期すれば、起動失敗のループを抜けやすいです。同じ職場で手順を揃えたいときは、番号帯の「予約表」を 1 枚残し、他の常駐プロキシと被らないようにするだけでも再発率が下がります。安定した挙動を体験したい方は、Clash を無料でダウンロードし、ログの一行を失わないクライアントから、まず本番用の config だけを一か所に集約する運用に寄せるのが近道です。