การตั้งค่า proxy ให้ Wget ดูเหมือนจะเป็นเรื่องง่าย ๆ ใช้เวลาไม่กี่วินาที — จนกว่าคุณจะต้องนั่งเสียเวลาเป็นชั่วโมงเพื่อไล่หาว่าทำไมคำขอถึงวิ่งข้าม proxy ไปเฉย ๆ แบบไม่มีข้อความเตือนสักบรรทัด ผมเคยเห็นทั้ง sysadmin รุ่นเก๋าและนักพัฒนามือใหม่เจอปัญหานี้มานับครั้งไม่ถ้วน
สาเหตุหลักแทบไม่เคยอยู่ที่ proxy เอง แต่เป็นเพราะ Wget อ่านค่าพร็อกซีได้จาก 4 จุดที่ต่างกัน, ความล้มเหลวแบบเงียบ ๆ เวลาตั้งตัวแปรผิดตัวพิมพ์ใหญ่-เล็ก, และรายละเอียดจุกจิกของเครือข่ายองค์กรที่คู่มือหลายเล่มไม่เคยอธิบายให้เข้าใจตรง ๆ คู่มือนี้จะพาคุณไล่ดูทุกวิธีในการตั้งค่า Wget ให้ใช้ proxy, ลำดับความสำคัญที่แน่นอนเมื่อหลายวิธีชนกัน, ตัวอย่าง output จริงจากเทอร์มินัลสำหรับข้อผิดพลาดที่พบบ่อย, และส่วนพิเศษสำหรับผู้ใช้ Windows กับผู้ใช้ที่อยู่หลัง firewall ขององค์กร — กลุ่มที่บทความส่วนใหญ่มักทำเหมือนไม่มีตัวตนอยู่จริง
- ระดับความยาก: มือใหม่ถึงระดับกลาง
- เวลาที่ต้องใช้: อ่านและตั้งค่าประมาณ 15 นาที; เหลือราว 2 นาทีเมื่อคุณเข้าใจแล้ว
- สิ่งที่ต้องมี: ติดตั้ง Wget ได้ใช้งานจริง (มีวิธีด้านล่าง), ที่อยู่ proxy (host + port), และถ้าจำเป็นก็ข้อมูลล็อกอินของ proxy
ลองใช้ Thunderbit เพื่อดึงข้อมูลแบบมีโครงสร้าง
Wget คืออะไร และทำไมต้องใช้ร่วมกับพร็อกซี?
Wget คือเครื่องมือบรรทัดคำสั่งสำหรับดาวน์โหลดไฟล์และหน้าเว็บจากอินเทอร์เน็ตโดยไม่ต้องเปิดเบราว์เซอร์ คำอธิบายของ GNU เรียกมันว่า "non-interactive network downloader" — พูดง่าย ๆ คือมันทำงานเองได้เบื้องหลัง, ดาวน์โหลดต่อจากไฟล์ที่สะดุดค้างได้, และจัดการการดาวน์โหลดแบบ recursive ได้โดยไม่ต้องมีคนคอยกดอะไรเลย
ในบริบทนี้ proxy คือเซิร์ฟเวอร์ตัวกลาง แทนที่เครื่องของคุณจะเชื่อมไปยังเว็บไซต์ปลายทางโดยตรง Wget จะส่งคำขอไปยัง proxy แล้วให้ proxy ส่งต่อให้อีกที เหตุผลหลักที่คนมักใช้มีดังนี้:
- ทำตามข้อกำหนดของ firewall องค์กร — บริษัทบังคับให้ทราฟฟิกขาออกทั้งหมดต้องผ่าน proxy ที่อนุมัติแล้ว
- ความเป็นส่วนตัวและการจัดการ IP — ปลายทางจะเห็น IP ของ proxy ไม่ใช่ IP ของคุณ
- ทดสอบตามภูมิภาค — ดึงข้อมูลที่ล็อกตามประเทศ หรือทดสอบพฤติกรรม CDN จากภูมิภาคที่เฉพาะเจาะจง
- งานเก็บข้อมูล — ดาวน์โหลด HTML ผ่าน rotating proxy เพื่อใช้ในการวิจัยหรือเฝ้าระวัง
- สภาพแวดล้อม CI/CD — runner ที่อยู่ในเครือข่ายแบบปิดซึ่งออกอินเทอร์เน็ตได้ผ่าน proxy เท่านั้น
Wget รองรับ proxy แบบ HTTP, HTTPS และ FTP โดยตรง แต่ ไม่รองรับ SOCKS5 ถ้าคุณต้องใช้ SOCKS5, curl รองรับโดยตรง สำหรับ scheme socks4://, socks5://, และ socks5h:// — หรือจะห่อ Wget ด้วยเครื่องมืออย่าง proxychains4 ก็ได้
วิธีติดตั้ง Wget บน Linux, macOS และ Windows
ก่อนจะตั้งค่า 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
formula ของ Homebrew ตอนนี้ให้ Wget 1.25.0 รุ่นเสถียร และมียอดติดตั้ง 396,818 ครั้งในรอบปีที่ผ่านมา
Windows (Chocolatey และติดตั้งแบบแมนนวล)
choco install wget
wget --version
แพ็กเกจ GNU Wget ของ Chocolatey รายงานว่ายอดดาวน์โหลดรวมเกิน 10 ล้านครั้ง แม้ตอนนี้จะอยู่ที่เวอร์ชัน 1.21.4 โดยปกติไฟล์ binary จะอยู่ที่ C:\ProgramData\chocolatey\bin\wget.exe
ข้อควรรู้สำหรับผู้ใช้ Windows: ตำแหน่งที่ Wget จะมองหา .wgetrc อาจต่างกันตาม build รายละเอียดมีในส่วน Windows ด้านล่าง
4 วิธีใช้ Wget ร่วมกับพร็อกซี (และวิธีเลือกให้เหมาะ)
มี 4 วิธี แต่ละวิธีมีขอบเขตและลำดับความสำคัญต่างกัน:
- ตัวเลือก
-eบน command line — ใช้ครั้งเดียวกับคำสั่งเดียว - ไฟล์คอนฟิกของผู้ใช้ (
~/.wgetrc) — มีผลกับทุกคำสั่ง Wget ของ user นี้ - ไฟล์คอนฟิกของระบบ (
/etc/wgetrc) — มีผลกับทุก user บนเครื่อง - ตัวแปรสภาพแวดล้อม (
http_proxy,https_proxy) — มีผลกับทั้ง shell session
วิธีที่ 1: ตัวเลือกบน Command Line (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
ถ้า output แสดง IP ของ proxy แทน 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
สังเกตว่ามีช่องว่างรอบ = — นี่คือ syntax ของ .wgetrc ตามเอกสาร คำสั่ง Wget ทุกคำสั่งที่คุณรันในฐานะผู้ใช้นี้จะวิ่งผ่าน proxy อัตโนมัติ
วิธีที่ 3: คอนฟิกทั้งระบบ (/etc/wgetrc)
ใช้คำสั่งเดียวกับ ~/.wgetrc แต่ย้ายไปใส่ในไฟล์คอนฟิกของระบบแทน GNU ระบุว่านี่คือ global startup file โดยตำแหน่งจริงขึ้นกับ prefix ตอนติดตั้ง ตำแหน่งที่เจอบ่อยคือ:
/etc/wgetrc(แพ็กเกจ Linux ส่วนใหญ่)/usr/local/etc/wgetrc(บาง build ของ Homebrew)- พาธที่แสดงในผลลัพธ์
wget --versionตรงบรรทัด "Wgetrc:"
วิธีนี้เหมาะกับเซิร์ฟเวอร์ที่ใช้ร่วมกัน, Docker container, หรือสภาพแวดล้อมใด ๆ ที่ทุกคนควรออกอินเทอร์เน็ตผ่าน 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 session ไม่ใช่แค่ Wget เท่านั้น เครื่องมืออย่าง curl ก็จะอ่านค่าพวกนี้ด้วย
คำเตือนสำคัญ: Wget จะอ่านชื่อ environment variable เฉพาะแบบ ตัวพิมพ์เล็ก เท่านั้น HTTP_PROXY ที่เป็นตัวพิมพ์ใหญ่จะถูกเพิกเฉยแบบเงียบ ๆ ไม่มี error ไม่มี warning ไม่มีอะไรทั้งนั้น เดี๋ยวผมจะโชว์ output จริงในส่วนข้อผิดพลาดที่พบบ่อย แต่ขอให้จำเรื่องนี้ไว้ก่อนเลย
ลำดับความสำคัญของวิธีตั้งค่า proxy: อะไรทับอะไรเมื่อมีหลายวิธีพร้อมกัน
ถ้าคุณตั้ง proxy ไว้ทั้งใน environment variables, ใน .wgetrc, และใน command line แล้วอะไรจะมีสิทธิ์เหนือกว่า? ไม่มีใครอธิบายเรื่องนี้ชัด ๆ ผมเลยลองทดสอบเอง
นี่คือลำดับความสำคัญที่ได้จากการทดสอบและ เอกสารทางการ:
| ลำดับความสำคัญ | วิธี | ขอบเขต | สิ่งที่ทับได้ |
|---|---|---|---|
| 1 (สูงสุด) | flag -e บน CLI | คำสั่งเดียว | ทุกอย่าง |
| 2 | .wgetrc ของผู้ใช้ (~/.wgetrc) | ผู้ใช้ปัจจุบัน | คอนฟิกของระบบ + env vars |
| 3 | /etc/wgetrc | ทั้งระบบ | เฉพาะ env vars |
| 4 (ต่ำสุด) | env vars http_proxy / https_proxy | shell session | ไม่มีอะไร |
ผมยืนยันกับ Wget 1.25.0 โดยตั้ง proxy ขัดแย้งกันในแต่ละระดับ เมื่อ environment ชี้ไปที่พอร์ต 3128, ไฟล์คอนฟิกชี้ไปที่ 3129, และ CLI ชี้ไปที่ 3130:
- คอนฟิกชนะ environment: Wget ไปที่พอร์ต 3129 และไม่สนใจ 3128
- CLI ชนะคอนฟิก: Wget ไปที่พอร์ต 3130 และไม่สนใจทั้ง 3129 และ 3128
ทางลัดสำหรับปิด proxy คือ --no-proxy ซึ่งจะข้ามทุกการตั้งค่า proxy ไม่ว่าคุณจะตั้งไว้ตรงไหน:
wget --no-proxy https://internal-server.company.com/report.pdf
สถานการณ์จริง: sysadmin ของคุณตั้ง proxy ไว้ใน /etc/wgetrc แต่คุณต้องเข้าถึงเซิร์ฟเวอร์ภายในโดยตรง ใช้ --no-proxy แค่กับคำสั่งนั้นแทนการไปแก้ system config
วิธีใช้ Wget กับพร็อกซีที่ต้องยืนยันตัวตน
proxy สำหรับธุรกิจและที่อยู่อาศัยจำนวนมากต้องใช้ username กับ password Wget รองรับผ่าน 2 วิธี โดยทั้งคู่ใช้ HTTP Basic authentication สำหรับ credentials ของ proxy
ใส่ credentials ไว้ใน URL ของ proxy
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/
ใช้ flag --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
flag เหล่านี้จะทับค่าที่ฝังไว้ใน URL แบบ user:pass@
เก็บ credentials ให้ปลอดภัย
ทั้งสองวิธีมีโอกาสทำให้ข้อมูลล็อกอินรั่วได้ GNU เตือน ว่ารหัสผ่านที่ใส่บน command line สามารถมองเห็นได้ผ่าน ps หรือเครื่องมือดู process list วิธีลดความเสี่ยง:
- เครื่องส่วนตัวคนเดียวใช้: เก็บ credentials ใน
~/.wgetrcและล็อกสิทธิ์ไฟล์:chmod 600 ~/.wgetrc - CI/CD pipelines: ใช้ GitHub Actions encrypted secrets หรือระบบที่เทียบเท่าของแพลตฟอร์มคุณ ส่งออกเป็น lowercase environment variables ใน step definition — ห้าม hardcode ใน YAML เด็ดขาด
- Docker builds: อย่าใช้
ARGหรือENVสำหรับ secrets เอกสารของ Docker ระบุชัด ว่า build arguments อาจติดไปใน image สุดท้าย ให้ใช้ BuildKit secret mounts แทน - การควบคุมเวอร์ชัน: ห้าม commit
.wgetrcที่มี credentials เข้าไป ให้ใส่ใน.gitignore
ข้อแตกต่างเล็ก ๆ ของ Wget ใน GitHub Actions คือชื่อ secret มักถูกเก็บเป็นตัวพิมพ์ใหญ่ตามธรรมเนียม แต่ environment variables ที่เปิดให้ Wget ใช้ต้องเป็นตัวพิมพ์เล็ก (http_proxy ไม่ใช่ HTTP_PROXY)
วิธีใช้ Wget กับพร็อกซีบน Windows และหลัง corporate firewall
บทความส่วนใหญ่หยุดแค่คำว่า "ติดตั้งด้วย Chocolatey" แต่ถ้าคุณใช้ Windows หรืออยู่หลัง proxy ขององค์กร ปัญหามักจะเพิ่งเริ่มตรงนั้น
Wget มองหา .wgetrc ที่ไหนบน Windows
เอกสารของ GNU บอกว่า Wget จะอ่าน $HOME/.wgetrc เว้นแต่ตัวแปร WGETRC จะชี้ไปที่อื่น บน Windows ค่า $HOME อาจ map ไปที่ %USERPROFILE% (เช่น C:\Users\alice) หรืออาจไม่เป็นแบบนั้นก็ได้ — แล้วแต่คุณใช้ build ของ Chocolatey, build ของ MSYS2, Git Bash, หรือ binary แบบ standalone
คำแนะนำของผม: ไม่ต้องเดา ใช้ flag --config ไปเลยเพื่อให้ผลลัพธ์แน่นอน:
wget --config=C:\Users\alice\wgetrc https://example.com/file.zip
ถ้าจะทดสอบว่า build ของคุณอ่านไฟล์คอนฟิกจากตำแหน่งใดตำแหน่งหนึ่งจริงไหม ให้สร้างไฟล์ทดสอบที่ชี้ไปยัง 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 แปลว่ามันอ่านไฟล์นั้นจริง
ตั้งค่า environment variables ของ proxy บน Windows
CMD (เฉพาะ session):
set http_proxy=http://HOST:PORT/
set https_proxy=http://HOST:PORT/
wget http://example.com/
PowerShell (เฉพาะ session):
$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 แล้ว คุณต้องเปิดหน้าต่างเทอร์มินัล ใหม่ session ปัจจุบันจะยังไม่เห็นการเปลี่ยนแปลง
ข้อควรระวังเรื่อง proxy ในองค์กร: PAC files, NTLM auth, และวิธีหา proxy address
มี 3 เรื่องที่มักทำให้ผู้ใช้ในองค์กรสะดุดเป็นประจำ:
PAC files: หลายองค์กรใช้ Proxy Auto-Configuration (PAC) files — เป็นสคริปต์ JavaScript ที่บอกเบราว์เซอร์ว่า URL ไหนควรใช้ proxy ตัวไหน Wget ไม่มี JavaScript interpreter ดังนั้นมัน อ่าน PAC files ไม่ได้ curl ก็อธิบายไว้แบบเดียวกัน วิธีแก้คือเปิดไฟล์ PAC (หรือถาม IT) แล้วหาค่า PROXY host:port สำหรับโดเมนเป้าหมาย จากนั้นเอา address แบบ static นั้นมาใส่ใน Wget
NTLM authentication: การยืนยันตัวตนของ proxy ใน Wget รองรับแค่ Basic auth ถ้า proxy ขององค์กรต้องใช้ NTLM แล้วคุณเจอ 407 Proxy Authentication Required อย่าเสียเวลากับการลอง --proxy-user หลายรูปแบบ ให้ติดตั้ง Cntlm — ตัว relay ภายในเครื่องที่จัดการการยืนยันตัวตนแบบ NTLM/NTLMv2 แล้วแปลงให้ Wget คุยผ่าน Basic-auth interface แทน Cntlm ยังมีการดูแลอยู่ (อัปเดตล่าสุดตุลาคม 2025, ประมาณ ~395 ดาวน์โหลด/สัปดาห์)
แนวทางตัดสินใจสำหรับผู้ใช้ proxy ในองค์กร:
- ลอง
set http_proxy=http://YOUR_PROXY:PORT/แล้วรัน Wget - ถ้าเจอ error
407และบริษัทใช้ NTLM → ติดตั้ง Cntlm, ตั้งค่าด้วย domain credentials ของคุณ, แล้วชี้ Wget ไปยัง local port ของ Cntlm (โดยทั่วไปคือhttp://127.0.0.1:3128/) - ถ้าบริษัทใช้ PAC file → ดึงค่า
PROXY host:portที่แท้จริงจาก PAC file หรือขอ static proxy address จาก IT
พอร์ต proxy ในองค์กรที่พบบ่อย: 3128 (สไตล์ Squid), 8080 (HTTP proxy ทั่วไป), 8888 (proxy สำหรับ debug เช่น Fiddler/Charles) ซึ่งทั้งหมดเป็นเพียงธรรมเนียม ไม่ใช่ข้อบังคับ
ข้อผิดพลาดที่พบบ่อยเมื่อใช้ Wget กับพร็อกซี (พร้อม error output จริง)
มาถึงส่วนที่สัญญาไว้ตั้งแต่หัวข้อด้านบนกันแล้ว ตัวอย่าง output ด้านล่างทั้งหมดทดสอบซ้ำบน Wget 1.25.0 (macOS, Homebrew) ณ วันที่ 2026-06-01
ข้อผิดพลาด 1: ลืมใส่ prefix 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:// และ slash ปิดท้ายเสมอ เพราะจะช่วยลดความกำกวมระหว่างเวอร์ชันของ Wget และทำให้รูปแบบ credentials (http://user:pass@host:port/) ชัดเจนกว่า
ข้อผิดพลาด 2: use_proxy=yes กับ use_proxy=on
จากการทดสอบของผมบน Wget 1.25.0 ทั้ง yes และ on ใช้ได้ แต่ถ้าใส่ค่าที่ไม่ถูกต้องจะมี error ชัดเจน:
wget: use_proxy: Invalid boolean 'true'; use `on' or `off'.
ใช้ on จะปลอดภัยและเข้ากันได้กว้างที่สุด — มันตรงกับ รูปแบบ boolean ที่คู่มือระบุ และตรงกับคำแนะนำจาก error ของ Wget เอง
ข้อผิดพลาด 3: HTTP_PROXY ตัวพิมพ์ใหญ่ถูกเพิกเฉยแบบเงียบ ๆ
นี่เป็นปัญหาที่น่าหงุดหงิดที่สุด เพราะ ไม่มี error เลย 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.
เห็นความต่างไหม? แบบตัวพิมพ์ใหญ่ resolve example.com โดยตรง ส่วนแบบตัวพิมพ์เล็กพยายามใช้ proxy แต่ไม่มีคำเตือนทั้งคู่ curl ก็มีพฤติกรรมคล้ายกัน — มันรับ proxy variables แบบตัวพิมพ์ใหญ่ได้ส่วนใหญ่ แต่จะปฏิเสธ HTTP_PROXY แบบตัวพิมพ์ใหญ่โดยตรงด้วยเหตุผลด้านความปลอดภัย
วิธีแก้: ใช้ http_proxy และ https_proxy แบบตัวพิมพ์เล็กเสมอ
ข้อผิดพลาด 4: proxy เก่าใน .wgetrc ทำให้ขึ้น "Connection Refused"
ถ้าคุณ (หรือ sysadmin หรือ image ใน Docker) ลืมทิ้ง address เก่าของ 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.
error จะชี้ไปที่ IP ของ proxy เก่า ไม่ใช่เว็บไซต์ปลายทาง ลำดับการตรวจสอบควรเป็นตาม hierarchy ของ precedence:
- ตรวจคำสั่งของคุณว่ามี
-eflags หรือ shell alias หรือไม่ - ตรวจ
~/.wgetrc(หรือไฟล์ที่ระบุโดยWGETRC) - ตรวจคอนฟิกของระบบ (พาธที่
wget --versionแสดง) - ตรวจ environment:
env | grep -i proxy
สำหรับดีบัก --no-config คือเพื่อนที่ดีที่สุด เพราะมันบอกให้ Wget ข้ามทุกไฟล์คอนฟิก:
wget --no-config --spider http://example.com/
ถ้าวิธีนี้ใช้ได้ แปลว่าปัญหาอยู่ในไฟล์คอนฟิกแน่นอน
ข้อผิดพลาด 5: สับสนเรื่อง syntax ของ HTTPS proxy
หลายคนมักงงตรงนี้ เวลาเราตั้ง https_proxy ตัว URL ของ proxy เองมักจะเป็น http:// ไม่ใช่ https:// เพราะ Wget จะส่ง HTTP CONNECT request ผ่าน proxy เพื่อสร้าง tunnel สำหรับ session HTTPS ที่เข้ารหัส
ถูกต้อง:
https_proxy=http://proxy.company.com:8080/
wget https://example.com/
Wget จะส่ง CONNECT example.com:443 HTTP/1.1 ไปยัง proxy แล้วค่อย tunnel HTTPS ผ่านตรงนั้น
ไม่ถูกต้อง (สำหรับ target URL แบบ HTTP ที่ชี้ไปยัง proxy endpoint แบบ 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 ปฏิเสธ https:// ในฐานะ proxy URL สำหรับ target แบบ HTTP แบบตรง ๆ เลย ใช้ https_proxy=http://HOST:PORT/ เว้นแต่องค์กรของคุณจะระบุ endpoint แบบ HTTPS proxy ไว้ชัดเจน และคุณได้ทดสอบกับ build ของ Wget เรียบร้อยแล้ว
ชีตคำสั่ง Wget สำหรับพร็อกซี (อ้างอิงเร็วแบบ bookmark ได้)
บันทึกตารางนี้ไว้เลย มันรวบรวม flag และ directive ทุกตัวของ Wget ที่เกี่ยวกับ proxy เอาไว้ในที่เดียว
| Flag / Directive | บริบท | ตัวอย่าง | หมายเหตุ |
|---|---|---|---|
-e use_proxy=on | CLI | -e use_proxy=on | on ปลอดภัยที่สุด; บาง build ก็รับ yes ได้ |
-e http_proxy= | CLI | -e http_proxy=http://proxy:8080/ | ใส่ prefix http:// และ slash ปิดท้าย |
-e https_proxy= | CLI | -e https_proxy=http://proxy:8080/ | URL ของ proxy มักเป็น http:// แม้ปลายทางจะเป็น HTTPS |
--proxy-user | CLI | --proxy-user=admin | ทับค่า user:pass@ ที่ฝังใน URL |
--proxy-password | CLI | --proxy-password=secret | มองเห็นได้ใน ps — ควรเลี่ยงบนระบบที่ใช้ร่วมกัน |
--no-proxy | CLI | --no-proxy | ข้ามการตั้งค่า proxy ทุกแหล่ง |
--no-config | CLI | --no-config | ข้ามไฟล์คอนฟิกทั้งหมด — ดีสำหรับการดีบัก |
--config=FILE | CLI | --config=/tmp/wgetrc | ระบุ path คอนฟิกแบบแน่นอน — เหมาะมากสำหรับ Windows และ CI |
http_proxy | .wgetrc / env | http_proxy = http://proxy:8080/ | ไฟล์คอนฟิกใช้ช่องว่างรอบ =; env var ใช้ตัวพิมพ์เล็ก |
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 ดิบ ๆ กลับมา คุณยังต้อง parse, clean และจัดโครงสร้างต่อเอง และถ้าคุณใช้ rotating proxy เพื่อเลี่ยงการถูกบล็อก ตอนนี้คุณต้องดูแลทั้งลิสต์ proxy, สคริปต์ดาวน์โหลด, parser, และ pipeline สำหรับส่งออกข้อมูลไปด้วย
| เป้าหมายของคุณ | เครื่องมือที่เหมาะที่สุด | เพราะอะไร |
|---|---|---|
| ดาวน์โหลดไฟล์เดี่ยวผ่าน proxy | wget พร้อม proxy flags | ง่าย ใช้คำสั่งเดียวจบ |
| mirror เว็บไซต์หรือไดเรกทอรีผ่าน proxy | wget --recursive + ตั้งค่า proxy | การดึงแบบ recursive คือจุดแข็งหลักของ Wget |
| ดึงข้อมูลแบบมีโครงสร้าง (ตาราง, รายการ, รายชื่อผู้ติดต่อ) | Thunderbit | Wget ให้แค่ HTML ดิบ — คุณยังต้อง parse เอง แต่ Thunderbit ใช้ AI อ่านหน้าเว็บแล้วส่งออกเป็นข้อมูลมีโครงสร้างไปยัง Excel, Google Sheets, Airtable หรือ Notion โดยไม่ต้องเขียนโค้ด การ scrape บน cloud ยังช่วยจัดการ IP rotation และมาตรการกันบอท ทำให้คุณข้ามขั้นตอนตั้งค่า proxy ไปได้เลย |
| เรียก REST API ผ่าน proxy | curl | ควบคุม header ได้ดีกว่า และรองรับ JSON / SOCKS5 แบบ native |
| เก็บข้อมูลตามกำหนดอย่างต่อเนื่อง | Thunderbit Scheduled Scraper หรือ cron + wget | Thunderbit ปรับตัวเมื่อ layout ของหน้าเว็บเปลี่ยน แต่สคริปต์ cron + wget มักพังแบบเงียบ ๆ |
Wget เก่งเรื่องดาวน์โหลดไฟล์มาก แต่เวิร์กโฟลว์แบบ "ตั้ง proxy → หมุน IP → ดาวน์โหลด HTML → เขียน parser → export เป็นสเปรดชีต" มีหลายจุดที่ต้องดูแล ถ้าสิ่งที่คุณต้องการจริง ๆ คือข้อมูลในรูปแบบตาราง Chrome extension ของเรา ก็จัดการทั้งกระบวนการได้ใน 2 คลิก ถ้าอยากอ่านแนวทางนี้เพิ่มเติม ดูคู่มือเรื่อง AI web scraping และ web scraping without coding
แต่ถ้าเป้าหมายของคุณคือ "ดาวน์โหลดไฟล์ ZIP นี้ผ่าน corporate proxy" — Wget ก็ยังเป็นตัวเลือกที่ใช่ และตอนนี้คุณก็รู้วิธีตั้งค่าให้ถูกต้องแล้ว
ประเด็นสำคัญที่ควรจำ
สรุปสั้น ๆ:
- มี 4 วิธีและมีลำดับความสำคัญชัดเจน: flag บน CLI ทับ user config, user config ทับ system config, และ system config ทับ environment variables ส่วน
--no-proxyจะทับทุกอย่าง - ใช้ตัวพิมพ์เล็กเสมอ สำหรับ environment variables (
http_proxyไม่ใช่HTTP_PROXY) เพราะตัวพิมพ์ใหญ่จะถูกเพิกเฉยแบบเงียบ ๆ - ใส่
http://ใน proxy URL เสมอ แม้กับhttps_proxyเพราะ endpoint ของ proxy เองเป็น HTTP แล้วค่อย tunnel HTTPS ผ่าน CONNECT - ใช้ค่า
onสำหรับ boolean ใน.wgetrcและใน-eflags เป็นตัวเลือกที่เข้ากันได้ดีที่สุดกับหลายเวอร์ชันของ Wget - ผู้ใช้ Windows: ใช้
--config=C:\path\to\wgetrcเพื่อหลีกเลี่ยงความกำกวมของไฟล์คอนฟิก และใช้set(CMD) หรือ$env:(PowerShell) สำหรับตัวแปร proxy แบบ session - ผู้ใช้ proxy ในองค์กร: Wget อ่าน PAC files ไม่ได้ และไม่รองรับ NTLM auth แบบ native ถ้าจำเป็นให้ใช้ Cntlm เป็น local relay
- บุ๊กมาร์กชีตคำสั่งด้านบน ไว้ — จะช่วยไม่ต้องกลับมาอ่านบทความนี้ซ้ำทุกครั้งที่ลืมชื่อ flag
ถ้าเป้าหมายจริงของคุณคือการดึงข้อมูลแบบมีโครงสร้าง Thunderbit หรือ curl อาจเหมาะกว่า การดีบักที่ดีที่สุดคือการดีบักที่คุณไม่ต้องเริ่มมันตั้งแต่แรก
คำถามที่พบบ่อย
1. Wget รองรับ proxy แบบ SOCKS5 ไหม?
ไม่รองรับ GNU Wget 1.x รองรับเฉพาะ proxy แบบ HTTP, HTTPS และ FTP เท่านั้น โปรเจกต์ Wget2 เคยมีคำขอฟีเจอร์ SOCKS5 แต่ยังไม่ใช่ตัวเลือกมาตรฐานที่มีเอกสารรองรับ ถ้าจะใช้ SOCKS5 ให้ใช้ curl กับ scheme socks5:// หรือ socks5h:// แบบ native หรือห่อ Wget ด้วย proxychains4 เพื่อบังคับ route ผ่าน SOCKS
2. ทำไมการตั้งค่า proxy ถึงถูกเพิกเฉยเมื่อใช้ HTTP_PROXY ตัวพิมพ์ใหญ่?
Wget จะอ่านเฉพาะชื่อ environment variable แบบตัวพิมพ์เล็ก (http_proxy, https_proxy, ftp_proxy, no_proxy) เท่านั้น ตัวแปรแบบตัวพิมพ์ใหญ่ เช่น HTTP_PROXY จะถูกเพิกเฉยแบบเงียบ ๆ — ไม่มี error ไม่มี warning นี่เป็นหนึ่งในปัญหาที่พบบ่อยและน่าหงุดหงิดที่สุดเพราะไม่มีสัญญาณบอกเลยว่ามีอะไรผิด ใช้ตัวพิมพ์เล็กเสมอ
3. จะ bypass proxy สำหรับบางโดเมนได้อย่างไร?
ใช้ directive no_proxy ได้ทั้งในรูป environment variable และใน .wgetrc:
export no_proxy=localhost,127.0.0.1,.mycompany.com
หรือใน ~/.wgetrc:
no_proxy = localhost,127.0.0.1,.mycompany.com
โดเมนให้คั่นด้วยจุลภาค และถ้าใส่จุดนำหน้า (.mycompany.com) จะตรงกับทุก subdomain
4. ใช้ Wget กับ rotating proxies ได้ไหม?
Wget เองไม่มีระบบหมุน proxy ในตัว คุณมี 2 ทางเลือก: ใช้ผู้ให้บริการ proxy ที่หมุน IP ฝั่งเซิร์ฟเวอร์ให้เลย (คุณจะเห็น gateway address เดิม แต่ IP ปลายทางเปลี่ยน), หรือเขียน shell script ให้สุ่ม proxy จากรายการแล้วส่งผ่าน -e http_proxy=... ทุกครั้งที่เรียก หากต้องซับซ้อนกว่านั้น — เช่น rotation อัตโนมัติ, retry logic, การรับมือ anti-bot — เครื่องมือสำหรับ scraping โดยเฉพาะมักเหมาะกว่า
5. ความต่างระหว่าง http_proxy กับ https_proxy ใน Wget คืออะไร?
http_proxy จะถูกใช้เมื่อ URL ปลายทางเป็น http:// ส่วน https_proxy จะถูกใช้เมื่อ URL ปลายทางเป็น https:// ในทั้งสองกรณี URL ของ proxy เองโดยทั่วไปยังเป็น http:// สำหรับปลายทางแบบ HTTPS, Wget จะส่ง HTTP CONNECT request ผ่าน proxy เพื่อสร้าง tunnel และการเข้ารหัส HTTPS จริง ๆ จะเกิดแบบ end-to-end ระหว่าง Wget กับเซิร์ฟเวอร์ปลายทาง proxy จะเห็น hostname จาก CONNECT request แต่จะอ่านข้อมูลที่เข้ารหัสไม่ได้
ลองใช้ Thunderbit สำหรับ AI Web Scraping Get Started Free
เรียนรู้เพิ่มเติม
