GitHubにつながらない・pushできない時の対処|障害・認証・通信経路の確認

GitHubの画面は開くのにpushできない、SSHだけつながらない、APIが失敗する場合は、同じGitHubでも経路と認証が異なります。手元の変更を消さず、読み取り確認から始める手順をまとめます。

【要点】リポジトリを初期化せずに調べる

• ローカルの変更と未送信のコミットを保護します。
• Web、HTTPS、SSH、APIのどれが失敗するか記録します。
• 認証失敗やブランチ保護をサービス障害と混同しません。
• force pushやTLS検証の無効化で接続不良を直そうとしないでください。

公式サービス障害モニターほかのサービスの障害・メンテナンス・復旧履歴を確認

この表示はGitHubのGit操作・APIなどの公開対象です。GitHub Actions、Copilot、Pagesは別項目で、企業内のGitHub Enterprise Serverの稼働を保証するものではありません。

失敗する操作と原因候補

変更を守って接続を確認する

1. git status で未保存・未コミットの変更を確認します。必要なものを普段の手順で保存します。
2. Webで対象リポジトリを開き、想定したアカウントで閲覧できるか確かめます。
3. 管理対象のリポジトリで git ls-remote origin を使うと、作業ファイルを書き換えずにリモート参照を取得できるか確認できます。
4. エラー全文と時刻を記録し、別の許可された環境と比較します。認証情報が含まれるURLは報告から除きます。

接続のテストとしてpullすると、設定によってマージやリベースが始まります。障害確認だけなら、最初は作業状態を変えない操作を選びます。失敗したpushが一部反映されたか不明な時は、Webやリモート参照でコミットを照合してから再開してください。

SSHだけ失敗する場合

通常の接続先を使っていることを確認し、必要に応じて ssh -T git@github.com で認証を試します。初回にホスト鍵の確認が出たら、公式のフィンガープリントと一致を確認してから進みます。不明な警告を無視したりknown_hostsを一括削除したりしません。

会社のネットワークがSSHを制限している場合は管理者へ相談します。GitHub.comには443番ポート経由のSSHもありますが、接続先は通常の github.com ではなく専用のホストです。対象外のEnterprise環境もあります。公式のSSH接続方法を確認し、許可なく通信制限を回避する目的では使いません。

認証と証明書のエラー

トークンの期限、アクセス対象、組織の認証が関係する場合は、必要なリポジトリへの権限を管理者と確認します。WebからログアウトしてもSSH鍵の問題は直りません。すべてのキーを作り直す前に、失敗している方式を特定してください。

証明書エラーは社内プロキシや信頼ストアの問題も含みます。GitHub公式の接続不良の対処に沿って管理者へ相談します。sslVerify=false などで検証を止めると安全性を損なうため、恒久的な解決にしません。

pushが失敗したように見える場合

通信が切れた場所によっては、サーバー側で受け付けられた後に結果だけ受信できなかった可能性もあります。復旧後にリモートの対象ブランチとコミットIDを確認し、手元の送信対象と照合します。エラーを消すために強制pushや履歴の作り直しを行う必要はありません。共同作業者の変更が入っていないかも確かめてから通常の手順で再開します。

Webが開くのにGit操作だけ失敗するなら、認証方式と接続経路を分けて記録します。トークンやSSH鍵を無差別に作り直すと、他のツールの認証にも影響します。読み取り確認が通った後、pushやpull requestの更新を一つずつ確認してください。障害中に残したローカル変更は、リモートへ反映されたと確認できるまで保持します。

まとめ

GitHubでは操作経路を分け、変更を保護して読み取りテストを行います。復旧後は未送信コミット、pull request、WebhookやAPI処理の残件を確認します。通信が戻ったことと、開発・配信の工程が完了したことを別々に確認してください。

国内の通信・アプリ・企業システム障害のまとめを見る