GitのHTTP/HTTPSとSSHを分け、安全にproxy経路を切り分けます。以下の旧コード9個は履歴保存のため残しており、危険・不正確な指定を含みます。各直前の訂正を先に読み、通常は追加の一回限りの例を使ってください。

この記事の要点

基本: HTTP/HTTPSのGit URLは共通のhttp.proxy。まず非永続のgit -cで確認し、秘密値をURLへ保存しない HTTPS用: 接続先URL別にhttp.<URL>.proxyを照合。https.proxyを別途設定する説明は誤り URL 別: http.<URL>.proxy で特定ホストだけプロキシ経由 / 直結を切替 SSH のプロキシ: ~/.ssh/config の ProxyCommand または ProxyJump 企業認証はGit/libcurlの対応と組織ポリシーを確認。解除も元の設定スコープ・キーを限定する

Git プロキシ設定の全体像

社内ネットワークやファイアウォール環境で GitHub / GitLab / 自社 Git サーバへ接続する場合、HTTP/HTTPS プロキシ経由のアクセスが必要になります。Git は http.proxy という設定キーでプロキシを指定できます。通常の読込み順はsystem → global → local → worktree → commandで、同じキーの単一値では後の値が優先します。worktree設定はextensions.worktreeConfig有効時、commandにはgit -cやGIT_CONFIG_COUNT系も含まれます。include / includeIfは挿入位置で読み込まれ、globalにはXDG側のファイルもあります。次の3行の表は全範囲を網羅していません。

スコープ	コマンド	保存先
システム	git config --system http.proxy ...	/etc/gitconfig
ユーザ（全体に影響）	git config --global http.proxy ...	~/.gitconfig
リポジトリ	git config http.proxy ...	.git/config

基本設定: http.proxy（HTTPSにも使用）

まず追加の非永続例を示します。管理者が許可した接続先に置き換えて使うPOSIXシェル例です。-cはそのGit呼出しだけで、既存URL別設定・remote別設定・NO_PROXY等も確認します。実在サービスにはこの検証では接続していません。2つ目は確認済み組織CAが必要な場合だけ使い、CAファイルも管理下のものに読み替えます。

# POSIX shell; replace both reserved .test names with approved endpoints.
# No persistent config writes and no credentials in the URL.
git -c http.proxy=http://proxy.example.test:8080 ls-remote https://git.example.test/team/repo.git
# HTTPS destination uses the SAME http.proxy key; http:// describes the proxy.
# Confirmed organization CA, only when required (never sslVerify=false):
git -c http.proxy=http://proxy.example.test:8080 -c http.sslCAInfo=/approved/company-ca.pem ls-remote https://git.example.test/team/repo.git

訂正・安全上の注意（旧例）: 基本設定の旧コードは実行しないでください。GitのHTTPSにもhttp.proxyを使います。https.proxyはGitのHTTP転送用の設定キーではありません。Git configは未知のキーも保存・表示できるため、--getで値が出ても利用される証拠にはなりません。URLへのuser:password埋込みと--globalによる永続保存も推奨しません。下の旧コード内の一覧表示は秘密値を露出し得ます。

# HTTP / HTTPS 両方にプロキシを設定
git config --global http.proxy http://proxy.example.com:8080
git config --global https.proxy http://proxy.example.com:8080

# 認証付きプロキシ（ユーザ名・パスワード埋め込み）
git config --global http.proxy http://user:password@proxy.example.com:8080

# HTTPS のみ別プロキシを使う
git config --global https.proxy http://secure-proxy.example.com:8443

# 現在の設定を確認
git config --global --get http.proxy
git config --global --get https.proxy

# 全プロキシ設定を一覧
git config --global --list | grep -i proxy

正しい使い分け: Gitのhttp.proxyはHTTPとHTTPS両方に作用します。値のhttp://はクライアントからproxyへのプロトコルで、接続先がHTTPSでもHTTP proxyの指定はhttp://です。HTTPS接続先へは通常CONNECTでトンネルを作り、その中でTLSを行います。値をhttps://にするのはproxy自体がTLSに対応する場合で、8443番というだけでは判断できません。

URL 別プロキシ設定

「社内 Git サーバには直結したいが GitHub にはプロキシ経由」のように接続先で振り分けたい場合は http.<URL>.proxy を使います:

