エラーの内容
git clone、git pull、または git push を実行すると、Git が突然止まります：
fatal: unable to access 'https://github.com/user/repo.git/': Could not resolve host: github.com
Git はリモートサーバーに到達すらできません。認証プロンプトも、プロトコルハンドシェイクも発生せず、DNS ルックアップの段階で接続が失敗します。これは Git のバグではなく、ネットワーク層の問題です。
まず原因を診断する
闇雲に設定を変更するのは禁物です。まず以下の2つを確認しましょう：
# github.com の名前解決ができるか確認
ping github.com
# dig/nslookup でクリーンな DNS チェックを行う
dig github.com
nslookup github.com
ping で unknown host が返ってくる、または nslookup で応答がない場合は DNS が壊れています — 修正1へ進んでください。ping は通るのに Git だけ失敗する場合は、ほぼ確実にプロキシが原因です — 修正2へ進んでください。
# Git にプロキシが設定されているか確認
git config --global http.proxy
git config --global https.proxy
修正1 — DNS が壊れている（最も一般的）
マシンが github.com を IP アドレスに変換できない状態です。パブリック DNS リゾルバに切り替えることで、たいてい1分以内に解決できます。
Linux / macOS
# /etc/resolv.conf を編集して、動作するネームサーバーを追加
sudo nano /etc/resolv.conf
# 先頭に以下のいずれかを追加：
nameserver 8.8.8.8
nameserver 1.1.1.1
systemd-resolved を使用しているシステム（Ubuntu 18.04以降、Fedora など）では、resolv.conf への変更は再起動後に失われます。代わりに resolvectl を使用してください：
sudo resolvectl dns eth0 8.8.8.8 1.1.1.1
Windows
# PowerShell（管理者として実行）
Set-DnsClientServerAddress -InterfaceAlias "Ethernet" -ServerAddresses 8.8.8.8,1.1.1.1
GUI から設定する場合は、ネットワーク設定 → アダプターのオプションを変更 → IPv4 プロパティ から DNS サーバーを 8.8.8.8 に設定してください。
確認
ping github.com
# 表示例: 64 bytes from 20.205.243.166 (または類似のIP)
修正2 — Git のプロキシ設定が間違っているか古い
最近ネットワークを切り替えましたか？VPN のオン/オフ、オフィスから自宅、ホテルの Wi-Fi など。Git はプロキシ設定を無期限に保持します。手動でクリアするまで、存在しないプロキシ経由でルーティングし続けます。
# プロキシ設定を削除
git config --global --unset http.proxy
git config --global --unset https.proxy
# 削除されたことを確認
git config --global --list | grep proxy
プロキシが必要な企業ネットワーク上では、正しく設定してください：
git config --global http.proxy http://proxy.company.com:8080
git config --global https.proxy http://proxy.company.com:8080
グローバル設定を変更せず、特定のリポジトリだけに適用したい場合：
git config http.proxy http://proxy.company.com:8080
修正3 — ファイアウォールがポート443をブロックしている
ポート443に実際に到達できるか確認します：
# Linux/macOS
curl -v https://github.com
# Windows
Test-NetConnection -ComputerName github.com -Port 443
接続がタイムアウトする場合、ファイアウォールまたはセキュリティアプライアンスが HTTPS トラフィックをブロックしています。対処法は3つあります：
- ネットワーク管理者に依頼して、ポート443で
github.comをホワイトリストに追加してもらう - 別のネットワークに接続する（モバイルホットスポットは簡単なテストに最適）
- SSH に切り替える — 修正5を参照
修正4 — /etc/hosts への不正なエントリ
/etc/hosts の1行が DNS 全体を上書きし、github.com を 0.0.0.0 や古い内部 IP に向けてしまうことがあります。確認は簡単です：
grep -i github /etc/hosts
github.com をローカルまたは無効なアドレスにリダイレクトしている行を削除してください。このファイルは GitHub Desktop や一部の VPN クライアントによって変更されることがあります — 削除する前に必ず内容を確認してください。
修正5 — HTTPS から SSH に切り替える
プロキシやファイアウォールによって HTTPS が繰り返しブロックされる場合、SSH を使うことで問題を回避できることがあります。ポート22とポート443は独立してフィルタリングされるため、一方がブロックされていても他方は通る場合があります。
# リモート URL を HTTPS から SSH に変更
git remote set-url origin git@github.com:user/repo.git
# 確認
git remote -v
GitHub アカウントに紐付いた SSH キーが必要です。まだ作成していない場合は生成してください：
ssh-keygen -t ed25519 -C "your@email.com"
cat ~/.ssh/id_ed25519.pub # これをコピーして GitHub → Settings → SSH Keys に登録
# 接続テスト
ssh -T git@github.com
# 期待される出力: Hi username! You've successfully authenticated...
修正6 — VPN がパブリック DNS を壊している
企業の VPN はよくある原因の一つです。多くの VPN は内部トラフィックのみをトンネル経由でルーティングするよう設定されており、github.com のような外部サイトへのパブリック DNS 解決が壊れてしまうことがあります。
簡単なテスト：VPN を切断して Git を再試行してください。すぐに動作すれば VPN の設定が問題です。対処法はいくつかあります：
- IT 部門に
github.comに対するスプリットトンネルが正しく設定されているか確認する - GitHub の現在の IP アドレスを使って静的な
/etc/hostsエントリを追加する — 正常に動作しているマシンでdig github.comを実行して IP を取得する - SSH に切り替える（修正5）— VPN トンネル経由でも異なるルーティングが行われる場合がある
修正後の確認
# 軽量なリモート確認 — クローン不要
git ls-remote https://github.com/user/repo.git
# または、小さなパブリックリポジトリをクローンして実際にテスト
git clone https://github.com/github/gitignore.git /tmp/test-clone
# テスト後の後片付け
rm -rf /tmp/test-clone
git ls-remote が参照一覧を表示すれば、接続は完全に機能しています。
補足情報
複雑なサブネットや VPN 環境でデバッグしている場合、どの IP レンジが使われているかを把握しておくと役立ちます。ToolCraft のサブネット計算ツールを使えば、CIDR レンジを確認して GitHub の IP ブロック（140.82.112.0/20 など）が制限されたサブネット内に含まれているかどうかを検証できます。ブラウザ上で完全に動作し、どこにもデータは送信されません。
恒久的な対策として、マシンごとではなくルーターレベルで DNS を 8.8.8.8 または 1.1.1.1 に設定することをお勧めします。ネットワーク上のすべてのデバイスが恩恵を受けられ、OS の再インストールや新しい開発マシンのセットアップ後に同じ問題を追いかけることもなくなります。