「http_proxy を1行 export すれば終わり」——Wget のプロキシ設定をそう高くくっている人は多いはずです。ところが実際に動かすと、リクエストはプロキシをまるごと素通りして直接サイトへ飛んでいるのに、画面にはエラーひとつ出ない。そして原因を探すうちに1時間が消えていきます。経験を積んだ sysadmin でも、入って数か月の開発者でも、ここは平等にはまります。
犯人は、たいていプロキシ本体ではなく、Wget の「設定の読み方」のほうです。設定の置き場所が4種類あって優先順位が決まっていること、環境変数名の大文字・小文字を一文字違えるだけで黙殺されること、そして man ページが触れない企業ネットワーク特有の事情——この3つが重なると、再現性のない不具合のように見えてきます。本記事では、設定の全パターンと正確な優先順位、競合したとき何が勝つのか、実際のターミナル出力つきのエラー診断、さらに他の解説がほぼ素通りする Windows と企業ファイアウォール環境までを、ひと続きで扱います。
- 難易度: 初級〜中級
- 所要時間: 読みながら設定して約15分。仕組みが頭に入っていれば約2分
- 必要なもの: Wget が動く環境（下記参照）、プロキシのアドレス（ホスト + ポート）、必要に応じてプロキシ認証情報
Wget とは何か、なぜプロキシと組み合わせるのか？
Wget は、ブラウザを開かずにインターネットからファイルやWebページを取得できるコマンドラインツールです。GNU の公式説明では「非対話型のネットワークダウンローダー」と位置づけられています。要は、人の操作を待たずにバックグラウンドで走り、途切れた転送を再開し、再帰的なダウンロードまでこなす、という性格のツールです。
そこに「プロキシ」を挟むと、中継サーバーが間に入ります。マシンが対象サイトへ直接つなぐのではなく、Wget はまずプロキシへリクエストを渡し、プロキシがそれを目的地まで転送する。よくある使いどころは次のとおりです。
- 企業ファイアウォールへの対応 — 会社のルールで、外向き通信を承認済みプロキシ経由に限定している
- プライバシーと IP 管理 — アクセス元 IP を、自分のものではなくプロキシ側に見せられる
- 地域差のテスト — 地域制限のあるリソースの取得や、CDN の挙動を特定地域から確認したい
- データ収集パイプライン — 研究や監視のために、ローテーションプロキシ経由で HTML を取得する
- CI/CD 環境 — 制限されたネットワーク上のビルド実行環境が、プロキシ経由でしか外に出られない
対応プロトコルには注意点があります。Wget が標準で扱えるのは HTTP、HTTPS、FTP のプロキシまでで、SOCKS5 は対象外です。SOCKS5 をどうしても通したいなら、curl が socks4://、socks5://、socks5h:// をネイティブ対応しているのでそちらを使うか、proxychains4 のようなツールで Wget を包んでしまう手があります。
Linux、macOS、Windows での Wget のインストール方法
プロキシの話に入る前に、まず Wget 自体を入れておきましょう。ここはあくまで準備段階で、本題はこの先です。
Linux（Debian/Ubuntu と RHEL/CentOS）
# Debian/Ubuntu
sudo apt update
sudo apt install wget
# RHEL/CentOS/Fedora
sudo dnf install wget
# 確認
wget --version
バージョンはディストリビューションでまちまちです。Ubuntu 24.04 LTS は Wget 1.21.4 を同梱、Debian Trixie は 1.25.0、CentOS Stream 10 は 1.24.5 という具合です。
macOS（Homebrew）
brew install wget
wget --version
Homebrew の formula が配布しているのは安定版の Wget 1.25.0 で、直近1年で396,818件のインストールがあります。
Windows（Chocolatey と手動インストール）
choco install wget
wget --version
Chocolatey の GNU Wget パッケージ は 累計1,000万回超のダウンロードを記録していますが、配布バージョンは 1.21.4 とやや古めです。バイナリの置き場所は通常 C:\ProgramData\chocolatey\bin\wget.exe です。
Windows ではもうひとつ覚えておきたいことがあります。Wget が .wgetrc を探す場所が、ビルド次第で変わるのです。これは後半の Windows セクションで掘り下げます。
Wget をプロキシ経由で使う4つの方法と、その選び方
設定の入れ方は4通り。それぞれ効く範囲と、互いの強さ（優先順位）が違います。
- コマンドラインの
-eフラグ — その場限りの単発設定 - ユーザー設定ファイル（
~/.wgetrc） — そのユーザーのすべての Wget コマンドに適用 - システム設定ファイル（
/etc/wgetrc） — マシン上の全ユーザーに適用 - 環境変数（
http_proxy、https_proxy） — シェルセッション全体に適用
方法 1: コマンドラインフラグ（単発のプロキシ設定）
「とりあえず1回だけ試したい」に向いた方法です。コマンドが終わればフラグも一緒に消えます。
wget -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://example.com/file.zip
HTTPS 対象の場合:
wget -e use_proxy=on -e https_proxy=http://HOST:PORT/ https://example.com/
ちゃんとプロキシを通っているかは、見かけ上の IP を取って確かめるのが手っ取り早いです。
wget -qO- -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://ifconfig.me
返ってきた IP が自分のものではなくプロキシのものなら、成功です。
方法 2: ユーザー設定ファイル（~/.wgetrc）
~/.wgetrc を開き（なければ作って）、次の行を足します。
use_proxy = on
http_proxy = http://proxy.company.com:8080/
https_proxy = http://proxy.company.com:8080/
no_proxy = localhost,127.0.0.1,.internal.company.com
= の両側にスペースを入れている点に注目してください。これは 公式に定められた .wgetrc の構文です。これ以降、このユーザーが叩く Wget コマンドは、すべてプロキシを通るようになります。
方法 3: システム全体の設定（/etc/wgetrc）
書く中身は ~/.wgetrc と変わりませんが、ファイルの置き場所がシステム側になります。GNU はこれをグローバルな起動ファイルとして扱っています。実パスはインストール構成で変わるので、見当をつける候補はこのあたりです。
/etc/wgetrc（多くの Linux パッケージマネージャー）/usr/local/etc/wgetrc（一部の Homebrew ビルド）wget --versionの出力にあるWgetrc:以下のパス
共有サーバーや Docker コンテナ、あるいは全ユーザーに同じプロキシを通させたい環境で出番になります。
方法 4: 環境変数（http_proxy / https_proxy）
export http_proxy=http://HOST:PORT/
export https_proxy=http://HOST:PORT/
export no_proxy=localhost,127.0.0.1,.internal.company.com
これらは Wget 専用ではなく、シェルセッション全体に効きます。curl をはじめ、他のツールも同じ変数を見にいきます。
ここが落とし穴: Wget が拾うのは小文字の環境変数名だけ。HTTP_PROXY（大文字）は何も言わずに無視されます。エラーも警告も一切なし、です。実際の出力は後半の落とし穴セクションで見せますが、まずここだけは刻んでおいてください。
プロキシ設定の優先順位: 複数の方法が同時にあるとき、どれが勝つのか
環境変数、.wgetrc、コマンドライン——3か所すべてにプロキシが書かれていたら、いったいどれが採用されるのか。ドキュメントだけでは心もとないので、手元で実際に確かめました。
下表が、検証で裏取りしたうえで 公式にも文書化されている 優先順位です。
| 優先度 | 方法 | 適用範囲 | 上書き対象 |
|---|---|---|---|
| 1（最優先） | -e の CLI フラグ | 単一コマンド | すべて |
| 2 | ~/.wgetrc | 現在のユーザー | システム設定 + 環境変数 |
| 3 | /etc/wgetrc | システム全体 | 環境変数のみ |
| 4（最下位） | http_proxy / https_proxy の環境変数 | シェルセッション | なし |
検証は Wget 1.25.0 で、各レベルにわざと違うプロキシをぶつけて行いました。環境変数を 3128 番、設定ファイルを 3129 番、CLI を 3130 番に向けると、結果はこうでした。
- 設定ファイルが環境変数を打ち負かす: Wget は 3128 を素通りし、3129 に接続。
- CLI が設定ファイルを打ち負かす: Wget は 3129 も 3128 も無視し、3130 に接続。
そして、この序列を丸ごと飛び越えるのが --no-proxy です。どこに書かれたプロキシ設定だろうと、まとめて無効にします。
wget --no-proxy https://internal-server.company.com/report.pdf
たとえば、/etc/wgetrc に全社共通のプロキシを置いている sysadmin が、社内サーバーにだけ直接つなぎたい——そんなとき、システム設定をいじらずにそのコマンドだけ --no-proxy を付ければ済みます。
認証付きプロキシで Wget を使う方法
商用や家庭向けのプロキシは、たいていユーザー名とパスワードを求めてきます。Wget はこれに、HTTP Basic 認証ベースの2通りで対応します。
プロキシ URL に認証情報を埋め込む
wget -e use_proxy=on \
-e http_proxy=http://USERNAME:PASSWORD@proxy.company.com:8080/ \
http://example.com/file.zip
同じ書き方は .wgetrc にも持ち込めます。
http_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
https_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
--proxy-user と --proxy-password フラグを使う
wget --proxy-user=USERNAME --proxy-password=PASSWORD \
-e use_proxy=on \
-e http_proxy=http://proxy.company.com:8080/ \
http://example.com/file.zip
このフラグは、URL に埋め込んだ user:pass@ よりも強く、そちらを上書きします。
認証情報を漏らさないために
どちらの書き方も、扱いを誤ると認証情報が漏れます。GNU も、コマンドラインに書いたパスワードは ps などのプロセス一覧から丸見えになると注意しています。場面ごとの守り方はこうです。
- 単一ユーザーのマシン:
~/.wgetrcに認証情報を置き、chmod 600 ~/.wgetrcで読める範囲を絞る - CI/CD パイプライン: GitHub Actions の暗号化シークレットなど、各プラットフォームの相当機能に預ける。ステップでは小文字の環境変数として渡し、YAML に直書きしない
- Docker ビルド: 秘密情報に
ARGやENVを使わない。Docker 公式も、ビルド引数が最終イメージに残り得ると明記しています。代わりに BuildKit の secret mount を使う - バージョン管理: 認証情報入りの
.wgetrcをコミットしない。.gitignoreに入れておく
GitHub Actions ならではの注意もひとつ。シークレット名は慣例で大文字にしますが、Wget へ渡す環境変数は小文字でなければ効きません（HTTP_PROXY ではなく http_proxy）。
Windows と企業ファイアウォール環境で Wget をプロキシと使う方法
この手の記事は「Chocolatey で入れたら完了」で締めがちです。ですが Windows や企業プロキシの現場では、そこがゴールではなくスタートです。
Windows が .wgetrc を探す場所
GNU のドキュメントによれば、Wget は WGETRC で別の場所を明示しない限り $HOME/.wgetrc を読みます。やっかいなのは、Windows では $HOME が %USERPROFILE%（例: C:\Users\alice）を指すこともあれば、Chocolatey・MSYS2・Git Bash・単体バイナリのどれを使うかによって指さないこともある、という点です。
推測でつまずくくらいなら、--config フラグで読むファイルを名指ししてしまうのが確実です。
wget --config=C:\Users\alice\wgetrc https://example.com/file.zip
「この場所の設定ファイルを本当に読めているか」を確かめたいときは、わざと使えないプロキシを指すテストファイルを用意します。
; C:\Users\alice\wget-test.rc
use_proxy = on
http_proxy = http://127.0.0.1:3128/
そのうえでこう叩きます。
wget --config=C:\Users\alice\wget-test.rc --spider http://example.com/
Wget が 127.0.0.1:3128 へつなぎにいけば、そのファイルをちゃんと読んでいる証拠です。
Windows でプロキシ環境変数を設定する
CMD（そのセッションだけ）:
set http_proxy=http://HOST:PORT/
set https_proxy=http://HOST:PORT/
wget http://example.com/
PowerShell（そのセッションだけ）:
$env:http_proxy = "http://HOST:PORT/"
$env:https_proxy = "http://HOST:PORT/"
wget http://example.com/
永続化（再起動後も生きる）:
setx http_proxy http://HOST:PORT/
setx https_proxy http://HOST:PORT/
setx を使ったら、新しいターミナルを開き直してください。いま開いているセッションには反映されません。
企業プロキシの落とし穴: PAC ファイル、NTLM 認証、プロキシアドレスの見つけ方
企業ユーザーがつまずくのは、だいたい次の3か所です。
PAC ファイル: 多くの企業は Proxy Auto-Configuration（PAC）ファイルを配っています。これは「どの URL にどのプロキシを使うか」をブラウザに教える JavaScript スクリプトです。ところが Wget には JavaScript の実行環境がないので、PAC ファイルは読めません（curl のドキュメントも同じ点を指摘しています）。抜け道は、PAC ファイルを自分で開く（または IT に聞く）ことで、対象ドメインに割り当てられた PROXY host:port を特定し、その静的アドレスを Wget に直接渡すことです。
NTLM 認証: Wget のプロキシ認証は Basic 認証だけの実装です。会社のプロキシが NTLM を求めてきて 407 Proxy Authentication Required が返るなら、--proxy-user の書き方をどういじっても通りません。ここは Cntlm の出番です。NTLM/NTLMv2 を肩代わりし、Wget に対しては Basic 認証の入口だけを見せてくれるローカル中継で、今も保守が続いています（最終更新 2025年10月、週約395ダウンロード）。
企業プロキシ利用者向けの判断フロー:
- まず
set http_proxy=http://YOUR_PROXY:PORT/を試して Wget を走らせる。 407が返り、会社が NTLM を使っているなら → Cntlm を入れ、ドメイン資格情報で設定し、Wget を Cntlm のローカルポート（通常http://127.0.0.1:3128/）へ向ける。- 会社が PAC ファイルを使っているなら → PAC から実際の
PROXY host:portを抜き出すか、IT に静的アドレスを確認する。
企業プロキシでよく見るポートは 3128（Squid 系）、8080（一般的な HTTP プロキシ）、8888（Fiddler/Charles などデバッグ用）あたり。ただし、これは慣習であって保証ではありません。
Wget をプロキシで使うときのよくある落とし穴（実際のエラー出力つき）
ここからが、冒頭で予告した“本題”です。以下の出力はすべて、2026-06-01 時点の Wget 1.25.0（macOS、Homebrew）で手元再現したものです。
落とし穴 1: http:// プレフィックスの付け忘れ
「これをやると確実に壊れる」と古い記事は書きがちですが、Wget 1.25.0 では http_proxy=127.0.0.1:3128 でも動きます。Wget が裏で http:// を補ってくれるからです。
Prepended http:// to '127.0.0.1:3128'
Spider mode enabled. Check if remote file exists.
--2026-06-01 10:38:15-- http://example.com/
Connecting to 127.0.0.1:3128... failed: Operation not permitted.
実際、ちゃんと正しいプロキシへつなぎにいっています。とはいえ私は、http:// も末尾のスラッシュも常に付ける派です。バージョン差による解釈のぶれを避けられますし、認証情報の書式（http://user:pass@host:port/）もはっきりします。
落とし穴 2: use_proxy=yes と use_proxy=on
私が Wget 1.25.0 で試した範囲では、yes も on もどちらも通りました。一方で、無効な値はきっぱりエラーになります。
wget: use_proxy: Invalid boolean 'true'; use `on' or `off'.
最も無難なのは on です。マニュアルが示す真偽値の書式とも、Wget 自身のエラーメッセージとも一致します。
落とし穴 3: 大文字の HTTP_PROXY が静かに無視される
これがいちばん始末に負えません。エラーが何も出ないからです。Wget は、プロキシなど最初から設定されていなかったかのように、平然と直接接続します。
大文字版（失敗。プロキシは使われない）:
HTTP_PROXY=http://127.0.0.1:3128/ wget --no-config --spider http://example.com/
Spider mode enabled. Check if remote file exists.
--2026-06-01 10:40:06-- http://example.com/
Resolving example.com (example.com)... 198.18.58.61
Connecting to example.com (example.com)|198.18.58.61|:80... connected.
HTTP request sent, awaiting response... 200 OK
小文字版（成功。プロキシへの接続を試みる）:
http_proxy=http://127.0.0.1:3128/ wget --no-config --spider http://example.com/
Spider mode enabled. Check if remote file exists.
--2026-06-01 10:40:16-- http://example.com/
Connecting to 127.0.0.1:3128... failed: Connection refused.
差はひと目で分かります。大文字版は example.com を直接名前解決し、小文字版はプロキシへ向かっている。どちらも警告は出ません。curl にも似た振る舞いがあり、多くのプロキシ変数は大文字を受け付ける一方、大文字の HTTP_PROXY だけはセキュリティ上の理由で明示的に拒否します。
対策: とにかく小文字の http_proxy と https_proxy で統一すること。
落とし穴 4: .wgetrc に残った古いプロキシで「Connection Refused」になる
設定ファイルに昔のプロキシアドレスが居残っていると（自分が書いたものでも、sysadmin が書いたものでも、Docker イメージに焼かれていても）、こうなります。
Spider mode enabled. Check if remote file exists.
--2026-06-01 10:39:10-- http://example.com/
Connecting to 127.0.0.1:3128... failed: Connection refused.
このエラーが指しているのは対象サイトではなく、古いプロキシ IP のほうです。切り分けは、先ほどの優先順位をそのまま上からたどります。
- コマンドに
-eフラグやシェルエイリアスが紛れていないか確認する ~/.wgetrc（またはWGETRCが指すファイル）を確認する- システム設定（
wget --versionに出るパス）を確認する - 環境変数を確認する:
env | grep -i proxy
デバッグ時の心強い味方が --no-config です。設定ファイルを丸ごと無視して走らせます。
wget --no-config --spider http://example.com/
これで動くなら、原因は設定ファイル側にあると断定できます。
落とし穴 5: HTTPS プロキシの URL 記法がややこしい
ここでつまずく人がとにかく多いです。https_proxy を設定するとき、プロキシ URL 自体は普通 https:// ではなく http:// で書きます。Wget は、暗号化された HTTPS セッション用のトンネルを掘るために、プロキシへ HTTP CONNECT リクエストを投げるからです。
正しい例:
https_proxy=http://proxy.company.com:8080/
wget https://example.com/
Wget はまずプロキシに CONNECT example.com:443 HTTP/1.1 を送り、そのあと HTTPS をトンネルします。
誤りの例（HTTP ターゲットに HTTPS プロキシエンドポイントを指定）:
http_proxy=https://127.0.0.1:18082/
wget http://example.com/
Error in proxy URL https://127.0.0.1:18082/: Must be HTTP.
Wget 1.25.0 は、HTTP ターゲット向けのプロキシ URL に https:// を見つけると、その場で突き返します。組織が HTTPS プロキシのエンドポイントを明示し、そのビルドで動作確認できている場合を除いては、https_proxy=http://HOST:PORT/ で書いてください。
Wget のプロキシコマンド早見表（保存用クイックリファレンス）
ブックマーク向きの表です。Wget のプロキシ関連フラグと設定項目を、1か所にまとめました。
| フラグ / 設定 | 用途 | 例 | 補足 |
|---|---|---|---|
-e use_proxy=on | CLI | -e use_proxy=on | on が最も安全。ビルドによっては yes も可 |
-e http_proxy= | CLI | -e http_proxy=http://proxy:8080/ | http:// プレフィックスと末尾の / を付ける |
-e https_proxy= | CLI | -e https_proxy=http://proxy:8080/ | HTTPS 対象でも、プロキシ URL は通常 http:// |
--proxy-user | CLI | --proxy-user=admin | 埋め込みの user:pass@ より優先 |
--proxy-password | CLI | --proxy-password=secret | ps で見えるので、共有環境では避ける |
--no-proxy | CLI | --no-proxy | すべてのソースのプロキシ設定を無効化 |
--no-config | CLI | --no-config | すべての設定ファイルをスキップ。デバッグに便利 |
--config=FILE | CLI | --config=/tmp/wgetrc | 設定ファイルの場所を固定できる。Windows や CI に最適 |
http_proxy | .wgetrc / env | http_proxy = http://proxy:8080/ | 設定ファイルでは = の前後にスペース。環境変数は小文字 |
https_proxy | .wgetrc / env | https_proxy = http://proxy:8080/ | http_proxy と同じ形式 |
ftp_proxy | .wgetrc / env | ftp_proxy = http://proxy:8080/ | FTP 取得用 |
no_proxy | .wgetrc / env | no_proxy = localhost,127.0.0.1,.corp | カンマ区切りのドメイン一覧 |
proxy_user | .wgetrc | proxy_user = admin | --proxy-user と同等 |
proxy_password | .wgetrc | proxy_password = secret | ファイルは chmod 600 で保護する |
Wget + プロキシが最適でないケースと、その代替手段
ここまで設定を詰めておいて言うのもなんですが、あえて逆方向の話をします。そもそも Wget を選ばないほうがいい場面も、確かにあるのです。
「wget proxy」で検索する人の本当の目的は、1ファイルのダウンロードとは限りません。商品価格、連絡先一覧、不動産リストといった構造化データを集めたくて、たまたま手に馴染んだコマンドが Wget だった——というケースが、実はかなりの割合を占めます。ここで効いてくるのが、Wget が返すのは生の HTML だという事実です。そこから解析し、整形し、構造に落とす作業がまるごと残ります。おまけにブロック回避でプロキシをローテーションし始めると、プロキシリスト・ダウンロードスクリプト・パーサー・書き出し処理まで、すべて自前で面倒を見ることになります。
| 目的 | 最適なツール | 理由 |
|---|---|---|
| プロキシ経由で単一ファイルをダウンロードしたい | プロキシフラグ付きの wget | シンプルで 1 コマンドで済む |
| プロキシ経由でサイトやディレクトリをミラーしたい | wget --recursive + プロキシ設定 | 再帰取得は Wget の得意分野 |
| 構造化データ（表、一覧、連絡先）を抽出したい | Thunderbit | Wget は生 HTML しか返さないので、結局は解析が必要。Thunderbit は AI がページを読み取り、コード不要で Excel、Google Sheets、Airtable、Notion に構造化データとして出力します。クラウドスクレイピングが IP ローテーションや bot 対策も処理するので、プロキシ設定自体が不要です。 |
| プロキシ経由で REST API を叩きたい | curl | ヘッダー制御がしやすく、JSON をネイティブに扱え、SOCKS5 も対応 |
| 定期的にデータ収集したい | Thunderbit Scheduled Scraper または cron + wget | ページ構造の変更に Thunderbit は追従しやすい。cron + wget は静かに壊れやすい |
ファイルのダウンロードに関して、Wget は今でも一級品です。ただ、「プロキシ設定 → IP ローテーション → HTML 取得 → パーサー作成 → スプレッドシートへ出力」という長い連結は、最終的な成果物が単なるデータの表である場合、部品の数が明らかに過剰です。心当たりがあるなら、Chrome 拡張機能を使えば、この一連の流れを2クリックに畳めます。さらに知りたい方は、AI Web Scraping と コードなしでの Web スクレイピング のガイドが参考になります。
逆に、やりたいことが「社内プロキシ越しにこの ZIP を1つ落とす」なら、答えは変わりません。Wget が最適です。この記事を読み終えた今なら、もう正しく設定できるはずです。
重要ポイントまとめ
要点だけ、短く拾っておきます。
- 4つの方法と明確な優先順位: CLI フラグはユーザー設定より優先され、ユーザー設定はシステム設定より優先され、システム設定は環境変数より優先されます。
--no-proxyはすべてを上書きします。 - 環境変数は必ず小文字 で（
HTTP_PROXYではなくhttp_proxy）。大文字は静かに無視されます。 - プロキシ URL には必ず
http://を付ける こと。https_proxyでも同じです。プロキシ先は HTTP で、HTTPS は CONNECT でトンネルします。 .wgetrcや-eフラグの真偽値はonが安全。Wget のバージョン差をまたいでも安定します。- Windows ユーザー: 設定ファイルの曖昧さを断つには
--config=C:\path\to\wgetrc。セッション用の変数はset（CMD）か$env:（PowerShell）で。 - 企業プロキシユーザー: Wget は PAC ファイルを読めず、NTLM もネイティブ非対応です。必要なら Cntlm をローカル中継に挟みましょう。
- 上の早見表を保存 しておけば、フラグ名を思い出すたびに記事を読み返さずに済みます。
そして、本当に欲しいのが構造化データなら、Thunderbit や curl のほうが近道かもしれません。最良のデバッグとは、そもそも始めずに済むデバッグです。
FAQ
1. Wget は SOCKS5 プロキシをサポートしていますか？
いいえ。GNU Wget 1.x が対応するのは HTTP、HTTPS、FTP のプロキシだけです。Wget2 プロジェクトでは SOCKS5 が要望に挙がっていますが、標準で文書化されたオプションではありません。SOCKS5 を使うなら、curl の socks5:// か socks5h:// を使うか、proxychains4 で Wget を包んで SOCKS 経由にします。
2. HTTP_PROXY を大文字で設定しても無視されるのはなぜですか？
Wget が読むのは小文字の環境変数名だけだからです（http_proxy、https_proxy、ftp_proxy、no_proxy）。HTTP_PROXY のような大文字版は黙って無視され、エラーも警告も出ません。何が悪いのか見当がつかないぶん、最も厄介なトラブルのひとつです。とにかく小文字で。
3. 特定ドメインだけプロキシをバイパスするにはどうすればいいですか？
no_proxy を環境変数か .wgetrc で指定します。
export no_proxy=localhost,127.0.0.1,.mycompany.com
または ~/.wgetrc に:
no_proxy = localhost,127.0.0.1,.mycompany.com
ドメインはカンマ区切り。先頭にドットを付けた .mycompany.com は、配下のサブドメインすべてに一致します。
4. Wget でローテーションプロキシは使えますか？
Wget 単体にローテーション機能はありません。手は2つ。ひとつは、サーバー側で出口 IP を回してくれるプロキシプロバイダを使うこと。常に同じゲートウェイにつなぎながら、出口 IP だけが変わります。もうひとつは、プロキシ一覧からランダムに1つ選び、実行ごとに -e http_proxy=... で渡すシェルスクリプトを書くこと。自動ローテーション、リトライ制御、bot 対策まで欲しくなったら、専用のスクレイピングツールのほうが向いています。
5. Wget における http_proxy と https_proxy の違いは何ですか？
対象 URL が http:// なら http_proxy、https:// なら https_proxy が使われます。どちらでも、プロキシ URL 自体は通常 http:// です。HTTPS 対象では、Wget がプロキシへ HTTP CONNECT を送ってトンネルを作り、実際の暗号化は Wget と対象サーバーの間でエンドツーエンドに行われます。プロキシからは CONNECT に含まれるホスト名こそ見えますが、暗号化された中身までは読めません。
AI Web Scraping に Thunderbit を試す Get Started Free
詳しくはこちら
