In this Article
企業ネットワーク内からGitHubを利用する際は、設定を共有しない5つのツールにまたがる構成上の問題になることがほとんどです。cloneはできるのにnpm installが失敗する、npmは動くのにDockerがpullできない、コマンドラインではすべて動くのにIDEは何にも接続できない、といったことが起こります。
このガイドでは、各ツールがどこからプロキシ設定を読み込むか、SSHがHTTPSとは異なる振る舞いをする理由、実際に表示される4種類のエラーの読み方、そして避けるべき2つの近道を取り上げます。
重要ポイント
- ツールごとに独自のプロキシ設定があります。Git、npm、pip、Docker、シェルはそれぞれ異なる設定を読み込むため、1つを直しても他が動かないことがあります。
- HTTPSが使えてもSSHは通常失敗します。多くの企業プロキシは、標準ポート上のHTTP CONNECTしか転送しないためです。
- 証明書エラーはほぼ常にTLSインスペクションを意味します。検証を無効化するのではなく、企業CAを信頼することが解決策です。
- cloneを成功させるために証明書検証を無効化してはいけません。目に見える設定問題が、目に見えないセキュリティ問題へと変わります。
- プロキシURL内の認証情報はログとシェル履歴に漏れます。代わりにツールの認証情報ストアを使用してください。
各ツールはプロキシ設定をどこから読み込みますか？
それぞれ別個です。これが混乱の大半の原因です。これを4部構成のツールチェーンモデルと呼びます。
| ツール | 参照先 | よくある不足 |
|---|---|---|
| 1. Git | 独自の設定、次に環境変数 | HTTPSリモートは動作するがSSHリモートは動作しない |
| 2. パッケージマネージャー | 独自の設定ファイル、次に環境変数 | 個別の設定が必要で、レジストリはGitHubと異なる場合がある |
| 3. Docker | シェルだけでなくデーモンの設定 | シェル変数はイメージをpullするデーモンに届かない |
| 4. IDEとエディター | 独自の設定、場合によってはシステムストア | ターミナルは動作するが統合機能は動作しない |
したがって、動作するgithub proxy設定とは、1つではなく5つの設定を意味します。実践的な順序は、シェル用の環境変数を設定し、次にgit、各パッケージマネージャー、Dockerデーモンを設定し、最初から内部ホスト用のno-proxyリストを含めることです。最後の手順を省くと、ほかは正常に設定できていても内部サービスに到達できなくなります。
HTTPSが動くのにSSHが失敗するのはなぜですか？
別々のポートを使う異なるプロトコルであり、多くの企業プロキシは少数のポートへのHTTP CONNECTしか転送しないためです。
HTTPS経由のGitは、プロキシがネイティブに扱える通常のWebリクエストです。SSH経由のGitはポート22を使用しますが、通常はプロキシ経由でまったく許可されません。その結果、HTTPSリモートではリポジトリを問題なくcloneできるのに、SSHリモートではタイムアウトします。エラーメッセージに理由が示されることはほとんどありません。
実用的な解決策は、推奨順に、トークンを使ってリモートをHTTPSへ切り替える、GitHubが対応している場合はHTTPSポート経由でSSHを使う、ネットワークチームに特定ホストへのSSHを許可してもらう、の3つです。最初の方法はどこでも機能し、ほとんどのチームが最終的に選択します。
エラーはどう読み解けばよいですか？
| エラー | この対処を使う場面 | 避ける場面 |
|---|---|---|
| Certificate verification failed | ツールの信頼ストアに企業CAを追加する | 実際のリスクを隠すため、検証を無効化しない |
| SSHリモートで接続がタイムアウトする | HTTPSに切り替えるか、HTTPSポート経由でSSHを使う | 再試行。ポートは遅いのではなくブロックされている |
| プロキシ認証が必要 | ツールのストアに認証情報を設定する | ログに漏れるURL内への記載 |
| ターミナルでは動作するがDockerで失敗する | Dockerデーモンを設定し、再起動する | デーモンが決して読まないシェル変数を追加する |
| 設定後に内部ホストへ到達できない | no-proxyリストに追加する | プロキシ設定を完全に削除する |
特に断固として扱うべきなのは最初の行です。TLSインスペクションは、中間装置が接続を終端し再署名していることを意味します。正しい対応は、組織のCAを意図して信頼することです。検証を無効化すればエラーは消えますが、将来のあらゆる傍受が見えなくなります。
外部プロキシが適切なツールとなるのはいつですか？
この問題に対しては、めったにありません。その点は明確にしておく価値があります。
企業プロキシは組織が運用するインフラであり、その背後でGitHubへアクセスするための解決策は、2つ目のプロキシではなく設定です。雇用主が意図して導入したネットワーク制御を迂回することは、技術的な問題である前にポリシー上の問題です。
商用プロキシが本当に適用されるのは、GitHubに関係する別の作業です。たとえば公開リポジトリのデータを大規模に収集する、公開ページが他国でどのように表示されるか確認する、複数地域から自動チェックを実行するといった作業です。とりわけリポジトリデータの収集では、まずトークン付きのGitHub APIが適切な答えであり、その制限は十分に寛大なので、スクレイピングが正当化されることはめったにありません。
収集に分散した出口IPが必要な場合、DataImpulse residentialは195か国を$1 per GBでカバーしています。関連: Webスクレイピング向けプロキシ、403 Forbiddenの解説。
よくある質問
gitでプロキシを使うように設定するにはどうすればよいですか？
git独自の設定または標準の環境変数でプロキシを設定し、同時に内部ホストをno-proxyリストへ追加します。Gitはnpm、pip、Dockerとは別に独自の設定を読み込むため、各ツールを個別に設定する必要があります。
プロキシの背後でSSH経由のgit cloneが失敗するのはなぜですか？
SSHはポート22を使用し、多くの企業プロキシは標準WebポートへのHTTP CONNECTしか転送しないためです。HTTPSリモートは通常のWebリクエストなので動作します。トークンを使ってリモートをHTTPSへ切り替える方法は、最も多くの環境で機能する解決策です。
企業プロキシの背後で証明書エラーが起きる原因は何ですか？
TLSインスペクションです。中間装置が組織独自の認証局証明書で接続を終端し再署名します。解決策は、そのCAを各ツールの信頼ストアへ追加することです。証明書検証を無効化すればエラーは消えますが、実際の傍受を検出する能力も失われます。
ターミナルが動くのにDockerが失敗するのはなぜですか？
イメージをpullするのはシェルではなくDockerデーモンであり、デーモンは環境変数ではなく独自の設定を読み込むためです。デーモンのプロキシ設定を構成し、再起動してください。
職場でGitHubに接続するために商用プロキシを使うべきですか？
いいえ。企業プロキシは組織が意図して運用するインフラであり、解決策は設定です。商用プロキシは、多くの地域から公開データを収集するような別の作業に適用されます。その場合でも、通常はトークン付きのGitHub APIのほうが適切な手段です。
作業が接続性ではなく収集の場合
公開ページが他の地域でどう表示されるかを確認することや、公開データを大規模に収集することは、企業ネットワーク設定とは別の問題です。DataImpulse residential proxiesは195か国を$1 per GBでカバーしています。それが目的ならアカウントを作成してください。
関連: Webスクレイピング向けプロキシ · スクレイピング時の403 Forbidden · Webプロキシとは。
最終更新: 2026年9月17日。