curl proxy 設定入門：環境変数とオプション

By /

curl プロキシ設定入門：環境変数とオプションの詳細な説明

はじめに

インターネット上のリソースを取得したり、APIと連携したりする際に広く利用されるコマンドラインツール、curl。その多機能性の中でも、特に重要な設定の一つが「プロキシ」の利用です。プロキシは、セキュリティ、プライバシー保護、アクセス制限の回避、キャッシングによるパフォーマンス向上など、様々な目的で使用されます。

しかし、curlでプロキシを設定する方法はいくつか存在し、それぞれの特徴や優先順位を理解していないと、意図しない挙動になったり、設定が反映されなかったりすることがあります。curlでプロキシを設定する主な方法は、環境変数を使用する方法と、コマンドラインオプションを使用する方法の二つです。

この記事では、curlにおけるプロキシ設定について、これら二つの方法を中心に、その基本的な仕組みから詳細な設定方法、さらには高度な使い方やトラブルシューティングまでを網羅的に解説します。約5000語に及ぶこの詳細なガイドを通して、あなたのcurlとプロキシに関する知識を深め、より効果的にツールを使いこなせるようになることを目指します。

プロキシの基本

curlでのプロキシ設定方法に入る前に、まずはプロキシそのものについて簡単に理解しておきましょう。

プロキシとは？

プロキシ（Proxy Server）は、「代理」という意味の通り、クライアント（あなたのコンピューターやcurlコマンド）とインターネット上のサーバーの間で通信を仲介するサーバーです。クライアントからのリクエストは一度プロキシサーバーを経由し、プロキシサーバーが代理として目的のサーバーにリクエストを送信します。目的のサーバーからの応答も、プロキシサーバーを経由してクライアントに戻されます。

なぜプロキシを使うのか？

プロキシを利用する理由は多岐にわたります。

  • セキュリティの向上: 企業ネットワーク内でのアクセス制御やフィルタリング、マルウェア対策などを行います。クライアントのIPアドレスを隠蔽することにもつながります。
  • プライバシー保護: クライアントの本来のIPアドレスを隠し、匿名性を高めます。
  • アクセス制限の回避: 特定の地域からしかアクセスできないサービスに、その地域に設置されたプロキシを経由してアクセスするといった使い方が可能です。（ただし、サービスの利用規約に違反しない範囲で使用することが重要です。）
  • キャッシング: 一度アクセスしたコンテンツをプロキシサーバーに一時保存（キャッシュ）しておき、次に同じリクエストがあった際にプロキシサーバーから直接応答を返すことで、通信速度を向上させたり、帯域幅を節約したりします。
  • モニタリングとログ: 社内ネットワークにおける通信内容を監視・記録するために使用されます。

プロキシの種類

プロキシにはいくつかの種類があり、それぞれ対応するプロトコルや機能が異なります。curlが主に対応しているのは以下のタイプです。

  • HTTPプロキシ: HTTPおよびHTTPS（CONNECTメソッドを使用）の通信を仲介します。最も一般的なプロキシタイプです。通常、特定のポート（例: 8080, 3128, 80）で待ち受けます。
  • SOCKSプロキシ: HTTPだけでなく、TCP/IPベースのあらゆるプロトコル（FTP, SMTP, P2Pなど）の通信を仲介できます。HTTPプロキシよりも汎用性が高いですが、HTTP固有の機能（キャッシングやヘッダー書き換えなど）は持ちません。SOCKS4、SOCKS5などのバージョンがあります。SOCKS5は認証やUDP通信にも対応しています。

プロキシサーバーのアドレスとポート

プロキシサーバーを指定するには、そのサーバーのホスト名またはIPアドレスと、待ち受けポート番号が必要です。例えば、proxy.example.com というホスト名でポート番号 8080 で動作しているHTTPプロキシは proxy.example.com:8080 のように指定します。

プロキシ認証

多くのプロキシサーバーは、不正利用を防ぐために認証を要求します。認証方式にはBasic認証、Digest認証、NTLM認証などがあり、curlはこれらに対応しています。認証が必要なプロキシを使用する場合、ユーザー名とパスワードをcurlに伝える必要があります。

curlでのプロキシ設定方法 – 環境変数

curlでプロキシを設定する最も手軽な方法の一つは、環境変数を使用することです。環境変数は、オペレーティングシステムやシェルによって管理される変数で、実行されるプログラムに様々な設定情報を渡すために使われます。

環境変数を使うメリット・デメリット

メリット:

  • 設定の簡易性: 一度環境変数を設定すれば、そのシェルセッション内で実行されるcurlコマンド（および多くのHTTPクライアント）は自動的にそのプロキシ設定を使用します。毎回コマンドラインオプションを指定する必要がありません。
  • システム全体の統一: 環境変数に対応している他のツールやアプリケーションも同じプロキシ設定を利用できる場合があります。

デメリット:

  • 柔軟性の低さ: 環境変数による設定はグローバルに適用されるため、特定のコマンドだけプロキシを使わない、あるいは別のプロキシを使うといった細かい制御がしにくいです。（ただし、no_proxy 環境変数や後述のコマンドラインオプションとの組み合わせで回避可能です。）
  • セキュリティ: 環境変数に認証情報（ユーザー名やパスワード）を含める場合、その情報はシステム上の他のユーザーから参照される可能性があるため、セキュリティリスクになり得ます。

主要なプロキシ関連環境変数

