cURLは、世界中で推定200億件ものインストール数を誇るツールです。macOS、ほとんどのLinuxディストリビューション、そしてWindows 10/11には標準で入っています。それでも、cURLのリクエストをきちんとプロキシ経由にする方法を10人の開発者に聞いたら、たぶん少しずつ違う答えが10通り返ってくるでしょう。しかも、その半分は認証やSOCKSが絡んだ瞬間に崩れます。
このズレを埋めるのが、ここで紹介する内容です。多くのチュートリアルは「このコマンドを打てば動く」と1つ見せて終わります。でも、プロキシが本当に効いているかどうかの確認方法までは教えてくれません（実は効いていないこともあります）。さらに、少しでも環境が理想から外れたとたんに出てくるエラーコードの対処法も、ほとんど触れられません。このガイドでは、HTTP/HTTPSプロキシ、SOCKS4/SOCKS5/socks5h、環境変数とその落とし穴、実践的なプロキシのトラブルシューティング表、そしてcURLとプロキシだけではもう解決できないケースまで、ひと通り解説します。
cURLとは何か？ なぜプロキシと一緒に使うのか？
cURLは、URL宛てにデータを送受信するためのコマンドラインツールです。それだけです。GUIも派手な機能もなく、HTTP、HTTPS、FTPなどのプロトコルを扱えるシンプルなプログラムです。いちばん基本的な使い方は次の通りです。
curl https://example.com
これでページを取得して、HTMLの生データをターミナルに表示します。単体でも便利ですが、開発者や技術寄りのビジネスユーザーがcURLを使う本当の理由は、APIのテスト、データのスクレイピング、地域制限コンテンツの確認、CI/CDパイプライン内でのリクエスト実行などです。
プロキシは、自分の端末と目的のサーバーの間に入り、あなたの代わりにリクエストを中継します。相手側から見えるのはあなたのIPではなく、プロキシのIPです。これは正当な用途でもかなり重要です。たとえば、別の国から見たときのサイト表示を確認する、QA中のレート制限を回避してテストする、社内で必須のゲートウェイ経由に通信を通す、といったケースです。cURLはHTTP、HTTPS、SOCKS4、SOCKS5まで幅広く対応しており、このガイドで何度も出てくるフラグは -x / --proxy（プロキシのアドレス指定）、-v（詳細出力。デバッグの相棒）、-k（SSL検証を無視。基本的にテスト以外では使わない）です。
先に1点だけ注意です。このガイドは、cURLでプロキシを使うときのネットワーク上の仕組みを説明するものです。対象サイトの利用規約や組織のセキュリティポリシーを無視していい、という意味ではありません。プロキシは通信経路を変えるだけで、合法性や許可の有無までは変えません。
始める前に
難易度: 初級〜中級
所要時間: 基本例を一通り試すのに約15分
必要なもの:
- cURLがインストールされていること（
curl --versionで確認できます。macOS、Linux、Windows 10/11なら、たいてい最初から入っています） - プロバイダーからのプロキシ情報：ホスト、ポート、プロトコル（HTTP/HTTPS/SOCKS）、必要ならユーザー名とパスワード
- ターミナル（macOSのTerminal、Linuxの任意のシェル、WindowsのPowerShellまたはCMD）
もし何らかの理由でcURLが入っていないなら、1行で入れられます。macOSならHomebrewで brew install curl、Debian/Ubuntuなら sudo apt install curl、RHEL/CentOSなら sudo yum install curl です。WindowsではWindows 10 build 17063以降でOSに同梱されています。
このガイドでは、proxy.example:8080 をプロキシアドレス、user:pwd を認証情報の例として使います。実際の値に置き換えて使ってください。そして、本物の認証情報はシェル履歴、スクリーンショット、Slackメッセージに絶対に貼らないでください。Slackでプロキシのパスワード漏えいを見た回数は、正直あまり言いたくありません。
HTTPまたはHTTPSプロキシでcURLを使う方法
これはいちばん一般的な構成で、ほとんどのプロキシ用途で使うやり方です。
-x / --proxy フラグを使う
基本形は次の通りです。
curl -x "http://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
-x と --proxy はまったく同じ意味です。覚えやすい方を使ってください。HTTPはcURLのデフォルトのプロキシスキームなので、厳密には http:// を省略して proxy.example:8080 と書くこともできます。ただ、私は明示的に書くのをおすすめします。半年後の自分が、そのほうが見てすぐ分かるからです。
URL全体はダブルクォートで囲ってください。パスワードに @、#、& が入っていると、クォートなしではcURLに届く前にシェル側で壊れます。
HTTPSプロキシ経由で接続する
プロバイダーによっては、ターゲットとの通信だけでなく、プロキシ自身との接続もTLSで行います。これはHTTPSサイトを取得することとは別の話です。プロキシのプロトコルと対象のプロトコルは、互いに独立しています。指定するには次のようにします。
curl -x "https://user:pwd@proxy.example:8080" "https://httpbin.org/ip"
ここで証明書エラーが出ても、安易に -k を足して済ませないでください。-k はSSL証明書の検証を完全に無効にします。5分だけのローカルテストならまだしも、本番や実データに触る用途ではかなり危険です。TLSを中継する社内プロキシ（企業環境でよくあるMITM構成）を使っている場合、正しい対処は検証を無効化することではなく、プロキシのCA証明書を取り込むことです。
--proxy-user で認証する
認証情報をURLに埋め込まず、専用フラグに分けることもできます。
curl -x "http://proxy.example:8080" --proxy-user "user:pwd" "https://httpbin.org/ip"
大文字の -U はターゲットサイトの認証（小文字の -u / --user）とは別物です。ここを混同すると、プロキシのパスワードを別の相手に送ることになりかねません。Basic認証ではなくNTLMやDigestを使う企業環境では、--proxy-user に加えて --proxy-ntlm や --proxy-digest を指定します。
SOCKSプロキシでcURLを使う方法：SOCKS4、SOCKS5、socks5hの違い
SOCKSプロキシはHTTPプロキシより低いレイヤーで動きます。どのプロトコルを流しているかを気にしないため、HTTP以外の通信、Tor回線、プライバシー重視の通信に向いています。競合記事ではここを1コマンドで済ませがちですが、それはもったいないです。SOCKS4、SOCKS5、socks5h:// の違いは本当に重要です。
| 機能 | SOCKS4 | SOCKS5 | socks5h:// |
|---|---|---|---|
| TCP対応 | はい | はい | はい |
| UDP対応 | いいえ | はい | はい |
| 認証 | いいえ | はい | はい |
| リモートDNS解決 | いいえ | いいえ（ローカルDNS） | はい（プロキシが解決） |
| Torとの相性 | いいえ | 注意が必要（DNS漏えい） | はい |
実際に問題になりやすいのはDNS解決の行です。socks5:// では、接続をプロキシに渡す前に自分の端末がホスト名を解決します。つまり、実際のHTTP通信はプロキシ経由でも、ローカルのDNSリゾルバー、ひいてはISPに「どのドメインへ行こうとしているか」が見えてしまいます。socks5h:// なら、ホスト名の解決をプロキシ側に任せるので、宛先に関する情報がローカルに漏れません。Torのドキュメントが socks5h:// を強く推すのはこのためです。socks5:// を使うと、Torが本来持っている匿名性のかなりの部分を台無しにしてしまいます。
cURLでの書き方は次の通りです。
curl --socks4 "proxy.example:1080" "http://example.com"
curl -x "socks5://user:pwd@proxy.example:1080" "http://example.com"
curl -x "socks5h://user:pwd@proxy.example:1080" "http://example.com"
特別な理由がない限り、socks5h:// を標準にしてください。追加コストはなく、気づきにくい漏えいを防げます。
環境変数でプロキシを設定する方法（そして落とし穴を避ける方法）
毎回 -x を打つのはすぐ面倒になります。環境変数を使えば、シェルセッションごとに一度だけプロキシを設定して、それ以降のcURL呼び出しに自動適用できます。cURLのマニュアル では、http_proxy、HTTPS_PROXY、ALL_PROXY、NO_PROXY がサポート対象として案内されています。
基本
export http_proxy="http://user:pwd@proxy.example:8080"
export HTTPS_PROXY="http://user:pwd@proxy.example:8080"
export ALL_PROXY="socks5h://proxy.example:1080"
ここで多くの人がつまずく点があります。変数名はプロキシの種類ではなく、対象URLのプロトコルを指します。つまり、http_proxy は http:// のURLへのリクエストを管理し、HTTPS_PROXY は https:// のURLを管理します。どちらも同じHTTPプロキシサーバーを向けて問題ありません。これは普通の使い方です。
NO_PROXYでバイパスする
export NO_PROXY="localhost,127.0.0.1,.internal.example"
カンマ区切りで指定します。.internal.example の先頭のドットは、任意のサブドメインに一致するワイルドカードとして働きます。NO_PROXY は他の設定より優先されます。コマンドラインで -x を明示していても、NO_PROXY に一致すればそのリクエストはプロキシを通りません。
実際によくある落とし穴
exportを忘れる。http_proxy=http://...とだけ打ってexportしないと、変数はそのシェルの中だけに閉じ込められます。cURLは子プロセスなので、まったく見えません。経験上、「プロキシが動かない」という問い合わせの最頻出原因です。- 大文字・小文字の違い。 cURLは特に小文字の
http_proxyを優先して確認します。両方ある場合は小文字が優先されます。他のツールは大文字しか読まないこともあります。「反映されない」ときは、大小混在の重複を確認してください。 - PowerShellのエイリアス問題。 PowerShell 5.1で
curlと打つと、実際にはcURLではなくInvoke-WebRequestが動きます。フラグも挙動も別物です。Windowsで-xが妙なエラーを出すなら、curl.exeを明示して、実際にcURLを使っているか確認してください。 - Windowsの書き方の違い。 CMDでは
set http_proxy=...、PowerShellでは$env:http_proxy = "..."を使います。ターミナルをまたいで混同すると、午後が丸ごと消えます。 - 古い変数が残っている。
unset http_proxyとunset https_proxyで、もう使わないプロキシ設定を消せます。黙って全リクエストを誤った経路に流す原因になります。
切り替えを素早くしたいなら、.bashrc にエイリアスを2つ入れておくとかなり便利です。
alias proxyon='export http_proxy="http://proxy.example:8080"; export https_proxy="http://proxy.example:8080"'
alias proxyoff='unset http_proxy; unset https_proxy'
cURLで常にプロキシを使うようにする（設定ファイル）
社内プロキシの内側に95%の時間いるなら、.curlrc ファイル（Unix系ではホームディレクトリ）または _curlrc（Windowsではアプリデータフォルダ）で、環境変数に触れずに永続的なデフォルトを設定できます。
proxy="http://proxy.example:8080"
一度だけプロキシを使いたくない場合は、--noproxy "*" でその実行だけ設定を上書きできます。優先順位は基本的に「コマンドラインフラグ > 環境変数 > 設定ファイル」です。なので、競合した場合はコマンドラインの -x が常に勝ちます。
重要な注意点があります。.curlrc に平文パスワードを入れないでください。同期、バックアップ、誤ってリポジトリにコミットされる可能性がある場所なら、なおさらです。CIパイプラインでは、プラットフォームのシークレットマネージャーを使い、代わりにマスクされた環境変数として認証情報を注入してください。
プロキシが本当に使われているか確認する方法
ここはほとんどの解説記事が飛ばす部分で、実は一番時間を節約できるセクションです。プロキシを設定して「たぶん流れているはず」と思い込むと、そもそもプロキシを使っていないスクレイパーの調査に何時間も溶けます。
方法1: 出口IPを比較する
同じIP確認リクエストを2回、ひとつは直接、もうひとつはプロキシ経由で実行し、比較します。
curl https://httpbin.org/ip
curl -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
両方とも同じIPを返すなら、プロキシは機能していません。フラグの書き方、環境変数、あるいは NO_PROXY が誤って対象に一致していないか確認してください。
方法2: 詳細出力を見る
任意のプロキシリクエストに -v を付けると、cURLがハンドシェイク全体を表示します。
curl -v -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip
* Connected to proxy.example (xx.xx.xx.xx) port 8080 のような行の後に、> CONNECT httpbin.org:443 HTTP/1.1、さらに < HTTP/1.1 200 Connection established が続けばOKです。この一連の流れは、HTTP CONNECTメソッド が動いている証拠で、HTTPS宛ての通信をHTTPプロキシ経由で流すときに本来起きる挙動です。CONNECT行が出ないなら、プロキシフラグが適用されていません。ここでの注意点として、-v はデバッグ中だけ使い、共有前には必ず伏せ字にしてください。詳細出力にはプロキシ認証情報が平文で出ることがあります。
方法3: 並べて差分を取る
地域確認用途なら、両方の結果をファイルに保存してdiffを取ります。
curl https://httpbin.org/ip > direct.json
curl -x "http://user:pwd@proxy.example:8080" https://httpbin.org/ip > proxied.json
diff direct.json proxied.json
レスポンス本文、あるいはヘッダー（地域制限コンテンツの場合）が違えば、プロキシがネットワーク経路を変えていることを視覚的に確認できます。細かく掘り下げる前に不安を解消する、手軽で確実な方法です。
よくあるcURLプロキシエラーの対処法
多くの解説はここを曖昧にして、-k を一度だけ触れて終わりです。でも、このテーマにはきちんとした参照表が必要です。
| エラー | 主な原因 | 対処法 |
|---|---|---|
curl: (7) Failed to connect | プロキシのホスト/ポートが違う、またはプロキシが落ちている | アドレスを確認する。telnet host port や nc -zv host port で生の接続性を試す |
407 Proxy Authentication Required | プロキシ認証情報がない、または間違っている | --proxy-user user:pass を追加する。プロバイダーがBasicではなくNTLM/Digest/Negotiateを要求していないか確認する |
curl: (56) Recv failure: Connection reset by peer | 転送中にプロキシが接続を切った | プロバイダー側で安定性を確認する。TLS終端プロキシなら、検証を無効化するのではなく証明書の扱いを確認する |
curl: (28) Connection timed out | ファイアウォールに阻まれている、古いプロキシ設定が残っている、またはポート番号が違う | env | grep -i proxy で残っている変数を確認する。古いものは消す。直接アクセスを試して原因を切り分ける |
| 証明書検証失敗 | 信頼されていない、または通信を中継するプロキシ証明書 | 正しいCAチェーンを入手して --proxy-cacert を使う。単発の診断以外で検証を無効化しない |
これらに共通する最初の一手は -v を付けることです。DNS解決、TCP接続、TLSハンドシェイク、プロキシ認証交換のどこで止まっているのかが分かるので、3桁のエラーコードだけを見て推測する必要がなくなります。
企業向けプロキシでは、--proxy-ntlm と --proxy-negotiate がWindowsドメイン系の認証方式をカバーします。cURLが本当にネイティブでは扱いきれないものの1つが、PACファイルです。PAC（Proxy Auto-Config）スクリプトを使って動的にプロキシを切り替える会社もありますが、cURLにはPACパーサーが組み込まれていません。その場合は、ブラウザのネットワーク設定などから、実際のプロキシホストとポートを手動で拾い出す必要があります。
cURLとプロキシだけでは足りないとき
cURLとプロキシの組み合わせは、静的HTML、REST API、単純なデータ取得にはかなり強いです。苦手なのは、現代のWebが好んで使う防御策です。JavaScriptで描画されるシングルページアプリ、CloudflareやAkamaiのようなボット対策、CAPTCHAの壁などです。こうした仕組みの背後にあるReactやVueのアプリにcURLを当てると、<div id="root"></div> だけが返ってくることがあります。技術的には成功、実用上は空振りです。これはcURLのバグではありません。cURLはブラウザではない、それだけです。
すでにターミナルでcURLを使い慣れていて、その壁にぶつかったなら、次の自然な一歩は別のツールチェーンに丸ごと移ることではありません。描画や構造化を代わりにやってくれる層を足すことです。そこを埋めるために作られているのがThunderbitの開発者向けツールです。
| シナリオ | cURL + プロキシ | Thunderbit API (POST /extract) |
|---|---|---|
| 静的HTMLページ | 問題なく動作 | 動作し、構造化データも返す |
| JS描画のSPA | 空のHTML、または一部だけ取得 | renderMode: "full" でJSを処理 |
| ボット対策 / CAPTCHA | ブロックされる | 標準対応 |
| 構造化データ出力 | 生HTML。自分で解析が必要 | 独自スキーマに沿ったJSON |
| 一括処理（100件以上のURL） | 手動ループ + 自前のレート制御 | POST /batch/extract |
ThunderbitのOpen APIには、JSが多いページからスキーマに一致したJSONをそのまま返す /extract エンドポイントと、きれいなMarkdown変換用の /distill エンドポイントがあります。どちらも、これまでcURLコマンドを打っていたのと同じターミナルから呼び出せます。さらに、ClaudeやCursorのようなAIコーディングアシスタント向けのMCPサーバーや、npx @thunderbit/thunderbit-cli extract <url> --schema fields.json のようなCLIもあります。もちろん、これはcURLを置き換えるものではありません。cURLが得意な仕事はそのまま任せて、構造的にcURLでは進めない部分を引き受けるだけです。AI支援の抽出が自作スクレイパーと比べてどこにハマるのかを広く知りたいなら、AI web scraping の解説やbest AI web scrapers の比較記事が役立ちます。ビジネス寄りの視点で入門したいなら、web scraping without coding もおすすめです。
まとめ
cURLとプロキシの接続は、どこで失敗しているのかが分かれば難しくありません。そして実際には、失敗ポイントのほとんどはプロキシそのものではありません。export を忘れる。-u と -U を混同する。socks5h:// のつもりで socks5:// を使う。curl.exe ではなくPowerShellの curl エイリアスを実行してしまう。どれも、プロキシ事業者とは関係ない、ややこしい汎用エラーを生みます。
いちばん時間を節約できる習慣は、トラブルシューティングの前に確認することです。IP確認を実行し、-v の出力をざっと見て、まずプロキシがリクエスト経路に本当に入っているかを確かめる。そこからです。もし対象がきれいなHTMLではなくJavaScriptを返してくるなら、それはフラグを増やして解決するcURLの問題ではありません。描画向けに作られたツール、たとえばThunderbitのAPI を使うサインです。無料枠もあるので、JSONで返ることと生HTMLの違いを自分で試せます。
FAQ
cURLはデフォルトでプロキシを使いますか？
いいえ。http_proxy / HTTPS_PROXY の環境変数を設定していない限り、または.curlrc を構成していない限り、cURLはプロキシなしで直接対象に接続します。
1回だけcURLにプロキシを使わせない方法は？
そのコマンドに --noproxy "*" を追加してください。シェルセッション全体で無効にするなら、unset http_proxy && unset https_proxy を実行します。
ローテーションプロキシとcURLは併用できますか？
はい。プロバイダーがローテーション用ゲートウェイ（1つのエンドポイントで、リクエストごとに新しいIPを割り当てる仕組み）を提供しているなら、他のプロキシと同じように -x でそのゲートウェイを指定するだけです。JavaScript描画ターゲットに対してより複雑なローテーションが必要なら、ThunderbitのようなAPI層がローテーションやボット対策を内部で処理してくれるので、リトライロジックを手作業で組む必要がありません。
なぜ socks5:// はDNSリクエストを漏らして、socks5h:// は漏らさないのですか？
curl が socks5:// を使うと、接続要求をプロキシに送る前にローカル端末で宛先ホスト名を解決します。つまり、ISPのDNSリゾルバーに訪問先ドメインが見えます。socks5h:// はホスト名解決をプロキシ側に任せるため、宛先情報がローカルでは見えません。
プロキシ経由でcURLを使うのは合法ですか？
多くの法域では、プロキシを使うこと自体は合法です。ただし重要なのは、その使い方です。対象サイトの利用規約、該当する場合はrobots.txt、そして関連するデータ保護法を必ず守ってください。このガイドは技術的な仕組みの説明に限定しており、特定の用途を法的に保証するものではありません。
さらに詳しく知る