訂正・安全上の注意（旧例）: 次は永続設定を変更する旧例です。空文字はそのURLに対して環境変数由来のproxyも抑止するので、組織で直通が許可された場合だけ選びます。URLはscheme・host・port・path等で照合され、パスの長い一致等も優先されます。ホストワイルドカードは1階層で、任意の多段サブドメイン一致ではありません。クォートはシェルに合わせて確認してください。

# GitHub だけプロキシ経由
git config --global http.https://github.com.proxy http://proxy.example.com:8080

# 社内 GitLab は直結（空文字でプロキシを無効化）
git config --global http.https://gitlab.internal.example.com.proxy ""

# 特定ホストパターン
git config --global http.https://*.googleusercontent.com.proxy http://proxy.example.com:8080

# 削除
git config --global --unset http.https://github.com.proxy

パスワード文字列のエスケープ

パスワードに @ や : や # などの記号が含まれると URL パーサが誤動作します。パーセントエンコーディングが必要です:

文字	エスケープ後	意味
@	%40	ユーザ・ホスト区切りと衝突
:	%3A	ユーザ・パスワード区切りと衝突
/	%2F	パス開始と衝突
#	%23	フラグメント開始と衝突
半角空白	%20	URL に空白を含めない

訂正・安全上の注意（旧例）: 次の埋込みパスワード例は保存用の負例で、実行しないでください。パーセントエンコードは暗号化ではなく、config・履歴・プロセス引数等から復元可能です。実パスワードやハッシュをコマンド・URL・チケットへ記載しません。

# 例: パスワード "P@ss:w0rd!"
git config --global http.proxy http://user:P%40ss%3Aw0rd%21@proxy.example.com:8080

環境変数による設定

GitのHTTP転送はlibcurlのproxy環境変数を利用できます。Gitのhttp.proxyは環境変数によるproxy指定を上書きし、remote.<name>.proxyによる個別指定もあります。設定と環境変数を分けて確認してください。永続シェル設定へ無条件に追記しません。

訂正・安全上の注意（旧例）: 次はシェル全体を変更する旧例です。POSIX上のlibcurlはHTTP用には小文字http_proxyだけを読み、HTTP_PROXYだけでは効きません。HTTPSはhttps_proxy / HTTPS_PROXY、全体の補完はall_proxy / ALL_PROXYです。小文字優先やNO_PROXY / no_proxyの除外を確認します。Windowsは環境変数名の大文字小文字の扱いが異なります。他ツールも全て同じ挙動とは限りません。

# ~/.bashrc / ~/.zshrc / /etc/profile.d/proxy.sh など
export HTTP_PROXY=http://proxy.example.com:8080
export HTTPS_PROXY=http://proxy.example.com:8080
export NO_PROXY=localhost,127.0.0.1,.internal.example.com

# 小文字版も両方書いておくと無難
export http_proxy=$HTTP_PROXY
export https_proxy=$HTTPS_PROXY
export no_proxy=$NO_PROXY

# Windows (PowerShell) では
# $env:HTTPS_PROXY = "http://proxy.example.com:8080"

NO_PROXY / no_proxyはproxyを使わない接続先の指定です。ホスト名・ドメイン・IPの照合はlibcurlの版も確認し、必須proxyの無断迂回には使いません。設定に値があることと、実通信でproxyが使われることは別です。

SSH 接続をプロキシ経由にする

Git の SSH (git@github.com:user/repo.git) は http.proxy の影響を受けません。SSH の ProxyCommand / ProxyJump を使います:

訂正・安全上の注意（旧例）: 次は異なる方式を同じHost名で並べた旧例であり、このままコピーしません。nc -X connect -xはOpenBSD版ncの構文です。GNU netcatやNmap Ncatを同一視しません。導入済み実装のヘルプを確認してください。ProxyCommandはHTTP CONNECT等を行う外部コマンド、ProxyJumpはSSH踏み台であり、HTTP proxyの代わりではありません。同じHostの設定は最初に得た値が使われ、ProxyJumpとProxyCommandも競合します。corkscrewの認証ファイルも秘密情報です。

# ~/.ssh/config
Host github.com
    HostName github.com
    User git
    # nc / ncat を使った HTTP CONNECT 中継（GNU netcat 推奨）
    ProxyCommand nc -X connect -x proxy.example.com:8080 %h %p

# corkscrew を使う場合
Host github.com
    ProxyCommand corkscrew proxy.example.com 8080 %h %p ~/.ssh/proxy_auth

