如何透過 Proxy 使用 Wget（並避開常見坑點）

Wget 的 proxy 設定看起來像是五分鐘就能搞定的事——直到你花了一個小時，才發現請求根本沒走 proxy，而且還完全沒有任何錯誤訊息。我看過資深系統管理員和剛入行的工程師都踩過這個坑。

問題幾乎從來不在 proxy 本身，而是在於 Wget 可能從四個不同地方讀取 proxy 設定、大小寫用錯時會默默失敗，以及企業網路那些 man page 根本不會告訴你的特殊規則。本指南會完整說明 Wget 的各種 proxy 設定方式、當多種設定同時存在時的實際優先順序、每種常見錯誤的終端機輸出，還特別整理了 Windows 與企業防火牆環境的處理方式——也就是幾乎所有其他教學都假設不存在的那群使用者。

難度： 初學到中階
所需時間： 約 15 分鐘閱讀與設定；如果你已經很熟悉，約 2 分鐘就能完成
你需要準備： 已安裝好的 Wget（下方有安裝說明）、proxy 位址（主機 + 埠號），以及可選的 proxy 認證資訊

試用 Thunderbit，輕鬆擷取結構化資料

Wget 是什麼？為什麼要搭配 Proxy 使用？

Wget 是一個命令列工具，可以在不開瀏覽器的情況下，從網際網路下載檔案與網頁。GNU 官方說明把它稱為「非互動式網路下載器」——也就是說，它可以在背景執行、續傳中斷的傳輸，還能做遞迴下載，不需要人手動點任何按鈕。

在這裡，proxy 可以理解成一個中介伺服器。不是你的電腦直接連到目標網站，而是 Wget 先把請求送到 proxy，再由 proxy 轉送出去。這樣做通常有幾個原因：

企業防火牆合規——公司規定所有對外流量都必須經過核准的 proxy
隱私與 IP 管理——對外顯示的是 proxy 的 IP，而不是你的
地區測試——從特定地區抓取受地域限制的資源，或測試 CDN 行為
資料蒐集流程——透過輪替 proxy 下載 HTML，進行研究或監控
CI/CD 環境——建置執行器位於封閉網路中，只能透過 proxy 連上網際網路

Wget 原生支援 HTTP、HTTPS 與 FTP proxy，但不支援 SOCKS5。如果你需要 SOCKS5，curl 原生支援 socks4://、socks5:// 和 socks5h://，或者你也可以搭配 proxychains4 之類的工具包住 Wget。

如何在 Linux、macOS 與 Windows 安裝 Wget

在設定 proxy 之前，你得先確定電腦上已經有 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，過去一年有 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 搭配 Proxy 的 4 種方式（以及該選哪一種）

有四種方法，每種的作用範圍與優先層級都不同：

命令列 -e 參數——一次性、單一指令
使用者設定檔（~/.wgetrc）——套用到你執行的每一個 Wget 指令
系統設定檔（/etc/wgetrc）——套用到這台機器上的所有使用者
環境變數（http_proxy、https_proxy）——套用到整個 shell 工作階段

方法 1：命令列參數（一次性 Proxy）

適合快速測試。指令結束後，設定就消失。

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/

快速測試一下——透過 proxy 抓取你對外顯示的 IP：

wget -qO- -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://ifconfig.me

如果輸出的 IP 是 proxy 的，而不是你自己的，表示設定成功。

方法 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 指令，都會走 proxy。

方法 3：系統層級設定（`/etc/wgetrc`）

指令內容與 ~/.wgetrc 相同，但放在系統設定檔中。GNU 把它定義為全域啟動檔——實際路徑會依安裝前綴而異。常見位置包括：

/etc/wgetrc（大多數 Linux 套件管理器）
/usr/local/etc/wgetrc（某些 Homebrew 建置）
wget --version 輸出中「Wgetrc:」所顯示的路徑

這適合共用伺服器、Docker 容器，或任何所有使用者都應該走同一個 proxy 的環境。

方法 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

這些設定會影響整個 shell 工作階段，不只是 Wget。像 curl 這類工具也會讀取它們。

重要提醒： Wget 只會讀取小寫的環境變數名稱。HTTP_PROXY（大寫）會被靜默忽略。沒有錯誤、沒有警告、什麼都沒有。後面的坑點章節我會展示實際終端輸出，但這一點現在就很值得先記住。

Proxy 方法優先順序：多種設定同時存在時，誰會覆蓋誰？

如果你的環境變數、.wgetrc 和命令列同時都設定了 proxy，到底哪一個會生效？很多說明都講不清楚，所以我實際測過。

以下是經過測試、且官方文件也有記載的優先順序：

