TailscaleでリモートMacが再起動後にオフライン：2026年SSH修復ガイド

Macは再起動できたのに、Tailscaleの管理画面ではノードがオフラインのままになっています。

最短の修復方針は、Tailscaleノードの切断、MagicDNSの名前解決失敗、macOS SSHサービスの拒否を別々に切り分けることです。常用する開発機やビルドノードなら、ウェブコンソールまたはVNCを帯外の復旧経路として残し、受け入れ試験を通過するまで無人運用へ移行しないでください。

このページは、Xcode、自動ビルド、長時間のタスクを遠隔Macで動かし、再起動後も接続を戻したい開発者向けです。複数のmacOSノードの認証、アクセス制御、SSH権限を管理するDevOps担当者や、公開SSHポートを避けたいチーム管理者にも適しています。

SECTION 01 最初に故障層を確定する

表示が「オフライン」でも、実際の故障箇所は同じとは限りません。管理画面、名前解決、SSH接続の順に観察し、先に証拠を残してから設定を変更します。

CLIを使える状態なら、tailscale status でピアと接続状態を確認できます。コマンドの出力項目は、Tailscale CLIのstatus説明に照らして読み取ってください。アイコンがメニューバーにあるだけでは、SSHの到達性までは保証されません。

SECTION 02 復旧経路を先に比較する

再起動後にTailscaleが戻らない可能性を残したまま、単一のSSH経路へ依存するのは危険です。次の比較で、あなたの運用に必要な経路を決めます。

Appleが案内するmacOSの「リモートログイン」は、SSHとSFTPを提供します。一方、Tailscaleは機器間の接続経路を作る役割であり、接続先MacでSSHサービスが有効になっていなければログインできません。Appleのリモートログイン設定を確認してください。

SECTION 03 ログインセッションとシステム拡張を確認する

Macの再起動完了と、Tailscaleの接続復旧は別の出来事です。遠隔Macがログイン画面で停止している場合、通常のクライアントがユーザーセッションに依存していれば、Tailscale側のノードがオンラインへ戻らないことがあります。

帯外経路で画面を開き、次の順番で確認します。

• Macがログイン画面、ユーザー画面、または復旧画面のどこにいるか確認します。
• Tailscaleクライアントが起動しているか、認証を要求していないか確認します。
• システム拡張やネットワーク拡張の承認待ちが表示されていないか確認します。
• macOSのアップデート後またはTailscale更新後に、ネットワーク権限が変わっていないか確認します。
• クライアントのログと管理画面の状態を突き合わせます。

TailscaleはmacOSでシステム拡張を利用する形態があり、承認や読み込み状態が接続に影響します。macOSシステム拡張に関する公式説明を参照し、メニューバーの表示だけで正常と判断しないでください。

自動ログインを有効にすれば復旧する場合がありますが、端末へ到達した第三者がユーザーセッションを取得するリスクも増えます。先にVNCやウェブコンソールの認証、ディスク暗号化、運用者の復旧手順を確認し、安全性を下げる変更を標準手順にしないでください。

Tailscaleの公式説明でも、macOSの通常クライアントはログイン前からシステムサービスと同じように動くものではないとされています。無人運用に関する公式ガイドで、使用しているクライアント形態の制約を確認してください。

SECTION 04 ノード認証とアクセス制御を再点検する

クライアントが起動していても、デバイスの認証期限、承認待ち、再認証要求によって接続が戻らないことがあります。再認証や状態削除を急ぐ前に、既存の認証情報、管理画面のデバイス名、タグ、帯外経路を記録してください。

特に長期稼働ノードでは、個人の開発機と同じ扱いにしないことが重要です。ユーザーの退職や鍵の交換でノードが突然使えなくならないよう、運用主体、タグ、認証期限、復旧担当を分けて管理します。

アクセス制御は「接続元がTailscale内にいるか」だけで許可せず、送信元の識別、対象タグ、ポート、ユーザーを限定します。Tailscaleのアクセス制御公式ドキュメントとポリシー構文リファレンスを確認し、変更後は許可すべき接続と拒否すべき接続の両方を実際に試します。