# 多段 SSH（踏み台経由）
Host github.com
    ProxyJump bastion.example.com

GitHub.comのSSHはssh.github.com:443も利用できますが、通信はSSHのままです。443番が開いていても、組織のproxyやプロトコル制限を通れる保証はありません。

訂正・安全上の注意（旧例）: 次の443番の旧例はSSHの接続先変更だけです。SSHはHTTPSに変換されず、HTTP CONNECTも自動実行されません。明示proxyが必須なら許可されたCONNECT経路を別途構成し、proxyがSSHのトンネルを許可するか管理者へ確認します。GitHubの案内はssh.github.com:443用で、Enterprise Serverやデータ所在地指定Cloudには適用できません。ホスト鍵は公式の指紋と照合し、検証を無効化しません。

# ~/.ssh/config
Host github.com
    HostName ssh.github.com
    Port 443
    User git

# 接続テスト
# ssh -T git@github.com
# → Hi <user>! You've successfully authenticated...

NTLM 認証（Active Directory プロキシ）対策

企業proxyが返す407とProxy-Authenticateを管理者と確認します。Basic / NTLM / Negotiateなどの選択はproxyの世代だけで判断できません。http.proxyAuthMethodはユーザー名を含むproxy指定で作用します。Gitはproxy URLにユーザー名だけを指定すると通常のcredential処理でパスワードの取得を試みますが、helperの種類・実行環境によっては対話不可や平文保存もあるので安全性を確認します。サーバー用資格情報とproxy用を混同しません。

訂正・安全上の注意（旧例）: 次のcntlm導入・起動・global設定は歴史的な選択肢で、実行を推奨する手順ではありません。Gitにはhttp.proxyAuthMethodのntlm / negotiate等があり、対応はリンク先libcurlのビルド、資格情報、管理ポリシーに依存します。cntlmが必須ともSSO成功とも断定できません。導入・サービス起動・Listen範囲の変更は管理者の承認が必要で、PassNTLMv2も秘密として保護します。https.proxy行は不要です。

# Ubuntu
sudo apt install cntlm

# /etc/cntlm.conf 設定例
# Username  yourname
# Domain    EXAMPLE
# PassNTLMv2  <生成したハッシュ>
# Proxy     proxy.example.com:8080
# Listen    3128

# パスワードハッシュ生成
cntlm -H

# 起動
sudo systemctl start cntlm

# Git からは cntlm（ローカル 3128）を見る
git config --global http.proxy http://127.0.0.1:3128
git config --global https.proxy http://127.0.0.1:3128

SSL 証明書まわり

SSL 終端プロキシ（社内プロキシが中間者として独自 CA 証明書を発行）の環境では、自社 CA 証明書を Git に渡す必要があります:

訂正・安全上の注意（旧例）: 次のsslVerify false付き旧コードは実行しないでください。開発でも通常の解決策ではなく、相手の検証を失います。管理者から確認済みCAを受領し検証を有効のまま使います。sslCAPathは適切なハッシュ付きCAディレクトリを要し、任意のディレクトリ指定では代用できません。Schannel等ではCAストアとsslCAInfoの扱いが異なります。HTTPS proxyへのTLSはproxySSLCAInfo等、接続先へのTLSはsslCAInfo等で別々に扱います。

# 自社 CA を Git に教える
git config --global http.sslCAInfo /etc/ssl/certs/company-ca-bundle.pem

# OS の CA バンドルを使う
git config --global http.sslCAPath /etc/ssl/certs

# やむを得ず検証をスキップ（非推奨）
git config --global http.sslVerify false

# 特定ホストだけ検証スキップ
git config --global http.https://internal-git.example.com.sslVerify false

プロキシ解除と確認

まずローカル画面だけで出所とURL別値を確認します。出力には秘密値やユーザー名・パスが含まれ得るので転記せず、共有が必要なら値を伏せます。--get-urlmatchは設定照合であり、通信成功やNO_PROXY込みの最終経路を証明しません。

# Read locally only: values/origins may contain secrets. Do not paste output.
git config --includes --show-origin --show-scope --get-all http.proxy
git config --includes --get-urlmatch http.proxy https://git.example.test/team/repo.git
# URL-specific settings and remote.<name>.proxy can change the effective route.

