1. 症状の整理（本当に起動していないか）
まず「Clash が動いていない」の定義を揃えます。通知領域（トレイ）にアイコンが無いからといって、必ずしもプロセスが無いとは限りません。設定によっては起動直後にトレイへ格納されず、あとから現れる／クリックするまで見えない、というクライアントもあります。
タスク マネージャー（Ctrl + Shift + Esc）の「詳細」で、使用中のクライアント名（例：Clash Verge、実行ファイル名）やコア（mihomo 系）が立ち上がっているかを確認してください。ここで動いているのにブラウザだけプロキシが効かない場合は、本稿のテーマである「自動起動」より、TUN やファイアウォール、ミックスドポートとシステムプロキシの方が近いです。
逆に、ログオン直後はプロセスが無いが、しばらくしてから現れる場合は、遅延起動や他サービスの後に起動といったタスク設定の影響を疑います。次の各節は「再起動後、自分がデスクトップを触れる時点で、意図どおり常駐しているか」を前提に進めます。
2. クライアントの「自動起動」設定
Clash Verge、Clash for Windows など、配布形態ごとに「OS 起動時に実行」「Open at login」「Start with system」といった名称のトグルがあります。ここをオンにしたつもりでも、アップデート後に既定値へ戻る、別の設定プロファイルに切り替わって無効化される、といったことは珍しくありません。
一度オフにして保存し、再度オンにしてから完全終了（トレイの終了メニュー）→再起動、の順で試すと、GUI がレジストリやスタートアップ登録を書き直してくれる場合があります。クライアントの選び方は 比較記事も参照してください。
3. スタートアップとシェル スタートアップ
Windows 11 では「設定 → アプリ → スタートアップ」に一覧が出ます。ここで対象アプリがオンになっているか、優先度が「低」になっていて極端に遅延していないかを見ます。オフになっていたらオンにし、逆に二重登録で競合していないかも意識してください（同じ exe が複数経路で登録されると、一方が失敗してもログに残りにくいです）。
従来どおり、シェル:スタートアップフォルダにショートカットを置く方法も有効です。エクスプローラのアドレス欄に shell:startup と入力すると、現在のユーザー用のスタートアップが開きます。ここに公式のショートカットだけが残っているか、古いパスのショートカットが残っていないかを確認します。
すべてのユーザー向けスタートアップ
複数アカウント PC では、shell:common startup に別のショートカットが置かれ、想定と違うユーザーだけ起動する、ということもあります。誰のログオンで動かしたいかに合わせて整理してください。
4. タスク スケジューラ（ログオン時）
GUI のチェックだけでは不十分な場合、最も確実なのがタスク スケジューラでログオン時に実行することです。新規タスク作成時のポイントは次のとおりです。
- トリガー：「ログオン時」— 対象を「特定のユーザー」に絞るか、問題のあるアカウントで再現するかに合わせる。
- 操作：プログラムのパスに実行ファイル（
.exe）を直接指定。ショートカットではなくフルパスが無難。 - 条件：ノート PC では「AC 電源のみ」等のチェックがオンだと、バッテリー起動時に走らない。
- 設定：「タスクが失敗したら再起動」は必要に応じて。ログを残すなら「履歴」を有効化。
「最上位の特権で実行」は、コアや TUN が管理者権限を要する構成では有効なことがありますが、常にオンにすると UAC の挙動やセキュリティソフトのスキャン対象が変わります。まずはオフでログオン起動できるかを確認し、必要ならオンに切り替えると切り分けがしやすいです。
5. 管理者権限と UAC
毎回「管理者として実行」しないと TUN や一部機能が動かない、という構成では、スタートアップに通常権限で登録されているとサイレントに失敗しやすいです。UAC のプロンプトを出さずに高権限で動かすには、タスク スケジューラで「最上位の特権で実行」を使うか、クライアント側が推奨するサービス化・別ランチャーに従う必要があります。
逆に、不要なのに常に管理者で動かしていると、他ユーザーのコンテキストからの自動起動と衝突したり、セキュリティ製品に強く止められたりします。「本当に管理者が必要なのはどの機能か」を切り分け、公式ドキュメントの TUN／システムプロキシの項と照らしてください。
6. セキュリティ製品とスマートスクリーン
Windows Defender やサードパーティのセキュリティ製品は、未知の実行ファイルや更新直後のバイナリを一時的に隔離し、スタートアップやタスクからの起動をブロックすることがあります。除外設定にインストール先フォルダとコア exe を入れるか、一度検出ログを確認し、誤検知であれば許可リストへ追加します。
スマートスクリーンが「よくないことが起きる可能性があります」と止めるケースでは、手動実行では通っても、ログオン直後の無人起動ではユーザー操作が入らず止まることがあります。デジタル署名のあるビルドを使う、配布元を信頼できるものに固定する、が根本対策です。インストールや更新は 本サイトのダウンロードページから入手する形を推奨します（ソースコードや Issue は GitHub で確認する、と用途を分けると誤解が減ります）。
7. 高速スタートアップ・ユーザー・電源
高速スタートアップ（ハイブリッド シャットダウン）が有効な環境では、「シャットダウン」しても完全な冷起動と同じにならず、スタートアップ項目の挙動が直感とズレることがあります。切り分けのときは一度再起動（Restart）で試し、問題が再現するか比較してください。
また、リモート デスクトップや別ユーザーへの切り替えでは、「ログオン時」タスクがどのセッションで動くかが変わります。サーバ用途や常時稼働マシンでは、ログオンに依存せずサービスとして動かす案もありますが、一般的な Clash クライアントはデスクトップ常駐が前提のため、まずは対象ユーザーのセッションでタスクが登録されているかを確認します。
スリープからの復帰直後だけ起動しない場合は、電源オプションの高速スタートアップやUSB の選択的サスペンドなどより、単純に起動順が遅いだけのこともあります。タスクに数十秒の遅延を入れてネットワーク スタックが立ち上がったあとに実行する、という回避も有効です。
8. 症状対照表
代表的なパターンと、最初に見る場所の目安です。
| 症状のイメージ | まず疑うこと | 試すこと |
|---|---|---|
| 再起動のたびに手動で起動が必要 | GUI の自動起動オフ／スタートアップ未登録 | 設定の再保存、shell:startup、タスクでログオン時 |
| ログオン直後だけ出ないが、しばらくすると現れる | 遅延起動・低優先スタートアップ | スタートアップの優先度、タスクの遅延時間 |
| 更新後から起動しなくなった | パス変更・セキュリティの隔離 | タスクのパス更新、除外設定、再インストール |
| 手動では動くが自動だけ失敗 | 権限・UAC・スマートスクリーン | タスクの最上位特権、署名付きビルド、ログ確認 |
| 別ユーザーでは動く／動かない | ユーザー別スタートアップとタスクのスコープ | 該当ユーザーでタスク作成、common startup の整理 |
9. まとめ
Clash Windows の自動起動が効かないときは、クライアント内のトグル → スタートアップ（設定アプリと shell:startup）→ タスク スケジューラのログオン時 → 管理者権限と UAC → セキュリティ製品、の順に見ると迷いが少なくなります。Linux の systemd 常駐とは別物ですが、「常に同じ手順で常駐させたい」という目的は同じです。
トレイにアイコンが無い場合でもプロセスが生きていることがあり、接続不全は TUN やルールの問題かもしれません。本稿のチェックで「起動は安定したが通信が不安定」になったら、同ブログの Windows 向け記事を組み合わせてください。