SiteOps
トップメディアダッシュボード更新履歴
記事一覧

github.com が引けない（Could not resolve host）の最初の30分でやること

`Could not resolve host: github.com` が出たときに、DNS/プロキシ/環境差を最短で切り分けて復旧する手順です。

著者: 川原更新: 2026-05-13障害対応RSS
Xで共有FacebookLinkedIn
料金相談

CIやデプロイで急に Could not resolve host: github.com が出ると、「GitHubが落ちた？」と疑いたくなります。でも多くの場合、原因は“あなたのネットワーク（DNS/プロキシ/社内FW）側”です。まずは推理より、切り分けを速くして復旧までの時間を短くします。

この記事は、github.com が引けない（DNS解決できない）ときに、最初の30分でやることを固定するチェックリストです。

0. まずやらないこと

  • 依存を一斉更新する（問題を増やす）
  • 認証/SSH鍵/トークンを回し始める（今回のエラー種別では多くが無関係）
  • いきなりネットワーク機器の設定を触り散らかす（戻せない変更が混ざる）

1. “どこで”解決できていないかを3段に分ける（最優先）

同じ Could not resolve host に見えても、壊れている場所が違うと対処が変わります。

  1. ローカルPC（あなたの端末）だけ
  2. そのネットワーク（Wi-Fi / 会社の回線 / VPN）配下だけ
  3. 特定の実行環境だけ（例: CI、Docker、VM、Cloudflare Workersのビルド環境など）

この分類ができると、次に見るべき場所が一気に減ります。

2. まずは“同じ条件”で最小の再現コマンドを作る

最初の5分で、実行環境の中で以下だけ確認します。

  • curl -I https://github.com が引けるか
  • nslookup github.com / dig github.com のどちらかが動くか（無ければスキップ）
  • git ls-remote https://github.com/<owner>/<repo>.git が引けるか

ここで curl だけ落ちる / git だけ落ちる、の違いが見えたら勝ちです。

3. 典型原因トップ5（当たる順）

A. DNSが死んでいる / 切り替わっている

  • DNSサーバが落ちた、または社内DNSが github.com を引けない
  • VPN接続でDNSがすり替わっている
  • 端末のDNSキャッシュが壊れている（稀に起きます）

対処（戻せる順に）:

  • いったん別ネットワーク（テザリング等）で同じコマンドを再実行
  • VPNを切って再実行（業務上NGなら無理にやらない）
  • DNSを一時的にPublic DNS（例: 1.1.1.1 / 8.8.8.8）に切替えて再実行（変更点は必ずメモ）

B. プロキシ/フィルタでブロックされている

  • HTTPS_PROXY / HTTP_PROXY / NO_PROXY が意図せず効いている
  • 社内FWでGitHubがブロックされた（カテゴリフィルタ等）

対処:

  • 実行環境でプロキシ関連の環境変数を確認して、想定外がないかを見る
  • 同じ環境で別ドメイン（例: example.com）は引けるかを確認（DNS自体か、GitHubだけか）

C. コンテナ/VMだけDNSが壊れている

  • ホストはOKだが、Dockerコンテナ内だけ解決できない
  • resolv.conf が変になっている

対処:

  • “ホスト”と“コンテナ内”で同じ curl を比較して差分を取る
  • コンテナ実行時のDNS指定やネットワーク設定（社内の推奨設定）を確認

D. IPv6まわりの不整合

環境によってはIPv6優先で解決して、実際の到達が落ちることがあります。

対処:

  • 可能なら curl -4 / curl -6 で差分を見る（使えない環境ならスキップ）

E. 一時的な外部障害（最後に疑う）

GitHub側の障害はゼロではありませんが、最初に疑うと復旧が遅れやすいです。

対処:

  • GitHub Statusを確認（ただし“自分の環境だけ”の可能性は残るので、必ずA〜Dの切り分けを先に）

4. 10分で“暫定復旧”する（業務を止めない）

根本対応に入る前に、復旧だけ先に取れることがあります。

  • いったん別ネットワークで git pull / npm install / bun install だけ通す
  • 依存の取得が目的なら、ミラーやキャッシュ（社内設定）があるならそれを使う
  • CIなら「GitHubアクセスが必要なジョブ」だけ再実行する（全体を回し直さない）

5. 収束後にやること（再発防止）

  • “どの環境で” “どのコマンドが” 失敗したかを短く記録する
  • DNS/プロキシ変更をした場合は、必ず元に戻す手順も一緒に残す
  • 同じ事象が起きたときの確認コマンドを、チームのrunbookに追記する

運用の事故は「次の一回を短くする」ほど強くなります。

参考（公式）

  • GitHub Status（外部障害の最終確認）: https://www.githubstatus.com/
  • macOSのDNS設定変更（Apple公式）: https://support.apple.com/en-jo/guide/mac-help/mh14127/mac
  • macOSで1.1.1.1をDNSに設定（Cloudflare公式）: https://developers.cloudflare.com/1.1.1.1/setup/macos/

この記事を書いた人

川原

SiteOps編集チームの公開窓口として、検索、アクセス、収益データをもとにした運営判断の知見をまとめています。

著者情報

関連記事

Cloudflare 502 Bad Gatewayが出たとき、最初の30分でやること障害対応更新: 2026-05-18Cloudflare 504 Gateway Timeoutが出たとき、最初の30分でやること障害対応更新: 2026-05-18Cloudflare 520（Web server returned an unknown error）が出たとき、最初の30分でやること障害対応更新: 2026-05-18
前の記事robots.txt を変えたらクロールが止まったとき、最初の30分でやること次の記事libSQL/Tursoで `database is locked` が出たとき、最初の30分でやること

次にやること

複数サイトの検索、アクセス、収益データをまとめて見直すなら、SiteOpsのダッシュボードでサイト別に確認できます。

料金を見る相談したい / お問い合わせ