状態ファイルの削除やクライアントの再インストールは、最後の手段です。これらはノードの身元を変えたり、現在の認証情報を失わせたりする可能性があるため、ウェブコンソールまたはVNCで戻せることを確認できない場合は実行しないでください。

SECTION 05 MagicDNSとSSHを別々に復旧する

ノードアドレスでは接続できるのに、デバイス名では失敗するなら、Tailscale本体よりMagicDNSを先に疑います。MagicDNSはTailnet内の機器名を扱う機能であり、名前解決の挙動は接続経路そのものとは異なります。MagicDNSの公式説明とDNS動作のFAQを確認してください。

診断は次の順番で行います。

• 接続元から対象Macのノードアドレスへ疎通を確認します。
• 同じ接続元からMagicDNSの完全な名前を解決します。
• ssh -vvv ユーザー名@ホスト名 を実行し、名前解決前後のログを保存します。
• アドレス指定でSSHが始まり、名前指定だけ失敗するならDNS設定を修正します。
• どちらも失敗するなら、Tailscale状態、ポリシー、macOS SSHサービスを戻って確認します。

macOS側では「システム設定」の共有項目から「リモートログイン」を確認し、許可するユーザーを限定します。Tailscaleの経路が正常でも、ここが無効なら通常のSSH over Tailscaleは成立しません。

ここで通常のSSH over TailscaleとTailscale SSHを混同しないでください。前者はmacOS標準のSSHサービスをTailscaleの接続上で使う構成です。後者のサーバー機能は、対応するオープンソース版のtailscaleおよびtailscaledを使える形態に限って検討します。Tailscale SSHの公式仕様では、macOSの通常クライアントへそのまま適用できるとは説明されていません。

SECTION 06 受け入れ試験として再起動を実施する

修復後は、単にSSHで入れたという理由だけで本番投入しません。保守時間を決め、観察結果と手動介入の有無を記録しながら、次のマイルストーンを一つずつ通過させます。

Macがオンラインになる前にログイン操作が必要だった場合、その事実を「自動復旧」と記録してはいけません。無人状態でTailscaleが戻らないなら、帯外制御を本番運用の必須条件にし、単一のSSH経路へ戻らない設計にします。

既存のSSH鍵運用を見直す場合は、macOSのSSH鍵認証と権限管理に関するガイドも参照してください。遠隔Macを継続的なビルドノードとして扱うなら、VPSNIXのMacレンタル案内で利用形態を確認し、接続経路の検証条件を先に整理しておくと判断しやすくなります。

SECTION 07 よくある判断を短く確認する

FAQでは、再起動後のTailscale接続、公開IPなしのSSH、無人ログイン、Tailscale SSHの適用範囲を分けて回答しています。どれか一つが成立しても、残りの経路まで自動的に正常になるわけではありません。

SECTION 08 結論：再起動試験を通過してから運用方法を決める

自前のMacを使い続ける場合、再起動後にログインセッションが戻らない、拡張機能の承認で停止する、MagicDNSとSSHの状態を別々に監視しなければならない、といった管理負担が残ります。公開IPを避ける構成でも、帯外復旧経路がなければ、Tailscaleの切断時に遠隔から手を出せません。

そのため、既存設備に確実なウェブコンソールやVNCがなく、毎回現地操作が必要になるなら、VPSNIXのMacレンタルを候補に入れ、契約前にTailscale、MagicDNS、SSH、再起動後の復旧を一連の手順として確認するのが現実的です。VPSNIXの料金と利用プランを確認し、短期の検証環境や一時的なビルドノードとして適するかを、必要な帯外アクセス条件と合わせて判断してください。長期にわたり物理ポートや専用ハードウェアが必要な運用では、自購入のMacのほうが適する場合もあります。

関連記事

• Windows 11からリモートMacへ接続する方法と運用フロー
• Mac miniのリモート運用におけるレンタルと購入の選び方