訂正・安全上の注意（旧例）: 次は一括解除と秘密値のログ出力を含む旧例で、まとめて実行しないでください。--globalだけを消してもsystem/local/worktree/command、include、URL別、remote別や環境変数の設定は残り得ます。--unset-allは同じキーの複数値を失います。変更前に対象ファイル・キー・値を非公開で記録し、自分が追加した1件だけを元のスコープで戻します。envや--listの結果を貼らず、認証情報入りログを共有しません。

# 解除
git config --global --unset http.proxy
git config --global --unset https.proxy

# 全プロキシ系設定を削除
git config --global --unset-all http.proxy
git config --global --unset-all https.proxy

# 確認: もう設定されていないこと
git config --global --get http.proxy   # → 何も表示されない
git config --global --list | grep -i proxy

# それでもうまくいかないときは環境変数を疑う
env | grep -i proxy
unset HTTP_PROXY HTTPS_PROXY http_proxy https_proxy

トラブルシューティング

表の症状だけで原因を断定しない: 名前解決エラーは接続先・proxyのどちらの名前かを区別し、hosts編集で決め打ちしません。TCP接続失敗はDNS・許可・ポートも確認します。407はproxyの認証要求や方式不一致もあり、即パスワード再設定しません。CAエラーは中間証明書や信頼ストアの不備も候補です。Empty replyだけでCONNECT拒否とは特定できず、proxyの実記録やHTTP応答と照合します。ログは資格情報等を除去してから扱います。下表の原因欄は候補の一例です。

症状	原因	対処
Could not resolve host: github.com	接続先名の解決に失敗。直通/proxyの実経路を区別	URL・proxy/NO_PROXY・DNSを確認し、hostsを決め打ち変更しない
Failed to connect to proxy.example.com port 8080	proxyの名前・待受先・経路・接続許可などが候補	許可された宛先/ポートとHTTP応答を確認。pingの成否だけで判断しない
error: RPC failed; HTTP 407	proxyが認証を要求。資格情報不足や方式不一致などを確認	承認された認証方式・取得先・Git/libcurl対応を確認。即座に再設定しない
SSL certificate problem: unable to get local issuer certificate	CAへの信頼・中間証明書チェーン等が候補	http.sslCAInfo
fatal: unable to access ... Empty reply from server	応答前の切断。proxy/接続先のどちらが原因かは未確定	プロキシ管理者に確認

FAQ

Q: パスワードを平文で書きたくない
A: 組織が承認したcredential helperの保存方式を確認します。全helperがキーチェーンではなく、storeは平文です。ファイル権限600だけでURL中のパスワード保存が安全になるわけではありません。cntlmを必須の解決策にしません。

Q: 在宅勤務時にプロキシ無し、出社時にプロキシ有り、を自動切替したい
A: includeIfのgitdirはリポジトリの場所に応じた切替で、現在の社内LAN・VPNを検出しません。direnvも基本はディレクトリ単位です。PAC/WPADをGitが自動解釈するとも限りません。ネットワーク判定は承認済みの仕組みで別途行い、既存のglobal値を上書きする汎用スクリプトは避けます。

Q: GitHub Desktop / VS Code の Git 連携にも反映される？
A: アプリが使うGit実行ファイル、HOME/XDG、継承環境と設定スコープ次第です。CLIでの成功だけでDesktopやIDEの通信も同じ経路と断定できません。アプリ本体のHTTP設定とGitのhttp.proxyも別に確認します。

公式資料と検証範囲（2026年10月26日）

Git公式: 設定スコープ・URL照合・proxy認証・TLS、Git公式: 資格情報処理、curl公式: proxy環境変数、libcurl公式: proxy URLと空文字、OpenSSH: ProxyCommand / ProxyJump、OpenBSD: nc構文、GitHub公式: SSHの443番を照合しました。

Git 2.47.3とcurl 8.14.1の隔離Linuxで、設定読取り・URL照合、HTTP要求とHTTPSのCONNECTを記録するloopback proxyを検査しました。ダミーCAのみを使い、TLS検証停止・実資格情報・外部サービス・本番設定変更は行っていません。HTTP_PROXYの大文字小文字、環境変数の除外、空proxyによる直通、未知のhttps.proxyが設定に見えても通信に作用しない差も検査対象です。実NTLM / Kerberos / SSO / cntlm、SSH接続・ホスト鍵、HTTPS proxy自体のTLS、Windows / IDE / 他TLSバックエンドは未検証です。