http_proxy / https_proxy / no_proxy を「なんとなく設定」から卒業するための実務ガイド

企業ネットワークで Python、Git、Docker、npm、pip、curl、AWS CLI、社内 API、生成 AI 関連ツールなどを扱っていると、かなりの確率で遭遇するのが Proxy（プロキシ）設定 です。

そして現場では、こんな対応になりがちです。

export http_proxy=http://proxy.example.co.jp:8080
export https_proxy=http://proxy.example.co.jp:8080
export no_proxy=localhost,127.0.0.1

「とりあえずこれを入れたら通信できた」という状態でも業務は進みます。

しかし、

なぜ https_proxy なのに http://proxy... なのか
http_proxy と https_proxy は何を分けているのか
no_proxy は何を除外しているのか
OS のプロキシ設定とは何が違うのか
Docker だけ通信できないのはなぜか
curl は動くのに Python は動かないのはなぜか
localhost まで Proxy へ飛んでしまうのはなぜか

を理解していないと、企業ネットワーク特有のトラブルで毎回ハマることになります。

この記事では、http_proxy / https_proxy / no_proxy を中心に、「Proxy を設定する」の裏側で何が起きているのかを実務目線で整理します。

1. そもそも Proxy とは何か

Proxy は日本語では「代理」という意味です。

通常のインターネット通信は、以下のように直接通信します。

自分のPC
   │
   │ HTTPS
   ▼
api.github.com

しかし企業ネットワークでは、外部インターネットへの通信を Proxy サーバー経由にすることがあります。

自分のPC
   │
   ▼
社内Proxy
   │
   ▼
Internet
   │
   ▼
api.github.com

つまり、「クライアントの代わりに外部へアクセスする中継サーバー」が Proxy です。

企業で Proxy が使われる主な理由は以下の通りです。

外部通信の監視
アクセス制御
マルウェア対策
URL フィルタリング
認証
ログ取得
情報漏洩対策
インターネットアクセス経路の統一

そのため企業 PC では、「Internet へ直接通信」が禁止され、「Internet 通信は必ず Proxy を経由する」というネットワーク構成になっていることがあります。

2. http_proxy とは

http_proxy は、「HTTP 通信をするときに使用する Proxy」をアプリケーションへ伝える環境変数です。

例えば、以下のように設定します。

export http_proxy=http://proxy.example.co.jp:8080

その状態で、次のコマンドを実行します。

curl http://example.com

対応している curl などのクライアントは概念的には以下の経路で通信します。

curl
 │
 │ HTTP
 ▼
proxy.example.co.jp:8080
 │
 ▼
example.com

つまり http_proxy は、HTTP の宛先を指定しているのではなく、HTTP 通信を中継してもらう Proxy サーバーの場所を指定しています。

3. https_proxy とは

次が最も混乱しやすい部分です。企業環境ではよく以下のように設定します。

export https_proxy=http://proxy.example.co.jp:8080

ここで、「HTTPS なのになぜ https://proxy... ではなく http://proxy... なのか？」という疑問が出ます。

これは、https_proxy の https が「Proxy サーバー自身との通信方式」を意味しているわけではないからです。

正しくは、「HTTPS の宛先へ通信するときに利用する Proxy」という意味です。