優先級	方法	作用範圍	覆蓋對象
1（最高）	`-e` 命令列參數	單一指令	所有設定
2	`~/.wgetrc`	目前使用者	系統設定 + 環境變數
3	`/etc/wgetrc`	全系統	只覆蓋環境變數
4（最低）	`http_proxy` / `https_proxy` 環境變數	Shell 工作階段	不覆蓋任何東西

我用 Wget 1.25.0 實測了每一層都設定不同 proxy 的情況。當環境變數指向 3128 埠、設定檔指向 3129 埠，而命令列指向 3130 埠時：

設定檔優先於環境變數： Wget 連到 3129 埠，忽略了 3128。
命令列優先於設定檔： Wget 連到 3130 埠，忽略了 3129 和 3128。

如果你想直接繞過所有 proxy，可以用 --no-proxy。不管原本在哪裡設定，它都會全部跳過：

wget --no-proxy https://internal-server.company.com/report.pdf

實際情境：系統管理員已經在 /etc/wgetrc 裡設了 proxy，但你需要直接連內網伺服器。這時候與其去改系統設定，不如單次命令加上 --no-proxy。

如何讓 Wget 搭配已驗證的 Proxy 使用

多數商用或住宅 proxy 都需要使用者名稱和密碼。Wget 支援兩種做法，兩者都是透過 HTTP Basic authentication 來傳遞 proxy 認證。

直接把憑證放進 Proxy 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

這些參數會覆蓋 proxy URL 裡的 user:pass@ 寫法。

如何保護帳密安全

這兩種方式都可能外洩認證資訊。GNU 官方文件提醒，命令列上的密碼可以透過 ps 或程序列表工具看到。建議如下：

單人使用的電腦： 把憑證放在 ~/.wgetrc，並鎖定檔案權限：chmod 600 ~/.wgetrc
CI/CD 流程： 使用 GitHub Actions 加密 secrets 或平台提供的對應功能。在步驟定義中以小寫環境變數傳入，千萬不要直接寫死在 YAML 裡。
Docker build： 不要把 secret 放在 ARG 或 ENV 裡。Docker 官方文件明確警告：build arguments 可能會留在最終映像中。請改用 BuildKit secret mounts。
版本控制： 不要把含有憑證的 .wgetrc 提交到 Git，記得加入 .gitignore。

GitHub Actions 有一個跟 Wget 很相關的小細節：secret 名稱通常慣例會用大寫儲存，但你提供給 Wget 的環境變數一定要是小寫（http_proxy，不是 HTTP_PROXY）。

在 Windows 與企業防火牆後方如何使用 Wget + Proxy

多數文章講到這裡就只會停在「用 Chocolatey 安裝」。但如果你在 Windows 上，或者身處企業 proxy 環境，問題其實才剛開始。

Windows 會去哪裡找 `.wgetrc`

GNU 文件說明，Wget 會讀取 $HOME/.wgetrc，除非 WGETRC 環境變數指定了其他位置。在 Windows 上，$HOME 可能會對應到 %USERPROFILE%（例如 C:\Users\alice），也可能不會——這取決於你用的是 Chocolatey 版、MSYS2 版、Git Bash，還是獨立可執行檔。

我的建議是：不要猜，直接用 --config 參數來確保行為可預期：

wget --config=C:\Users\alice\wgetrc https://example.com/file.zip

如果你想測試某個建置是否會讀取特定位置的設定檔，可以建立一個指向明顯錯誤 proxy 的測試檔：

; 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 設定 Proxy 環境變數

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 之後，你必須開啟新的終端機視窗；目前這個工作階段不會立刻看到變更。

企業 Proxy 常見坑點：PAC 檔、NTLM 驗證，以及如何找出 Proxy 位址

企業使用者最常卡住的三件事：

PAC 檔： 很多企業會使用 Proxy Auto-Configuration（PAC）檔——這是一種以 JavaScript 撰寫的腳本，用來告訴瀏覽器不同網址應該走哪個 proxy。Wget 沒有 JavaScript 解析器，所以它無法讀取 PAC 檔。curl 文件也說明了同樣的問題。解法是：打開 PAC 檔（或請 IT 幫忙），找出你的目標網域對應的 PROXY host:port，再把這個靜態位址填到 Wget 裡。

NTLM 驗證： Wget 的 proxy 驗證只實作 Basic auth。如果公司的 proxy 需要 NTLM，而你看到 407 Proxy Authentication Required，就不要浪費時間試各種 --proxy-user 寫法了。請安裝 Cntlm——它是一個本機轉接層，能處理 NTLM/NTLMv2 驗證，並對 Wget 提供 Basic-auth 介面。Cntlm 目前仍在維護（最後更新為 2025 年 10 月，每週約 395 次下載）。

