「Connection timed out」という悪夢
月曜日の朝、コーヒーを片手に話題のライブラリを git clone しようとしたその時、画面に真っ赤な文字が表示されます：Fatal: Failed to connect to github.com port 443: Timed out。30秒間虚しく待った後、あなたは再び会社のファイアウォールに捕まったことに気づきます。
このファイアウォールの背後にある理由は、実は非常にシンプルです。銀行や大企業のようなセキュリティレベルの高い環境では、インターネットへのすべてのトラフィックはプロキシサーバーを経由する必要があります。プロキシを設定していない場合、Git は直接接続しようとしてファイアウォールに即座にブロックされます。
私もかつて、愚かなミスで午前中を棒に振ったことがあります。GitHub からコードをダウンロードするためにプロキシを設定した後、そのことをすっかり忘れてしまいました。社内の GitLab にコードをプッシュしようとした際、Git は「張り切って」会社のプロキシ経由でトラフィックを送信しました。その結果、プロキシは社内サーバーを認識できず、すべてがフリーズしてしまいました。
なぜ Git で Global Proxy を使うべきではないのか？
StackOverflow で最も一般的な方法は、グローバル設定コマンドを使用することです：
git config --global http.proxy http://proxy-server:8080このコマンドでインターネット接続は解決しますが、大きな問題を引き起こします。この設定はマシン上のすべてのリポジトリに適用されてしまうからです。
- GitHub/GitLab.com の場合: 正常に動作します。
- 社内 GitLab (イントラネット) の場合: プロキシが LAN 内の IP アドレスを解決できず、接続エラーが発生します。
プロジェクトを切り替えるたびに unset と set を繰り返すのは非常にストレスが溜まります。Git にはディレクトリごとに設定を自動で切り替える機能もありますが、プロキシというパスポートをいつ使うべきかを判断するよりスマートな解決策が必要です。
解決策1：ドメインごとに個別のプロキシを設定する（推奨）
Git ではリポジトリの URL に基づいてプロキシを指定できます。これが GitHub からコードをクローンしつつ、社内サーバーともスムーズに連携するための最もクリーンな方法です。
GitHub 用の設定
漠然とした global 設定の代わりに、https://github.com ドメインがプロキシを経由するように明示的に指定します：
git config --global http."https://github.com".proxy http://user:pass@proxy-server:8080GitLab または Bitbucket 用の設定
他のプラットフォームにも同様に適用できます：
git config --global http."https://gitlab.com".proxy http://proxy-server:3128この方法では、GitHub を操作するときだけ Git がプロキシを使用します。ターミナルから GitHub CLI (gh) を活用 する際も、このドメイン固有の設定は有効です。社内サーバー（例：https://git.company.com）で作業する場合、Git は直接接続します。すべてが完全に自動で行われます。
解決策2：SSH 接続の壁を突破する
多くの開発者は、トークンを手動で入力する手間を省くために SSH ([email protected]:...) を好んで使用します。また、セキュリティ向上のためにSSHキーでGitコミットに署名する設定を併用する場合も多いでしょう。ただし、上記の http.proxy 設定は SSH プロトコルには全く効果がないことに注意してください。
これを解決するには、~/.ssh/config にある SSH 設定ファイルを編集する必要があります。
Linux または macOS の場合 (nc – netcat を使用)
~/.ssh/config ファイルを開き、以下のコードを追加します：
Host github.com
HostName github.com
User git
# HTTP プロキシを使用する場合
ProxyCommand nc -X connect -x proxy-server:8080 %h %pWindows の場合 (connect.exe を使用)
Windows の Git Bash には強力な connect.exe ツールが付属しています。設定は以下のようになります：
Host github.com
HostName github.com
User git
ProxyCommand connect -H proxy-server:8080 %h %pプロキシでログインが必要な場合は、サーバーアドレスの前に情報を追加するだけです：connect -H user:pass@proxy-server:8080。
解決策3：環境変数（緊急時用）
プロジェクトを素早くクローンするために一度だけプロキシが必要な場合は、設定を変更する必要はありません。コマンドラインで直接環境変数を使用しましょう。
# Linux/macOS
HTTPS_PROXY=http://proxy-server:8080 git clone https://github.com/user/repo.git
# Windows (PowerShell)
$env:HTTPS_PROXY="http://proxy-server:8080"; git clone https://github.com/user/repo.gitこの方法は、一時的なサーバーでデバッグ中であり、設定の痕跡を残したくない場合に非常に便利です。
実践的な経験：NTLM プロキシ（Windows 認証）への対応
NTLM を使用している企業環境では、パスワードが正しくても Git がエラー 407 (Proxy Authentication Required) を返すことがよくあります。Git は元々、Windows 特有の認証プロトコルの処理が得意ではありません。
最適な解決策は Cntlm をインストールすることです。このツールは 127.0.0.1:3128 で動作する中間プロキシとして機能します。企業のプロキシとの複雑な「ハンドシェイク」を代行してくれます。この場合、Git をローカルに向けるだけで済みます：
git config --global http.proxy http://127.0.0.1:3128Cntlm は Git だけでなく、NPM、Docker、Pip ににとっての救世主となります。また、認証情報の管理には Git Credentialsを安全に管理する ツールを導入することで、セキュリティと利便性を両立できます。
設定の確認とクリーンアップ方法
ノート PC をカフェや自宅に持ち出すと、古いプロキシ設定のせいで Git がエラーになることがあります。以下のコマンドで実行中のルールを確認してください：
git config --global --get-regexp proxy完全に削除してデフォルトに戻したい場合：
# 特定のドメインのプロキシを削除
git config --global --unset http."https://github.com".proxy
# すべてのグローバルプロキシを削除
git config --global --unset http.proxyおわりに
プロキシ設定をマスターすることで、よりプロフェッショナルになり、無駄な時間を何時間も節約できます。複数のプラットフォームを併用する場合は、リポジトリを自動ミラーリングするなどの手法と組み合わせることで、さらに堅牢な開発環境を構築できます。接続トラブルが発生したときは、常に git config --list コマンドが頼もしい味方になることを忘れないでください。セットアップの成功を祈っています！