つまり、https_proxy=[http://proxy.example.co.jp:8080](http://proxy.example.co.jp:8080) は、

「HTTPS 通信をするときは [http://proxy.example.co.jp:8080](http://proxy.example.co.jp:8080) という Proxy を利用してください」

という意味になります。ここは非常に重要です。

4. HTTPS 通信では CONNECT が使われる

HTTPS サイトへ HTTP Proxy 経由で接続するとき、多くの場合 HTTP CONNECT が使用されます。

例えば、[https://github.com](https://github.com) へアクセスしたいとします。クライアントはまず Proxy へ次のような要求を送ります。

CONNECT github.com:443 HTTP/1.1
Host: github.com:443

Proxy が許可すると、以下のレスポンスが返ります。

HTTP/1.1 200 Connection Established

その後、暗号化トンネルが確立されます。

Client
   │
   │ TLS
   │
Proxy
   │
   │ Tunnel
   ▼
github.com:443

概念的には以下の通りです。

Client
  │
  │ CONNECT github.com:443
  ▼
HTTP Proxy
  │
  │ TCP Tunnel
  ▼
github.com

そのトンネルの内部で TLS 通信が行われます。

そのため、https_proxy=[http://proxy.company.local:8080](http://proxy.company.local:8080) は全く不思議な設定ではありません。むしろ企業環境では非常によくあります。

5. no_proxy とは

no_proxy は、「Proxy を使用しない宛先」を指定する環境変数です。

例えば、次のように設定します。

export no_proxy=localhost,127.0.0.1

こうすると、localhost や 127.0.0.1 への通信では Proxy を利用しません。

これは開発環境ではかなり重要です。例えば FastAPI を起動し、ローカルにアクセスする場合を考えます。

uvicorn app.main:app --port 8000
curl http://localhost:8000

no_proxy が適切でないと、ツールによっては以下のような意味不明な経路を試みてしまいます。

自分のPC
   │
   ▼
社内Proxy
   │
   ▼
localhost:8000 ?

当然、社内 Proxy から見た localhost はあなたの PC ではありません。そのためローカルサービスへ接続できなくなります。

6. 開発環境では最低限これを除外する

典型的には、以下を入れておきます。

export no_proxy=localhost,127.0.0.1,::1

localhost
127.0.0.1
::1 (IPv6 localhost)

Docker や Kubernetes、ローカル AI、社内サービスを使う場合はさらに増やします。

# 社内ドメインを除外する場合
export no_proxy=localhost,127.0.0.1,::1,.company.local

# Docker Host を除外する場合
export no_proxy=localhost,127.0.0.1,::1,host.docker.internal

# Kubernetes環境の場合
NO_PROXY=localhost,127.0.0.1,::1,.svc,.cluster.local

7. no_proxy は意外と標準化されていない

ここは Proxy でハマる大きな原因です。

HTTP_PROXY / HTTPS_PROXY / NO_PROXY は広く使われていますが、全ツールが完全に同じ解釈をしているわけではありません。

例えば、以下の指定方法の扱いはツールによって異なります。

.example.com
example.com
*.example.com
10.0.0.0/8

特に、CIDR、ワイルドカード、サブドメイン、ポート付き指定は注意が必要です。

つまり、NO_PROXY=10.0.0.0/8 と書けばすべてのアプリが 10.x.x.x 全体を除外してくれるとは限りません。

したがって企業環境では、「no_proxy はアプリケーション依存の挙動がある」という前提で考える必要があります。

8. 大文字と小文字

Proxy 環境変数には、小文字（http_proxy）と大文字（HTTP_PROXY）が存在します。

Linux 系ツールでは両方を見るものも多いですが、挙動は完全には統一されていません。そのため実務では、両方定義されている環境もあります。

export http_proxy=http://proxy.example.com:8080
export https_proxy=http://proxy.example.com:8080
export no_proxy=localhost,127.0.0.1
export HTTP_PROXY=$http_proxy
export HTTPS_PROXY=$https_proxy
export NO_PROXY=$no_proxy

ただし、HTTP_PROXY には歴史的なセキュリティ上の注意点（CGI 脆弱性関連）もあり、curl など一部ツールでは意図的に扱いが異なります。

「何でも大文字・小文字両方入れれば絶対安全」と考えず、まずは対象ツールの仕様を確認しましょう。

9. 環境変数とは何をしているのか

export https_proxy=... を実行しても、OS の通信経路そのものが魔法のように変更されるわけではありません。

環境変数は、単に https_proxy = [http://proxy.example.com:8080](http://proxy.example.com:8080) という文字列をプロセスへ渡しているだけです。

Shell
 │
 ├─ https_proxy=...
 │
 ▼
curl

そして curl 側が「https_proxy があるからこの Proxy を使おう」と判断しています。

したがって、Proxy 環境変数を設定しても、その環境変数を参照しないアプリケーションには効きません。

これが以下の現象の原因になります。

curl は動くのに Python は動かない
Git は動くのに Docker は動かない
ブラウザは動くのに pip は動かない

10. OS Proxy と環境変数 Proxy は別物

Proxy には複数の設定レイヤーがあります。

Windows Proxy 設定
macOS Network Proxy
PAC
環境変数
Git config
npm config
pip config
Docker config
Java properties

これらは全部同じものではありません。

例えば、Windows の「設定 > ネットワークとインターネット > プロキシ」へ設定しても、Linux/WSL 内の curl が自動的にその設定を利用するとは限りません。

同様に、export https_proxy=... を設定しても Chrome が必ずそれを使うとは限りません。

Proxy 問題ではまず、「どのレイヤーに設定しているのか」を意識する必要があります。

11. Proxy 設定の全体像

実務では次のように考えると整理できます。

                  ┌──────────────────┐
                  │ OS Proxy / PAC   │
                  └──────────────────┘
                            │
Terminal
  │
  ├─ HTTP_PROXY
  ├─ HTTPS_PROXY
  └─ NO_PROXY
        │
        ▼
 ┌──────────────────────────┐
 │       Application        │
 ├──────────────────────────┤
 │ curl                     │
 │ Python requests/httpx    │
 │ pip                      │
 │ Git                      │
 │ npm                      │
 │ AWS CLI                  │
 │ Docker CLI               │
 └──────────────────────────┘
              │
              ▼
            Proxy
              │
              ▼
           Internet

しかし一部ツール（Git, npm, pip, Docker daemon など）は独自の独自設定を持っているため、話が複雑になります。

12. curl で確認する

Proxy トラブルでは curl が非常に便利です。まず詳細ログを有効にして実行します。

curl -v https://example.com

Proxy 経由なら、Uses proxy env variable https_proxy や CONNECT example.com:443 に相当するログが見えます。

これによって、DNS / Proxy 接続 / CONNECT / TLS / HTTP のどこで失敗しているのか切り分けられます。

13. Proxy を明示指定して試す

環境変数を疑う場合、-x オプションで Proxy を直接指定できます。

curl -x http://proxy.example.com:8080 https://example.com

直接 Proxy 指定で成功 & 環境変数で失敗 $\rightarrow$ 環境変数、シェル、no_proxy、ツール設定を疑う。

14. Proxy を使わず通信してみる

逆に --noproxy オプションで Proxy を無効化してテストできます。

# 全通信でProxyを無効化
curl --noproxy '*' https://example.com

# ローカル通信でProxyを無効化
curl --noproxy localhost http://localhost:8000

切り分けでは、「Proxy あり」と「Proxy なし」を比較することが非常に重要です。

15. Python の場合

Python では HTTP ライブラリによって挙動が異なります。例えば requests は一般的に Proxy 環境変数を利用できます。

import requests

response = requests.get("https://example.com")
print(response.status_code)

環境変数 HTTPS_PROXY があればそれを利用しますが、以下のようにコード上で明示指定も可能です。

import requests

proxies = {
    "http": "http://proxy.example.com:8080",
    "https": "http://proxy.example.com:8080",
}

requests.get("https://example.com", proxies=proxies)

ただし企業環境では、Proxy ＋社内 CA 証明書の問題が同時に出ることがあるため、「Proxy 接続エラー」と「TLS 証明書エラー」は分けて考える必要があります。

16. よくある企業環境の TLS Inspection

企業 Proxy では、HTTPS 通信を検査するため TLS Inspection が行われることがあります。

通常は Client ──(TLS)──> github.com ですが、TLS Inspection 環境では概念的に以下のようになります。

Client ──(TLS)──> Company Proxy ──(TLS)──> github.com

その場合、クライアントから見る証明書は GitHub 本来のものではなく、企業 Proxy が生成した証明書になります。

その企業 CA を Python、Node.js、Java、Docker などが信頼していないと、以下のエラーが発生します。

CERTIFICATE_VERIFY_FAILED
self signed certificate in certificate chain
unable to get local issuer certificate

これは Proxy 設定が間違っているのではなく、CA Trust Store（信頼された証明書ストア）の問題です。「Network Route」と「TLS Trust」は別問題として考えましょう。

17. 「SSL 検証を OFF にする」は基本的にやらない

証明書エラーが出ると verify=False や curl -k で回避したくなりますが、業務環境では原則おすすめしません。TLS 証明書を検証しないことになってしまうためです。

正しい対応は、「社内 Root CA を各環境（OS / Python / Node / Java / Container）の Trust Store へ登録すること」です。

18. Git の場合

Git は環境変数に加えて独自設定も可能です。

# 設定（HTTPSでも設定名は http.proxy）
git config --global http.proxy http://proxy.example.com:8080

# 確認
git config --global --get http.proxy

# 削除
git config --global --unset http.proxy

環境変数と Git config の両方に Proxy が存在しているケースもあるため、「設定した覚えがない Proxy を使っている」というときは複数レイヤーを疑いましょう。

19. pip の場合

pip も環境変数を利用します。pip install が失敗する場合は https_proxy や証明書設定を確認します。

明示的に指定する場合は以下のようにします。

pip install requests --proxy http://proxy.example.com:8080

ただし、毎回 CLI 引数に埋め込むよりは環境変数や設定ファイルで管理するのが一般的です。

20. npm の場合

npm は独自の Proxy 設定を持っています。

# 設定
npm config set proxy http://proxy.example.com:8080
npm config set https-proxy http://proxy.example.com:8080

# 確認
npm config get proxy
npm config get https-proxy

# 削除
npm config delete proxy
npm config delete https-proxy

Shell 環境変数、npm 設定、.npmrc が混在するとトラブルシューティングが難しくなります。

21. Docker ではさらに話が複雑になる

Docker では、以下の要素を分けて考える必要があります。

Docker CLI
Docker daemon
Container
Docker build

Host に export HTTPS_PROXY=... を設定していても、Container 内部に自動的に同じ環境変数が存在するとは限りません。

コンテナ実行時に環境変数を渡す場合は次のようにします。

docker run \
  -e HTTP_PROXY="$HTTP_PROXY" \
  -e HTTPS_PROXY="$HTTPS_PROXY" \
  -e NO_PROXY="$NO_PROXY" \
  my-image

22. Docker build 時の Proxy

Dockerfile 内の RUN apt-get update や RUN pip install が失敗する場合、docker build 時に引数として渡す必要があります。

docker build \
  --build-arg HTTP_PROXY="$HTTP_PROXY" \
  --build-arg HTTPS_PROXY="$HTTPS_PROXY" \
  --build-arg NO_PROXY="$NO_PROXY" \
  .

※ 認証情報を含む Proxy URL などを Dockerfile へ直接ハードコードするのは避けてください。

23. localhost は「その環境自身」を意味する

Docker や VM を扱う際の注意点です。

Host PC 上で FastAPI（:8000）を起動し、Docker Container 内から http://localhost:8000 へアクセスした場合、localhost は Host を指さず Container 自身を指します。

Host の localhost
Container の localhost
WSL の localhost
VM の localhost

これらは文脈によって別物です。Proxy 問題と localhost 問題が組み合わさると非常に分かりにくくなります。

24. WSL でも Proxy 設定は別と考える

Windows 側に Proxy 設定があっても、WSL（Ubuntu）側の curl、apt、pip などが同じ設定を自動利用するとは限りません。

Windows
 ├─ Windows Proxy
 │
 └─ WSL
     ├─ http_proxy
     ├─ https_proxy
     ├─ apt
     ├─ pip
     └─ Docker

このように切り離して捉えた方がトラブルシューティングしやすくなります。

25. 認証付き Proxy

企業 Proxy では認証が必要な場合があります。

http://username:password@proxy.example.com:8080

このような URL を直接 export HTTPS_PROXY=... に設定する場合、シェル履歴（history）、プロセス環境変数、CI ログ、設定ファイルから認証情報が漏洩する危険性があります。

リポジトリや Dockerfile、.env などに直接書かないようにし、可能であれば Credential Manager や OS 認証、専用の Proxy 認証機構を利用してください。

26. Proxy 設定は「どこに置くか」が重要

一時的な設定であれば、Terminal 上で export します。

export HTTP_PROXY=http://proxy.example.com:8080
export HTTPS_PROXY=http://proxy.example.com:8080
export NO_PROXY=localhost,127.0.0.1,::1

永続化する場合は ~/.zshrc や ~/.bashrc に記述します。

ただし、「VPN 接続時のみ必要」「社内 LAN のみ必要（自宅では不要）」という環境で常時設定しておくと、自宅で通信できなくなるなどのトラブル原因になります。

27. Proxy ON/OFF 関数を作ると便利

シェル関数を定義しておくと切り替えがスムーズになります。

# Proxyを有効化する関数
proxy_on() {
    export http_proxy="http://proxy.example.com:8080"
    export https_proxy="http://proxy.example.com:8080"
    export no_proxy="localhost,127.0.0.1,::1"
    export HTTP_PROXY="$http_proxy"
    export HTTPS_PROXY="$https_proxy"
    export NO_PROXY="$no_proxy"
}

# Proxyを無効化する関数
proxy_off() {
    unset http_proxy
    unset https_proxy
    unset no_proxy
    unset HTTP_PROXY
    unset HTTPS_PROXY
    unset NO_PROXY
}

※ 業務環境のセキュリティポリシーに従って利用してください。

28. 設定確認

現在の Proxy 環境変数を確認するコマンド：

env | grep -i proxy

個別に確認する場合：

echo $HTTP_PROXY
echo $HTTPS_PROXY
echo $NO_PROXY

29. 一番重要なトラブルシュート手順

通信できないときは、次の順番で切り分けます。

どこへ通信したいのか（[https://api.github.com](https://api.github.com) なのか http://localhost:8000 なのか）
外部か内部か（Proxy を経由すべきか、NO_PROXY に入れるべきか）
Proxy 環境変数を見る (env | grep -i proxy)
curl で確認 (curl -v [https://example.com](https://example.com))
Proxy 明示指定 (curl -v -x [http://proxy.example.com:8080](http://proxy.example.com:8080) [https://example.com](https://example.com))
Proxy なしで確認 (curl --noproxy '*' [https://example.com](https://example.com))
DNS の確認 (nslookup example.com や dig example.com)
TLS の確認 (certificate verify failed なら CA / TLS Inspection を疑う)
アプリ固有設定を見る (Git, npm, pip, Docker, AWS CLI など)

30. Proxy 障害を OSI 的に分解すると理解しやすい

エラーメッセージごとにレイヤーを特定しましょう。

DNS ──> TCP ──> Proxy接続 ──> Proxy認証 ──> CONNECT ──> TLS ──> HTTP ──> Application

エラーの例	原因の推測
`Could not resolve host`	DNS
`Connection refused`	TCP / Proxy endpoint
`407 Proxy Authentication Required`	Proxy 認証
`CONNECT tunnel failed`	Proxy policy / CONNECT
`CERTIFICATE_VERIFY_FAILED`	TLS / CA
`403 Forbidden`	Proxy または Server policy
`Timeout`	Routing / Firewall / Proxy / Server

31. 407 Proxy Authentication Required

407 は通信先の Web サーバーではなく、Proxy サーバー自体が「認証してください」と返している状態です。

401 Unauthorized $\rightarrow$ Web サーバーによる認証要求
407 Proxy Authentication Required $\rightarrow$ Proxy サーバーによる認証要求

32. 403 は少し判断が難しい

403 Forbidden の場合、Proxy 側がブロックしているケースと、アクセス先の Web サーバーが拒否しているケースの 2 パターンがあります。

curl -v でレスポンスヘッダーを確認し、どちらが 403 を返しているのか特定します。

33. PAC とは何か

企業ネットワークでは PAC (Proxy Auto Configuration) が使われることがあります。

PAC ファイルには以下のような JavaScript ルールが書かれています。

function FindProxyForURL(url, host) {
    if (dnsDomainIs(host, ".company.local")) {
        return "DIRECT";
    }
    return "PROXY proxy.company.com:8080";
}

ブラウザは PAC に対応していても、curl、Python、npm、pip、Docker などは PAC を直接解釈してくれません。これが「ブラウザでは開けるのに CLI では通信できない」原因になります。

34. AI 開発では Proxy 問題が特に増える

AI フルスタック開発では通信先が多岐にわたります（GitHub, PyPI, npm, Docker Hub, Hugging Face, OpenAI API, AWS Bedrock, Anthropic, Supabase など）。

さらに Python、Node.js、Docker、WSL、VS Code、CLI、Browser と実行環境が跨がるため、単に「Proxy サーバーを 1 つ設定した」だけでは完結しません。

どのプロセスが、どの設定を見て、どこへ通信しているのかを整理することが不可欠です。

35. Proxy を理解するときの基本モデル

                     ┌────────────────┐
                     │ Destination    │
                     │ GitHub / PyPI  │
                     └───────▲────────┘
                             │
                             │
                    ┌────────┴────────┐
                    │                 │
              Proxy経由             Direct
                    │                 │
                    ▲                 ▲
                    │                 │
          HTTP_PROXY /           NO_PROXY
          HTTPS_PROXY
                    ▲
                    │
               Application
      curl / Python / Git / npm
       Docker / AWS CLI / etc
                    ▲
                    │
               Environment

思考のステップ：

Destination はどこか
Proxy が必要か
NO_PROXY 対象か
Application はどの設定を見るか
TLS/CA は正常か

36. 実務用チートシート

# 通常の企業Proxy設定
export http_proxy=http://proxy.example.com:8080
export https_proxy=http://proxy.example.com:8080
export no_proxy=localhost,127.0.0.1,::1

# 確認
env | grep -i proxy

# Proxy経由確認
curl -v https://example.com

# Proxy明示指定
curl -x http://proxy.example.com:8080 https://example.com

# Proxy無効化確認
curl --noproxy '*' https://example.com

# 環境変数削除
unset http_proxy https_proxy no_proxy HTTP_PROXY HTTPS_PROXY NO_PROXY

# Git / npm 設定確認
git config --global --get http.proxy
npm config get proxy
npm config get https-proxy

37. 最低限ここだけ覚える

http_proxy : HTTP 通信で利用する Proxy
https_proxy : HTTPS 通信で利用する Proxy
no_proxy : Proxy を利用しない宛先

https_proxy=[http://proxy.example.com:8080](http://proxy.example.com:8080) は一見矛盾しているようで正解です。「HTTPS サイトへ接続するときに HTTP Proxy を利用する」という意味だからです。

38. Proxy トラブル時の思考法

最も重要なのは、「Proxy を設定する」という 1 つの問題としてまとめないことです。

Network
DNS
Proxy routing
Authentication
CONNECT
TLS
CA Trust
Application config

通信できない場合は、上記のどのレイヤーで失敗しているのかを順番に切り分けます。

まとめ

Proxy 環境変数は単なる「おまじない」ではありません。

               Internet
                  ▲
                  │
              HTTP Proxy
                  ▲
                  │
       HTTP_PROXY / HTTPS_PROXY
                  ▲
                  │
             Application
                  │
                  ├── Git
                  ├── curl
                  ├── Python
                  ├── npm
                  ├── Docker
                  └── CLI

NO_PROXY ──> localhost / 社内API / Docker / Kubernetes など（Proxyを通さない）

トラブル時には以下の順で確認を行います。

$$\text{Destination} \rightarrow \text{Proxy / Direct} \rightarrow \text{環境変数} \rightarrow \text{App固有設定} \rightarrow \text{Proxy認証} \rightarrow \text{TLS / CA}$$

これができるようになると、「コピペして祈る」状態から卒業し、「CONNECT は成功しているが TLS Trust で落ちているため CA 側を確認する」といった正確なトラブルシューティングが可能になります。