企業 proxy 使用者決策樹：

先試 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 索取靜態 proxy 位址。

企業常見 proxy 埠號包括：3128（類似 Squid）、8080（通用 HTTP proxy）、8888（像 Fiddler/Charles 這類除錯 proxy）。這些都只是慣例，不是保證。

使用 Wget 搭配 Proxy 時的常見坑點（附實際錯誤輸出）

接下來就是標題承諾的重點。以下每一段輸出都已在 Wget 1.25.0（macOS，Homebrew）上於 2026-06-01 重現。

坑點 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.

它仍然有連到正確的 proxy。不過我還是建議你一律明確加上 http:// 前綴，並保留結尾的 /。這樣可避免不同 Wget 版本之間的歧義，也讓憑證格式（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 會直接連線，就像你根本沒有設定 proxy 一樣。

大寫版本（失敗——未使用 proxy）：

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

小寫版本（成功——有嘗試走 proxy）：

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；小寫版本才是真的去連 proxy。兩者都不會出現警告。curl 也有類似的特性——它對大多數 proxy 變數接受大寫，但基於安全考量，會明確拒絕大寫的 HTTP_PROXY。

修正方式： 一律使用小寫 http_proxy 和 https_proxy。

坑點 4：`.wgetrc` 裡殘留舊 proxy，導致「Connection Refused」

如果你（或系統管理員、或某個 Docker 映像）在設定檔裡留下了舊 proxy 位址，就會看到像這樣的錯誤：

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.

錯誤訊息指向的是舊 proxy IP，而不是目標網站。建議依照優先順序排查：

檢查你的指令是否有 -e 參數或 shell alias
檢查 ~/.wgetrc（或 WGETRC 指定的檔案）
檢查系統設定（wget --version 顯示的路徑）
檢查環境變數：env | grep -i proxy

除錯時，--no-config 很有用——它會讓 Wget 略過所有設定檔：

wget --no-config --spider http://example.com/

如果這樣可以正常運作，那問題就一定出在設定檔裡。

坑點 5：HTTPS Proxy 語法讓人混淆

這點會讓很多人卡住。當你設定 https_proxy 時，proxy URL 本身通常是 http://，而不是 https://。因為 Wget 會透過 proxy 發送 HTTP CONNECT 請求，建立一條給加密 HTTPS 工作階段使用的通道。

正確：

https_proxy=http://proxy.company.com:8080/
wget https://example.com/

Wget 會先對 proxy 發送 CONNECT example.com:443 HTTP/1.1，再透過它建立 HTTPS 隧道。

錯誤（對 HTTP 目標網址使用 HTTPS proxy 端點）：

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 會直接拒絕把 https:// 當成 HTTP 目標的 proxy URL。除非你的組織有明確文件說明並且你也已在 Wget 建置上測過，否則請使用 https_proxy=http://HOST:PORT/。

Wget Proxy 指令速查表（可收藏）

把這張表收藏起來。它把所有跟 proxy 相關的 Wget 參數與設定指令整理在同一個地方。

參數 / 指令	情境	範例	備註
`-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 目標，proxy URL 通常仍是 `http://`
`--proxy-user`	CLI	`--proxy-user=admin`	會覆蓋 inline 的 `user:pass@`
`--proxy-password`	CLI	`--proxy-password=secret`	會出現在 `ps` 裡——共用系統上請避免使用
`--no-proxy`	CLI	`--no-proxy`	會跳過所有來源的 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 + Proxy 不是最佳解？又該改用什麼？

講了這麼多 proxy 設定，這裡我要提出一個逆風觀點：有時候你其實根本不需要這些。

很多搜尋「wget proxy」的人，其實不是要下載單一檔案，而是想從網站蒐集結構化資料——像是商品價格、聯絡名單、不動產列表之類的內容，只是他們習慣性先想到 Wget。問題在於，Wget 只會給你原始 HTML。你還得自己解析、清理、整理格式。若再加上輪替 proxy 來避免封鎖，你就得同時維護 proxy 清單、下載腳本、解析器，以及匯出流程。