curlが認識する主要なプロキシ関連環境変数は以下の通りです。これらの変数は、大文字と小文字のどちらでも認識されることがありますが、一般的には小文字で指定することが推奨されます（例: http_proxy）。

  • http_proxy: HTTPプロトコルを使用するURLにアクセスする際に使用するプロキシサーバーを指定します。
  • https_proxy: HTTPSプロトコルを使用するURLにアクセスする際に使用するプロキシサーバーを指定します。多くのHTTPSプロキシは内部でCONNECTメソッドを使用します。
  • all_proxy: http_proxyやhttps_proxyが設定されていない場合に、全てのプロトコル（HTTP, HTTPS, FTPなど）に使用されるプロキシサーバーを指定します。特定のプロトコル用の環境変数（例: http_proxy）が設定されている場合は、そちらが優先されます。
  • no_proxy: プロキシを経由せずに直接接続するべきホスト名やドメイン、IPアドレス、ネットワークアドレス（CIDR形式）を指定します。カンマ区切りで複数指定できます。

環境変数の形式

プロキシサーバーのアドレスは、以下の形式で指定します。

[protocol://][user:password@]host:port

  • protocol://: プロキシの種類を指定します。http://, https://, socks4://, socks4a://, socks5://, socks5h:// などがあります。省略した場合、http:// と解釈されることが多いですが、明示的に指定する方が安全です。特にSOCKSプロキシを使用する場合は必須です。
  • user:password@: プロキシ認証が必要な場合に、ユーザー名とパスワードを指定します。セキュリティ上の理由から、環境変数に直接認証情報を埋め込むのは推奨されません。多くの場合は、プロキシサーバーが認証情報を要求してきた際にcurlが対話的に入力を促すか、別の安全な方法で認証情報を渡すことが望ましいです。
  • host: プロキシサーバーのホスト名またはIPアドレスです。
  • port: プロキシサーバーのポート番号です。ポート番号が省略された場合、プロトコルによってデフォルトのポートが使用されることがありますが、通常は明示的に指定します。HTTP/HTTPSプロキシの一般的なポートは8080, 3128, 80など、SOCKSプロキシの一般的なポートは1080などです。

例:

  • http://proxy.example.com:8080 (認証なしHTTPプロキシ)
  • socks5://socks.example.com:1080 (認証なしSOCKS5プロキシ)
  • http://user:[email protected]:8080 (認証ありHTTPプロキシ – 非推奨)

設定例 (Linux/macOS)

LinuxやmacOSなどのUnix系システムでは、シェル（bash, zshなど）で export コマンドを使って環境変数を設定します。

“`bash

HTTPプロキシを設定

export http_proxy=”http://proxy.example.com:8080″

HTTPSプロキシを設定 (HTTPプロキシと同じ設定を使うことが多い)

export https_proxy=”http://proxy.example.com:8080″

全ての通信にプロキシを設定 (http_proxy/https_proxy が優先)

export all_proxy=”http://proxy.example.com:8080″

プロキシを使わないホストを指定 (example.com ドメインと localhost)

export no_proxy=”example.com,localhost,127.0.0.1″

設定を確認

echo $http_proxy
echo $https_proxy
echo $no_proxy

設定を解除

unset http_proxy
unset https_proxy
unset no_proxy
unset all_proxy
unset no_proxy
“`

これらの設定は、コマンドを実行したシェルのセッション内でのみ有効です。ログイン時に毎回設定を読み込むようにするには、~/.bashrc, ~/.zshrc, ~/.profile などの設定ファイルに export コマンドを記述します。

SOCKSプロキシの設定例:

bash
export http_proxy="socks5://socks.example.com:1080"
export https_proxy="socks5://socks.example.com:1080"
export all_proxy="socks5://socks.example.com:1080"
socks5h:// のように h を付けると、プロキシサーバー側でホスト名の名前解決を行わせることができます。これは、クライアント側が名前解決できない場合に便利です。

bash
export http_proxy="socks5h://socks.example.com:1080"

設定例 (Windows)

Windowsのコマンドプロンプト（cmd.exe）やPowerShellでも環境変数を設定できます。

コマンドプロンプト (cmd.exe):

“`cmd
:: HTTPプロキシを設定
set http_proxy=http://proxy.example.com:8080

:: HTTPSプロキシを設定
set https_proxy=http://proxy.example.com:8080

:: プロキシを使わないホストを指定
set no_proxy=example.com,localhost,127.0.0.1

:: 設定を確認
echo %http_proxy%
echo %https_proxy%
echo %no_proxy%

:: 設定を解除
set http_proxy=
set https_proxy=
set no_proxy=
“`

PowerShell:

“`powershell

HTTPプロキシを設定

$env:http_proxy=”http://proxy.example.com:8080″

HTTPSプロキシを設定

$env:https_proxy=”http://proxy.example.com:8080″

プロキシを使わないホストを指定

$env:no_proxy=”example.com,localhost,127.0.0.1″

設定を確認

$env:http_proxy
$env:https_proxy
$env:no_proxy

設定を解除

Remove-Item Env:\http_proxy
Remove-Item Env:\https_proxy
Remove-Item Env:\no_proxy
“`

Windowsでこれらの設定を永続化するには、システムの環境変数として設定する必要があります。（「システムのプロパティ」->「環境変数」から設定可能）

no_proxy の詳細な使い方

no_proxy 環境変数（または後述の --noproxy オプション）は、プロキシを経由せずに直接アクセスしたいホストを指定するために非常に重要です。特に企業ネットワーク内では、社内リソースへのアクセスはプロキシ不要で、外部インターネットへのアクセスのみプロキシ経由とする場合が多いです。

no_proxy には、カンマ区切りで以下の形式の値を複数指定できます。

  • ホスト名: hostname (例: intranetserver) – 指定したホスト名に完全に一致する場合にプロキシを使用しません。
  • ドメイン名: .domain.com (例: .example.com) – 指定したドメイン名とそのサブドメイン（例: www.example.com, mail.example.com）にプロキシを使用しません。先頭のドット (.) は必須です。
  • IPアドレス: 192.168.1.100 – 指定したIPアドレスに完全に一致する場合にプロキシを使用しません。
  • ネットワークアドレス (CIDR): 192.168.1.0/24 – 指定したネットワークアドレス範囲内のIPアドレスにプロキシを使用しません。
  • 特定のポートを持つホスト/IP: hostname:port または ipaddress:port (例: intranetserver:8080, 192.168.1.100:80) – 指定したホスト/IPおよびポートに一致する場合にプロキシを使用しません。ポートが指定されていない場合は、そのホスト/IPへの全てのポートに対するアクセスでプロキシを使用しません。
  • ワイルドカード: アドレスに * を含む場合、特定のパターンに一致するホストを対象にできます。例えば、*.local は .local ドメインの全てのホストにマッチします。ただし、ワイルドカードの解釈はバージョンやライブラリによって異なる可能性があるため、一般的なホスト名、ドメイン、IP、CIDR形式の使用が推奨されます。
  • <local>: 特殊な値として <local> を指定すると、ローカルホスト (localhost, 127.0.0.1, IPv6の ::1) および、そのシステムのホスト名で解決されるアドレスへのアクセスでプロキシを使用しません。これは一般的に非常に有用な設定です。

例:

“`bash

example.com ドメインとそのサブドメイン、ローカルホスト、192.168.1.0/24 ネットワークにプロキシを使用しない

export no_proxy=”.example.com,localhost,192.168.1.0/24,”
“`

no_proxy 環境変数は、指定されたリストとアクセス先のホスト/IPを比較します。リストにマッチした場合、プロキシは使用されず、直接接続が試みられます。

環境変数設定の注意点

  • 永続化: 上記の export や set コマンドは、そのシェルのセッションが終了すると無効になります。永続的に設定したい場合は、各OSやシェルの設定ファイル（.bashrc, .profile, system environment variablesなど）に記述する必要があります。
  • セキュリティ: 環境変数にユーザー名やパスワードを含めるのは、同じシステム上の他のユーザーに情報が漏洩するリスクがあるため、避けるべきです。代わりに、後述のオプションで認証情報を渡すか、~/.curlrc ファイルを使用する、あるいはプロキシサーバー側でのIP認証など別の方法を検討してください。
  • 優先順位: 環境変数による設定は、後述のコマンドラインオプションによる設定よりも優先度が低いです。同じ項目（例: プロキシサーバーアドレス）が環境変数とコマンドラインオプションの両方で指定された場合、コマンドラインオプションが優先されます。

curlでのプロキシ設定方法 – コマンドラインオプション

環境変数による設定は便利ですが、一時的な設定や、特定のコマンド実行時のみプロキシ設定を変更したい場合には、コマンドラインオプションを使用するのが適しています。オプションは環境変数よりも優先されるため、環境変数でデフォルト設定をしておき、必要に応じてオプションで上書きするといった使い分けも可能です。

オプションを使うメリット・デメリット

メリット:

  • 柔軟性: コマンドごとに異なるプロキシサーバーを指定したり、特定のオプションを組み合わせたりすることが容易です。
  • 一時的な設定: 環境変数のようにシステム全体に影響を与えず、そのコマンド実行時のみ有効な設定ができます。
  • 認証情報の指定: 後述するように、認証情報を安全に渡すためのオプションが豊富に用意されています。（ただし、シェル履歴に残る可能性には注意が必要です。）
  • 細かい制御: プロキシ経由での接続に関する詳細な挙動（認証方式、SSL/TLS設定など）を細かく制御できます。

デメリット:

  • コマンドの複雑化: プロキシ設定に関わるオプションが増えると、コマンドラインが長くなり、読みにくくなることがあります。
  • 繰り返し指定の手間: 頻繁に同じプロキシ設定を使う場合、毎回オプションを指定するのが面倒になることがあります。（.curlrc ファイルで解決できます。）

主要なプロキシ関連オプション

curlには、プロキシ設定に関連する非常に多くのオプションがあります。ここでは主要なものを中心に解説します。

  • -x, --proxy <[protocol://][user:password@]host[:port]>: 最も重要なオプションで、プロキシサーバーを指定します。環境変数 http_proxy, https_proxy, all_proxy の設定よりも優先されます。形式は環境変数と同じですが、ユーザー名とパスワードをURLに埋め込む代わりに、別途 -U, --proxy-user オプションを使用することが推奨されます。複数のプロキシを指定したい場合は、-x オプションを複数回使用できますが、curlは通常最初のものだけを使用します。
  • -U, --proxy-user <user:password>: プロキシ認証のためのユーザー名とパスワードを指定します。-x オプションと組み合わせて使用します。パスワードを直接コマンドラインに書くとシェル履歴に残るリスクがあるため、ユーザー名だけ指定し、パスワードは対話的に入力させるか、--proxy-basic, --proxy-digest などの認証方式オプションと組み合わせて安全に扱う方法があります。
  • --proxy-anyauth: プロキシサーバーがサポートする任意の認証方式（Basic, Digest, NTLMなど）を自動的に試します。通常、-U オプションと組み合わせて使用します。
  • --proxy-basic: プロキシ認証にBasic認証を使用するよう強制します。
  • --proxy-digest: プロキシ認証にDigest認証を使用するよう強制します。
  • --proxy-negotiate: プロキシ認証にNegotiate (GSSAPI/Kerberos) 認証を使用するよう強制します。
  • --proxy-ntlm: プロキシ認証にNTLM認証を使用するよう強制します。
  • --proxy-aws-sigv4 <provider>: プロキシ認証にAWS SigV4認証を使用します。
  • --noproxy <comma-separated host list>: 環境変数 no_proxy と同様の機能を提供します。プロキシを経由せずに直接接続するホストのリストをカンマ区切りで指定します。このオプションが指定されている場合、環境変数 no_proxy よりも優先されます。形式やマッチングルールは環境変数 no_proxy と同じです。
  • -p, --proxytunnel: HTTPSやFTPなどのトンネルを必要とするプロトコルで、HTTPプロキシ経由で接続する際にCONNECTメソッドを使用するよう強制します。多くのHTTPSプロキシはCONNECTメソッドが必要ですが、curlは通常これを自動的に判断するため、このオプションはほとんどの場合不要です。しかし、特定の状況下（例: ポート443ではないHTTPSサービスにアクセスする場合など）で明示的に指定が必要になることがあります。
  • --socks4 <host[:port]>, --socks4a <host[:port]>, --socks5 <host[:port]>, --socks5h <host[:port]>: SOCKSプロキシを指定するための専用オプションです。-x オプションで socks:// プロトコルを指定するのと実質的に同じですが、これらのオプションはSOCKSプロキシであることをより明確に示します。4a と 5h は、ホスト名の名前解決をプロキシサーバー側で行うことを意味します。
  • --proxy-cacert <file>, --proxy-capath <directory>, --proxy-cert <certificate>, --proxy-key <key>, --proxy-ssl-allow-beast, --proxy-ssl-no-revoke, --proxy-ssl-opt <name>=<value>, --proxy-ssl-reqd, --proxy-ssl, --proxy-sslv2, --proxy-sslv3, --proxy-tlsv1.0, --proxy-tlsv1.1, --proxy-tlsv1.2, --proxy-tlsv1.3, --proxy-tls13-ciphers <list>, --proxy-ciphers <list>, --proxy-curves <list>: プロキシサーバーとの接続自体に関するSSL/TLS設定オプションです。これらは、curlが最終的に目的のサーバーと行うSSL/TLS接続ではなく、curlがプロキシサーバーと通信する際に使用するSSL/TLSの設定を制御します。プロキシサーバーがHTTPSプロキシ（SSL/TLSで保護されたプロキシ接続）である場合に使用します。
  • --proxy-service-name <name>: Negotiate/Kerberos認証で使用するサービスプリンシパル名を指定します。
  • --proxy-header <header name: header value>: プロキシサーバーに送信されるリクエスト（CONNECTリクエストなど）にカスタムヘッダーを追加します。

-x オプションの詳細

-x または --proxy オプションは、プロキシ設定の根幹をなします。

bash
curl -x http://proxy.example.com:8080 http://www.google.com
これは、http://www.google.com へのアクセスを proxy.example.com:8080 のHTTPプロキシ経由で行う例です。

プロトコルを指定しない場合、デフォルトは http:// と解釈されることが多いですが、明示的な指定が推奨されます。

“`bash

明示的に HTTP プロキシを指定

curl -x http://proxy.example.com:8080 http://www.google.com

明示的に SOCKS5 プロキシを指定

curl -x socks5://socks.example.com:1080 http://www.google.com
“`

認証情報を含めることも可能ですが、推奨されません。

“`bash

非推奨: コマンド履歴にパスワードが残るリスク

curl -x http://user:[email protected]:8080 http://www.google.com
“`

より安全な方法は、認証方式オプションや -U オプションと組み合わせることです。

-U オプションの詳細

-U, --proxy-user オプションは、プロキシ認証のユーザー名とパスワードを-xオプションとは別に指定できます。

bash
curl -x http://authproxy.example.com:8080 -U user:password http://www.google.com
この場合もパスワードがコマンド履歴に残るリスクがありますが、ユーザー名だけ指定し、パスワードは対話的に入力させることも可能です。

“`bash
curl -x http://authproxy.example.com:8080 -U user http://www.google.com

実行後にパスワード入力を求められる

“`

さらに安全性を高めるには、~/.curlrc ファイルを利用するか、以下のように環境変数などからパスワードを読み込む方法があります。（ただし、シェルによっては依然として履歴に残る可能性があるので注意が必要です。）

“`bash

パスワードを変数に入れる (完全に安全ではない)

PROXY_PASS=”mypassword”
curl -x http://authproxy.example.com:8080 -U “user:$PROXY_PASS” http://www.google.com
unset PROXY_PASS # 変数を削除

パスワードをファイルから読み込む (より安全)

echo “mypassword” > proxy_pass.txt

curl -x http://authproxy.example.com:8080 -U “user:$(cat proxy_pass.txt)” http://www.google.com

rm proxy_pass.txt # ファイルを削除

“`

認証方式オプションの詳細

-U オプションと組み合わせて、特定の認証方式を強制したり、自動判別させたりできます。

“`bash

Basic認証を指定して認証付きプロキシを利用

curl -x http://authproxy.example.com:8080 -U user:password –proxy-basic http://www.google.com

任意の認証方式を試す (–proxy-anyauth が最も一般的)

curl -x http://authproxy.example.com:8080 -U user:password –proxy-anyauth http://www.google.com
“`

プロキシサーバーが複数の認証方式に対応している場合、--proxy-anyauth が便利です。curlはサーバーからの応答を見て最適な認証方式を選択します。

--noproxy オプションの詳細

--noproxy オプションは、環境変数 no_proxy と同じ機能を提供しますが、コマンドラインオプションであるため、環境変数よりも優先されます。

“`bash

環境変数 no_proxy を無視して、特定のコマンド実行時のみ localhost へのアクセスでプロキシを使わない

curl –noproxy localhost -x http://proxy.example.com:8080 http://localhost/ http://www.google.com/
``
この例では、http://localhost/へのアクセスはプロキシを使わず直接行い、http://www.google.com/` へのアクセスは指定されたプロキシ経由で行います。

形式やマッチングルールは環境変数 no_proxy と全く同じです。カンマ区切りで複数指定できます。

bash
curl --noproxy "localhost,.example.com,192.168.0.0/16" -x http://proxy.example.com:8080 http://www.example.com/ http://intranet.example.com/ http://192.168.0.1/ http://www.google.com/
このコマンドでは、www.example.com, intranet.example.com, 192.168.0.1 へのアクセスはプロキシを使わず直接行い、www.google.com へのアクセスはプロキシ経由で行います。

SOCKSプロキシオプションの詳細

SOCKSプロキシを使用する場合、-x socks://... または専用オプションを使用できます。専用オプションの方が、プロキシの種類が明確になります。

“`bash

SOCKS5 プロキシを指定

curl –socks5 socks.example.com:1080 http://www.google.com/

SOCKS5 プロキシを指定し、プロキシ側でホスト名を解決

curl –socks5h socks.example.com:1080 http://www.google.com/

認証付き SOCKS5 プロキシ

curl –socks5 user:[email protected]:1080 http://www.google.com/

または

curl –socks5 socks.example.com:1080 -U user:password http://www.google.com/
``
SOCKSプロキシは特定のプロトコルに限定されないため、http_proxyやhttps_proxy環境変数にSOCKSプロキシを指定したり、-xオプションでsocks://` スキームを使ったりすることも一般的です。SOCKS5は認証に対応していますが、SOCKS4は通常認証に対応していません。

プロキシ接続時のSSL/TLS設定オプションの詳細

これらのオプションは、プロキシサーバー自体がSSL/TLSで保護されている場合（つまり、プロキシへの接続が https://proxy.example.com:port のようになる場合）に適用されます。これは、curlが最終的にアクセスする目的のURLがHTTPSであるかとは独立した設定です。

“`bash

HTTPSプロキシ (プロキシサーバーへの接続がSSL/TLS) 経由で HTTP サイトにアクセス

curl -x https://secureproxy.example.com:8443 http://www.google.com/

HTTPSプロキシ経由で HTTPS サイトにアクセス (プロキシへの接続と目的サイトへの接続の両方がSSL/TLSになる)

curl -x https://secureproxy.example.com:8443 https://www.google.com/

プロキシへのSSL/TLS接続時に特定のCA証明書を使用

curl -x https://secureproxy.example.com:8443 –proxy-cacert /path/to/proxy_ca.crt https://www.google.com/

プロキシへのSSL/TLS接続に特定のTLSバージョンを強制

curl -x https://secureproxy.example.com:8443 –proxy-tlsv1.2 https://www.google.com/
“`
これらのオプションは、通常、特定のSSL/TLS設定が要求されるセキュアなプロキシ環境で使用されます。

実用的なオプションの組み合わせ例

  • 認証付きHTTPプロキシ経由で外部サイトにアクセス:
    bash
    curl -x http://authproxy.example.com:8080 -U user:password http://www.google.com/
    # または、より安全にパスワード対話入力
    curl -x http://authproxy.example.com:8080 -U user http://www.google.com/

  • 認証付きHTTPプロキシ経由でHTTPSサイトにアクセス:
    bash
    curl -x http://authproxy.example.com:8080 -U user:password https://www.google.com/
    この場合、curlはプロキシサーバーに対して CONNECT www.google.com:443 HTTP/1.1 のようなリクエストを送信し、プロキシがトンネルを確立した後、curlはプロキシを介して www.google.com と直接SSL/TLSハンドシェイクを行います。（プロキシは単に暗号化されたデータを転送するだけです。HTTPプロキシがSSL/TLS通信の中身を見るには、後述するHTTPSインスペクションが必要です。）

  • 特定の社内サイトはプロキシを使わず、それ以外はプロキシを使う:
    “`bash
    # 環境変数でデフォルトプロキシを設定
    export http_proxy=”http://proxy.example.com:8080″
    export https_proxy=”http://proxy.example.com:8080″
    export no_proxy=”.internal.example.com,localhost,“

    (またはコマンドラインオプションで)

    curl -x http://proxy.example.com:8080 –noproxy “.internal.example.com,localhost,” …

    “`

  • プロキシにカスタムヘッダーを送信:
    bash
    curl -x http://proxy.example.com:8080 --proxy-header "Proxy-Custom-Header: myvalue" http://www.google.com/
    これはプロキシサーバーへのリクエスト（HTTPプロキシの場合は最初のGET/CONNECTリクエスト）にヘッダーを追加します。目的のサーバーへのリクエストに追加するには -H オプションを使用します。

.curlrc ファイルによる設定

頻繁に使用するプロキシ設定がある場合、ホームディレクトリに .curlrc ファイルを作成し、そこにオプションを記述しておくと便利です。これは環境変数やコマンドラインオプションよりも優先度が低いですが、デフォルト設定として役立ちます。

“`ini

~/.curlrc の例

proxy = http://proxy.example.com:8080
proxy-user = user:password

proxy-anyauth # 必要ならコメント解除

noproxy = .internal.example.com,localhost,
verbose # デバッグ用に冗長出力をデフォルトで有効化
``
このファイルに記述した設定は、特にコマンドラインオプションや環境変数で上書きされない限り、全てのcurl`コマンドに適用されます。パスワードをファイルに平文で記述することになるため、ファイルへのアクセス権限設定には注意が必要です。

環境変数とオプションの優先順位

curlでプロキシ設定を行う方法が複数あるため、どの設定が最終的に採用されるのか、優先順位を理解しておくことが重要です。

curlのプロキシ設定の優先順位は、一般的に以下のようになります（高い順）：

  1. コマンドラインオプション (-x, --proxy, --noproxy, --socks* など): コマンドラインで明示的に指定されたオプションが最も優先されます。同じ種類のオプション（例: -x と --proxy は同じ）が複数回指定された場合、通常は最後に指定されたものが有効になります。
  2. プロトコル固有の環境変数 (http_proxy, https_proxy, ftp_proxy, etc.): アクセスしようとしているURLのプロトコルに対応する環境変数が次に優先されます。
  3. all_proxy 環境変数: プロトコル固有の環境変数が設定されていない場合に、all_proxy の設定が使用されます。
  4. .curlrc ファイルの設定: ホームディレクトリの .curlrc ファイルに記述された設定は、上記のいずれの設定もない場合に適用されます。
  5. CURLOPT_PROXY などのプログラムによる設定: libcurl を利用するプログラムの場合、コード内で設定されたオプションが上記のいずれよりも優先される場合がありますが、これは curl コマンドラインツールには直接関係ありません。

例外と注意点:

  • no_proxy 環境変数と --noproxy オプションは、プロキシを使うかどうかを決定するものであり、プロキシのアドレスを指定するものではありません。--noproxy オプションは no_proxy 環境変数よりも優先されます。
  • プロキシ認証情報（ユーザー名とパスワード）は、通常、プロキシサーバーアドレスを指定するオプション/変数 (-x, --proxy, http_proxy など) と、認証情報自体を指定するオプション/変数 (-U, --proxy-user) の組み合わせで指定されます。--proxy-user オプションは、URLに埋め込まれた認証情報よりも優先されることがあります。
  • SOCKSプロキシ専用オプション (--socks4, --socks5 など) は、それ以外の汎用プロキシ設定（-x や環境変数）と同時に指定された場合の挙動が複雑になる可能性があります。通常はどちらか一方の方法で設定すべきです。

優先順位の例:

“`bash

環境変数でプロキシを設定

export http_proxy=”http://envproxy.example.com:8080″

コマンドラインオプションで別のプロキシを指定

curl -x http://optproxy.example.com:3128 http://www.google.com/
``
この場合、コマンドラインオプションの-x http://optproxy.example.com:3128が環境変数http_proxyよりも優先されるため、optproxy.example.com:3128` のプロキシが使用されます。

“`bash

環境変数でプロキシを設定

export http_proxy=”http://envproxy.example.com:8080″
export no_proxy=”localhost”

コマンドラインオプションで no_proxy を上書き

curl –noproxy “internal.example.com” http://localhost/ http://internal.example.com/ http://www.google.com/
``
この場合、http://localhost/へのアクセスは、環境変数no_proxyの設定によりプロキシを使わず直接行われます。http://internal.example.com/へのアクセスは、コマンドラインオプション–noproxy internal.example.comが環境変数no_proxyよりも優先されるため、プロキシを使わず直接行われます。http://www.google.com/へのアクセスは、環境変数http_proxy` が有効なため、プロキシ経由で行われます。

この優先順位を理解しておくと、期待通りにプロキシ設定が反映されない場合に原因を特定しやすくなります。

具体的なユースケースと設定例

ここでは、実際のシナリオに基づいたcurlのプロキシ設定例をいくつか紹介します。

1. 企業ネットワーク内でプロキシ経由で外部にアクセスする場合

多くの企業では、インターネットアクセスはセキュリティやログ取得のために一元的にプロキシサーバーを経由させます。

“`bash

.bashrc や .zshrc に設定して永続化することが多い

export http_proxy=”http://corp-proxy.example.com:8080″
export https_proxy=”http://corp-proxy.example.com:8080″

社内ネットワークへのアクセスはプロキシ不要な場合

export no_proxy=”.internal.example.com,localhost,,10.0.0.0/8,192.168.0.0/16″

設定確認

echo $http_proxy
echo $no_proxy

外部サイトにアクセス

curl http://www.google.com/
curl https://github.com/ # HTTPSも同じプロキシ経由
“`
この設定により、外部サイトへのアクセスは自動的にプロキシ経由で行われ、社内サイトやローカルホストへのアクセスは直接行われます。

2. 認証付きプロキシを使う場合

プロキシサーバーが認証を要求する場合、認証情報を渡す必要があります。

環境変数 (非推奨):

bash
export http_proxy="http://user:[email protected]:8080" # パスワード平文注意！
curl http://www.google.com/

コマンドラインオプション (推奨):

“`bash

パスワードを対話入力

curl -x http://auth-proxy.example.com:8080 -U myuser http://www.google.com/

パスワードもコマンドラインで指定 (履歴注意)

curl -x http://auth-proxy.example.com:8080 -U myuser:mypassword http://www.google.com/

認証方式を自動判別

curl -x http://auth-proxy.example.com:8080 -U myuser:mypassword –proxy-anyauth http://www.google.com/
“`

3. 特定のコマンドだけプロキシを使わない場合 (--noproxy)

普段は環境変数でプロキシを設定しているが、一時的に特定のホストへのアクセスでプロキシを使いたくない場合。

“`bash

環境変数でデフォルトプロキシを設定済みとする

export http_proxy=”http://proxy.example.com:8080″

このコマンドだけ、特定の社内サーバーにプロキシを使わずアクセス

curl –noproxy internal.example.com http://internal.example.com/
``–noproxyオプションは環境変数のno_proxyより優先されるため、このコマンド実行時はinternal.example.com` へのアクセスでプロキシが無効になります。

4. SOCKSプロキシを使う場合

SOCKSプロキシはHTTP/HTTPS以外の通信にも使えますが、ここではHTTP/HTTPSアクセスにSOCKS5プロキシを使う例を示します。

“`bash

環境変数で設定

export http_proxy=”socks5://socks.example.com:1080″
export https_proxy=”socks5://socks.example.com:1080″
curl http://www.google.com/ # SOCKS5経由

コマンドラインオプションで設定

curl -x socks5://socks.example.com:1080 http://www.google.com/

または

curl –socks5 socks.example.com:1080 http://www.google.com/

認証付きSOCKS5プロキシ (コマンドラインオプションが一般的)

curl –socks5 socks.example.com:1080 -U user:password http://www.google.com/
``
SOCKSプロキシ経由でHTTPSサイトにアクセスする場合も、通常の設定で問題ありません。curl`はSOCKSプロキシに対してCONNECTリクエストを発行し、トンネルを確立してからそのトンネル内でSSL/TLS通信を行います。

5. プロキシ設定を確認・デバッグする

プロキシが正しく設定されているか、意図したプロキシ経由で通信が行われているかなどを確認するには、-v, --verbose オプションが非常に役立ちます。

“`bash

プロキシ設定ありで詳細情報を表示

export http_proxy=”http://proxy.example.com:8080″
curl -v http://www.google.com/
``-vオプションを付けると、curl`は通信の過程で以下の情報を表示します。

  • ホスト名の解決 (* Trying ...)
  • プロキシサーバーへの接続 (* Connected to proxy.example.com (...) port 8080 (#0))
  • プロキシサーバーへのリクエストヘッダー (> GET http://www.google.com/ HTTP/1.1, > Proxy-Authorization: ..., > User-Agent: curl/..., > Host: www.google.com) – プロキシの種類によってはCONNECTメソッドが表示される場合もあります。
  • プロキシサーバーからの応答ヘッダー (< HTTP/1.1 200 Connection established など)
  • 目的のサーバーへの接続（プロキシがトンネルを確立した場合）
  • 目的のサーバーへのリクエスト/応答
  • SSL/TLSハンドシェイクの情報（HTTPSの場合）

この出力を見ることで、curlがどのプロキシサーバーに接続しようとしているか、認証情報を正しく送っているか、CONNECTメソッドを使っているかなどを確認できます。

プロキシ設定の注意点とトラブルシューティング

セキュリティ

  • 認証情報の管理: 環境変数やコマンドラインにパスワードを平文で記述するのは避けましょう。.curlrc ファイルを使う場合も、ファイルへのアクセス権限を適切に設定してください。可能であれば、パスワード入力が不要な認証方式（例: クライアント証明書認証、Kerberos認証など）を検討します。
  • HTTPSインスペクション (SSL Interception): 企業プロキシなどでは、セキュリティ目的でHTTPS通信の内容を検査するために、中間者攻撃のように振る舞うことがあります。この場合、プロキシサーバーは独自の証明書を発行してクライアントに提示します。curlがこのプロキシの証明書を信頼しない場合、SSL証明書エラー (curl: (60) SSL certificate problem: self signed certificate in certificate chain) が発生します。これを解決するには、プロキシのCA証明書をcurlに信頼させる必要があります。
    • システムの証明書ストアにプロキシのCA証明書を追加する。
    • --cacert <proxy_ca.crt> オプションで証明書ファイルを指定する。
    • 非推奨ですが、--insecure オプションで証明書の検証を無効にする（セキュリティリスクを伴います）。

パフォーマンス

プロキシを経由することで、直接接続するよりも通信に時間がかかる場合があります。プロキシサーバーの負荷やネットワーク状況によってパフォーマンスは変動します。キャッシングが有効なプロキシであれば、二回目以降のアクセスは高速になることもあります。

プロキシの種類と宛先プロトコルの互換性

  • HTTPプロキシは通常、HTTPおよびHTTPS（CONNECTメソッド経由）を扱います。FTPやその他のプロトコルには対応しないことがあります。
  • SOCKSプロキシはより汎用的ですが、HTTPプロキシのようなアプリケーション層の機能（ヘッダー書き換え、キャッシングなど）はありません。
  • 使用したいプロトコルとプロキシの種類が対応しているか確認が必要です。

ファイアウォールとの関係

クライアントからプロキシサーバーへの接続が、ローカルファイアウォールやネットワーク上のファイアウォールによってブロックされていないか確認してください。また、プロキシサーバーから目的のサーバーへの接続がブロックされていないかも確認が必要です。

よくあるエラーとその原因

  • curl: (7) Failed to connect to proxy proxy.example.com port 8080: Connection refused: 指定したプロキシサーバーのアドレスやポート番号が間違っているか、プロキシサーバーが稼働していない、またはファイアウォールによって接続がブロックされています。
  • curl: (5) Couldn't resolve proxy 'proxy.example.com': プロキシサーバーのホスト名を解決できません。DNS設定を確認してください。
  • curl: (47) Proxy authentication required: プロキシサーバーが認証を要求していますが、認証情報が提供されていないか、間違っています。-U オプションや環境変数の設定、認証方式オプション (--proxy-anyauth など) を確認してください。
  • curl: (56) Received HTTP code 407 from proxy after CONNECT: HTTPプロキシ経由でHTTPSサイトなどにアクセスしようとした際に、プロキシから認証要求または別のエラーコード(407 Proxy Authentication Required)が返されました。認証設定を見直してください。
  • curl: (60) SSL certificate problem: ...: HTTPS接続（目的サイトまたはプロキシ接続）で証明書の検証に失敗しました。自己署名証明書、期限切れ証明書、信頼されていないCAによる証明書などが原因です。HTTPSインスペクションが行われている場合は、プロキシのCA証明書を信頼させる必要があります。

デバッグ方法

-v, --verbose オプションは前述の通り非常に有効です。さらに詳細なデバッグが必要な場合は、トレースオプションを使用します。

  • --trace <file>: 全ての送受信データを指定したファイルに出力します（バイナリデータも含む可能性があります）。
  • --trace-ascii <file>: 全ての送受信データをASCII形式に変換して指定したファイルに出力します。ヘッダーやボディの内容を確認するのに便利です。

“`bash

詳細なトレース情報をファイルに出力

curl –trace-ascii curl_debug.log -x http://proxy.example.com:8080 http://www.google.com/
“`
出力されたログファイルを分析することで、どの段階で問題が発生しているか（例: プロキシへの接続、認証、目的サーバーへの接続など）を特定できます。

プロキシ設定が反映されない場合の確認事項

  1. スペルミス: 環境変数名（http_proxyなど）やオプション名、プロキシサーバーのアドレス/ポートにスペルミスがないか確認します。
  2. 環境変数の有効化: export や set コマンドが正しく実行され、現在のシェルセッションで環境変数が設定されているか echo コマンドで確認します。設定ファイルを編集した場合、シェルの再起動や source コマンドでの再読み込みが必要です。
  3. 優先順位: コマンドラインオプションが環境変数よりも優先されることを理解し、意図しないオプションが指定されていないか確認します。no_proxy/--noproxy の設定も確認します。
  4. プロキシの種類と形式: 指定したプロトコルスキーム（http://, socks5://など）や形式 (host:port, user:password@host:port) が正しいか確認します。
  5. ネットワーク設定: クライアントからプロキシサーバーへ、およびプロキシサーバーから目的のサーバーへのネットワーク経路が正常か、ファイアウォールでブロックされていないか確認します。

まとめ

この記事では、curlコマンドにおけるプロキシ設定の二つの主要な方法、すなわち環境変数とコマンドラインオプションについて詳細に解説しました。

  • 環境変数 (http_proxy, https_proxy, all_proxy, no_proxy) は、システムやシェルセッション全体にデフォルトのプロキシ設定を適用するのに便利です。一度設定すれば、多くのcurlコマンドで自動的にプロキシが使用されます。
  • コマンドラインオプション (-x, --proxy, --noproxy, -U, --proxy-user, --socks*, --proxy-anyauth, etc.) は、特定のコマンド実行時のみプロキシ設定を行う場合や、環境変数よりも優先される設定を行いたい場合に強力なツールとなります。認証情報の安全な渡し方や、SOCKSプロキシ、プロキシ接続時のSSL/TLS設定など、より詳細な制御が可能です。

これらの設定方法は、環境変数 < .curlrc ファイル < コマンドラインオプション の順に優先されます。この優先順位を理解することが、期待通りの動作を実現する鍵となります。

プロキシ設定は、単に -x オプションでアドレスを指定するだけでなく、認証、除外設定 (no_proxy/--noproxy)、プロキシの種類（HTTP/SOCKS）、そして場合によってはプロキシへの接続自体のSSL/TLS設定など、様々な側面を考慮する必要があります。

また、プロキシ設定に関するトラブルが発生した際には、-v オプションや --trace-ascii オプションを活用して、curlが実際にどのような通信を試みているかを確認することがデバッグの第一歩となります。エラーメッセージの内容も、原因特定のための重要な手がかりとなります。

この記事が、あなたのcurlとプロキシに関する理解を深め、日々の業務や開発においてcurlをより効果的かつ安全に活用するための一助となれば幸いです。

コメントする

メールアドレスが公開されることはありません。 ※ が付いている欄は必須項目です

上部へスクロール