| 你的目標 | 最佳工具 | 原因 | |---|---|---|---| | 透過 proxy 下載單一檔案 | 搭配 proxy 參數的 wget | 簡單，一條指令就行 | | 透過 proxy 整站或整個目錄鏡像下載 | wget --recursive + proxy 設定 | Wget 的遞迴擷取本來就是強項 | | 擷取結構化資料（表格、清單、聯絡資訊） | Thunderbit | Wget 只會給你原始 HTML，後面還要自己解析。Thunderbit 的 AI 會直接讀取頁面，並把資料輸出成 Excel、Google Sheets、Airtable 或 Notion，完全不需要寫程式。它的雲端爬取還能處理 IP 輪替與反機器人機制，讓你連 proxy 設定都省掉。 | | 透過 proxy 執行 REST API 呼叫 | curl | 標頭控制更完整、原生支援 JSON、也支援 SOCKS5 | | 長期、排程式資料蒐集 | Thunderbit 排程爬蟲 或 cron + wget | Thunderbit 能隨頁面版型變動自動調整；cron + wget 腳本則常常默默失效 |

Wget 很擅長下載檔案。但如果你的流程是「設定 proxy → 輪替 IP → 下載 HTML → 寫 parser → 匯出到試算表」，那這麼多步驟其實很重。若這聽起來像你的情況，我們的 Chrome 擴充功能只要兩下點擊就能把整個流程處理完。想了解更多，可以看看我們關於 AI 網頁爬取和免寫程式網頁爬取的教學。

但如果你的目標是「透過企業 proxy 下載這個 ZIP 檔」——那 Wget 仍然是對的工具，而且現在你也知道該怎麼正確設定了。

重點整理

簡單來說：

四種方法，優先順序清楚： 命令列參數會覆蓋使用者設定檔，使用者設定檔會覆蓋系統設定檔，系統設定檔會覆蓋環境變數。--no-proxy 則能凌駕一切。
環境變數一律用小寫（http_proxy，不是 HTTP_PROXY）。大寫會被靜默忽略。
Proxy URL 一律保留 http://，即使是 https_proxy 也一樣。proxy 端點本身是 HTTP，HTTPS 是透過 CONNECT 隧道轉送。
.wgetrc 與 -e 參數中的布林值請用 on。 這是跨版本最穩的選擇。
Windows 使用者： 用 --config=C:\path\to\wgetrc 避免設定檔路徑不明確。Session 代理變數可用 set（CMD）或 $env:（PowerShell）設定。
企業 proxy 使用者： Wget 無法讀 PAC 檔，也不原生支援 NTLM 驗證。必要時可用 Cntlm 當本機轉接層。
把上面的速查表存起來——每次想不起來參數名稱時，它都能幫你省下重看整篇文章的時間。

如果你真正的目標是結構化資料擷取，Thunderbit 或 curl 可能更適合。最好的除錯流程，就是根本不用開始除錯。

常見問題

1. Wget 支援 SOCKS5 proxy 嗎？

不支援。GNU Wget 1.x 只支援 HTTP、HTTPS 與 FTP proxy。Wget2 專案雖然曾有人提出 SOCKS5 功能需求，但它不是標準的已文件化選項。如果你需要 SOCKS5，請改用 curl 的原生 socks5:// 或 socks5h://，或者用 proxychains4 包住 Wget，強制走 SOCKS 路由。

2. 為什麼我用大寫 `HTTP_PROXY` 時，proxy 設定會被忽略？

Wget 只會讀取小寫的環境變數名稱（http_proxy、https_proxy、ftp_proxy、no_proxy）。像 HTTP_PROXY 這類大寫版本會被靜默忽略——沒有錯誤、沒有警告。這是最常見也最惱人的問題之一，因為你完全看不出哪裡出錯。請一律使用小寫。

3. 要怎麼讓特定網域繞過 proxy？

使用 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 可以搭配輪替 proxy 使用嗎？

Wget 本身沒有內建 proxy 輪替功能。你有兩種做法：使用伺服器端會自動輪替 IP 的 proxy 服務商（讓你永遠連同一個 gateway 位址，但出口 IP 會變），或者寫一個 shell script，從清單中隨機挑選 proxy，並在每次執行時透過 -e http_proxy=... 傳入。若需求更複雜——像是自動輪替、重試邏輯、反機器人處理——通常還是專門的爬取工具更適合。

5. Wget 裡 `http_proxy` 和 `https_proxy` 有什麼差別？

當目標網址是 http:// 時，會使用 http_proxy。當目標網址是 https:// 時，會使用 https_proxy。但在這兩種情況下，proxy URL 本身通常都是 http:// 位址。對 HTTPS 目標來說，Wget 會先透過 proxy 發送 HTTP CONNECT 請求建立隧道，而真正的 HTTPS 加密會在 Wget 與目標伺服器之間端到端完成。proxy 只能看到 CONNECT 請求中的主機名稱，但無法讀取已加密的流量。

試用 Thunderbit，進行 AI 網頁爬取 Get Started Free

延伸閱讀