Wget में proxy set करना पहली नज़र में पाँच सेकंड का काम लगता है — जब तक आप एक घंटा यह समझने में नहीं लगा देते कि आपकी requests proxy को bypass क्यों कर रही हैं, और कोई error भी नहीं आ रही। यह मैंने seasoned sysadmins से लेकर junior devs तक, सबके साथ होते देखा है।
असल दिक्कत लगभग कभी proxy में नहीं होती। परेशानी होती है Wget के उन चार अलग-अलग स्थानों में जहाँ वह proxy settings पढ़ सकता है, गलत variable casing से होने वाली silent failures में, और corporate network की उन अजीब बातों में जिन्हें कोई man page समझाता ही नहीं। यह guide Wget को proxy के साथ configure करने के हर तरीके, कई methods के टकराने पर कौन-सा rule लागू होता है, हर common error का असली terminal output, और Windows तथा corporate firewall users के लिए एक अलग section कवर करती है — यानी वह audience जिसे लगभग हर दूसरी tutorial नज़रअंदाज़ कर देती है।
- कठिनाई: Beginner से Intermediate
- समय: पढ़ने और setup करने में लगभग 15 मिनट; एक बार समझ आने पर लगभग 2 मिनट
- आपको क्या चाहिए: एक working Wget installation (instructions नीचे हैं), proxy address (host + port), और चाहें तो proxy credentials
Structured Data Extraction के लिए Thunderbit आज़माएँ
Wget क्या है और इसे Proxy के साथ क्यों इस्तेमाल करें?
Wget एक command-line tool है जो browser के बिना internet से files और web pages डाउनलोड करता है। GNU की अपनी description इसे एक "non-interactive network downloader" कहती है — यानी यह background में चलता है, टूटे हुए transfers को फिर से शुरू करता है, और recursive downloads संभालता है, बिना किसी human click के।
इस context में proxy एक बीच का server होता है। आपकी machine target website से सीधे connect करने के बजाय Wget request proxy को भेजता है, और proxy उसे आगे forward करता है। इसके मुख्य कारण ये हो सकते हैं:
- Corporate firewall compliance — आपकी कंपनी चाहती है कि सारी outbound traffic approved proxy से होकर जाए
- Privacy और IP management — requests आपकी IP की बजाय proxy की IP से दिखाई देती हैं
- Geo-testing — region-locked resources लाना या किसी खास geography से CDN behavior test करना
- Data collection pipelines — research या monitoring के लिए rotating proxies से HTML डाउनलोड करना
- CI/CD environments — ऐसे locked-down build runners जहाँ internet तक सिर्फ proxy के ज़रिए पहुँचा जा सकता है
Wget अपने आप HTTP, HTTPS, और FTP proxies सपोर्ट करता है। यह SOCKS5 सपोर्ट नहीं करता। अगर आपको SOCKS5 चाहिए, तो curl native support देता है socks4://, socks5://, और socks5h:// schemes के लिए — या आप Wget को proxychains4 जैसे tool के साथ wrap कर सकते हैं।
Linux, macOS, और Windows पर Wget कैसे Install करें
Proxy configure करने से पहले आपके सिस्टम में Wget होना चाहिए। यह हिस्सा छोटा है — यह prerequisite है, main topic नहीं।
Linux (Debian/Ubuntu और RHEL/CentOS)
# Debian/Ubuntu
sudo apt update
sudo apt install wget
# RHEL/CentOS/Fedora
sudo dnf install wget
# Verify
wget --version
Ubuntu 24.04 LTS में Wget 1.21.4 आता है, जबकि Debian Trixie में 1.25.0 है। CentOS Stream 10 packages में 1.24.5 दिखता है.
macOS (Homebrew)
brew install wget
wget --version
Homebrew का formula अभी stable Wget 1.25.0 देता है, और पिछले साल में इसके 396,818 installs हुए हैं।
Windows (Chocolatey और Manual Install)
choco install wget
wget --version
Chocolatey का GNU Wget package 10 million से ज़्यादा total downloads दिखाता है, हालांकि अभी version 1.21.4 है। Binary आमतौर पर C:\ProgramData\chocolatey\bin\wget.exe में मिलती है।
Windows users के लिए एक ज़रूरी बात: Wget .wgetrc कहाँ खोजेगा, यह build पर निर्भर करता है। Details नीचे Windows section में हैं।
Proxy के साथ Wget इस्तेमाल करने के 4 तरीके (और कौन-सा चुनें)
चार methods हैं, और हर एक की scope व precedence अलग है:
- Command-line
-eflags — एक बार के लिए, single command - User config file (
~/.wgetrc) — आपके चलाए गए हर Wget command पर लागू - System config file (
/etc/wgetrc) — मशीन के सभी users पर लागू - Environment variables (
http_proxy,https_proxy) — पूरे shell session पर लागू
Method 1: Command-Line Flags (One-Off Proxy)
Quick test के लिए best। Command खत्म होते ही settings भी खत्म।
wget -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://example.com/file.zip
HTTPS targets के लिए:
wget -e use_proxy=on -e https_proxy=http://HOST:PORT/ https://example.com/
Quick smoke test — proxy के through अपना apparent IP देखें:
wget -qO- -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://ifconfig.me
अगर output में आपकी IP की जगह proxy की IP दिखती है, तो setup सही है।
Method 2: User Config File (~/.wgetrc)
इन lines को ~/.wgetrc में जोड़ें (file न हो तो बना लें):
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
= के आसपास spaces ध्यान से देखें — यही documented .wgetrc syntax है। अब इस user के हर Wget command पर proxy लागू होगा।
Method 3: System-Wide Config (/etc/wgetrc)
~/.wgetrc जैसे ही directives हैं, लेकिन system config file में रखे जाते हैं। GNU इसे global startup file के रूप में document करता है — exact path आपके install prefix पर निर्भर करता है। Common locations:
/etc/wgetrc(ज़्यादातर Linux package managers)/usr/local/etc/wgetrc(कुछ Homebrew builds)wget --versionके output में "Wgetrc:" के नीचे दिखा path
यह shared servers, Docker containers, या किसी भी ऐसे environment में उपयोगी है जहाँ सभी users को एक ही proxy से route करना हो।
Method 4: Environment Variables (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 को affect करते हैं — सिर्फ Wget को नहीं। curl जैसे tools भी इन्हें उठा लेते हैं।
महत्वपूर्ण चेतावनी: Wget environment variable names केवल lowercase में पढ़ता है। HTTP_PROXY (uppercase) को चुपचाप ignore कर दिया जाता है। कोई error नहीं, कोई warning नहीं। exact terminal output मैं gotchas section में दिखाऊँगा, लेकिन अभी यह बात याद कर लेना बेहतर है।
Proxy Method Precedence: कई methods सेट हों तो कौन-सा override करता है?
अगर proxy environment variables में भी है, .wgetrc में भी है, और command line पर भी है, तो जीत किसकी होती है? यह बात साफ़-साफ़ कोई नहीं बताता, इसलिए मैंने test किया।
यह tested और documented precedence है:
| Priority | Method | Scope | Overrides |
|---|---|---|---|
| 1 (highest) | -e CLI flags | Single command | Everything |
| 2 | ~/.wgetrc | Current user | System config + env vars |
| 3 | /etc/wgetrc | System-wide | Env vars only |
| 4 (lowest) | http_proxy / https_proxy env vars | Shell session | Nothing |
मैंने Wget 1.25.0 पर हर level पर conflicting proxies सेट करके इसे verify किया। जब environment port 3128 पर था, config file 3129 पर, और CLI 3130 पर:
- Config environment पर भारी पड़ा: Wget ने 3128 की बजाय 3129 से connect किया।
- CLI config पर भारी पड़ा: Wget ने 3129 और 3128 दोनों को ignore करके 3130 से connect किया।
इससे निकलने का तरीका है --no-proxy। यह जहाँ भी proxy set हो, उसे bypass कर देता है:
wget --no-proxy https://internal-server.company.com/report.pdf
Practical scenario: आपके sysadmin ने /etc/wgetrc में proxy set कर दिया है, लेकिन आपको internal server तक direct पहुँचना है। System config edit करने के बजाय उस एक command के लिए --no-proxy इस्तेमाल करें।
Authenticated Proxy के साथ Wget कैसे इस्तेमाल करें
ज़्यादातर business और residential proxies में username और password चाहिए होता है। Wget इसे दो तरीकों से सपोर्ट करता है, और दोनों proxy credentials के लिए HTTP Basic authentication इस्तेमाल करते हैं।
Proxy URL में Inline Credentials
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 Flags का उपयोग
wget --proxy-user=USERNAME --proxy-password=PASSWORD \
-e use_proxy=on \
-e http_proxy=http://proxy.company.com:8080/ \
http://example.com/file.zip
ये flags proxy URL में embedded user:pass@ को override कर देते हैं।
Credentials को सुरक्षित कैसे रखें
दोनों methods credentials leak कर सकते हैं। GNU चेतावनी देता है कि command line पर passwords ps या process-list tools में दिख सकते हैं। बचाव के तरीके:
- Single-user machines: Credentials को
~/.wgetrcमें रखें और file lock करें:chmod 600 ~/.wgetrc - CI/CD pipelines: GitHub Actions encrypted secrets या अपनी platform की equivalent सुविधा इस्तेमाल करें। Step definition में इन्हें lowercase environment variables के रूप में pass करें — YAML में hardcode कभी न करें
- Docker builds: Secrets के लिए
ARGयाENVका इस्तेमाल न करें। Docker docs साफ़ warning देते हैं कि build arguments final image में रह सकते हैं। इसके बजाय BuildKit secret mounts का उपयोग करें - Version control:
.wgetrcको credentials के साथ कभी commit न करें। इसे.gitignoreमें जोड़ें
GitHub Actions के लिए Wget-specific nuance: convention के हिसाब से secret names uppercase होते हैं, लेकिन Wget को expose किए गए environment variables lowercase होने चाहिए (http_proxy, HTTP_PROXY नहीं)।
Windows पर और Corporate Firewalls के पीछे Wget को Proxy के साथ कैसे चलाएँ
इस topic पर ज़्यादातर articles बस "Chocolatey से install करो" तक रुक जाते हैं। अगर आप Windows पर हैं या corporate proxy के पीछे हैं, तो वहीं से आपकी असली समस्याएँ शुरू होती हैं।
Windows में .wgetrc कहाँ खोजा जाता है
GNU documentation कहती है कि Wget $HOME/.wgetrc पढ़ता है, जब तक WGETRC environment variable किसी और जगह की ओर न इशारा करे। Windows पर $HOME, %USERPROFILE% (जैसे C:\Users\alice) से map हो सकता है — या नहीं भी — यह इस पर निर्भर करता है कि आप Chocolatey build, MSYS2 build, Git Bash, या standalone binary इस्तेमाल कर रहे हैं या नहीं।
मेरा सुझाव: अनुमान लगाने की बजाय deterministic behavior के लिए --config flag इस्तेमाल करें:
wget --config=C:\Users\alice\wgetrc https://example.com/file.zip
यह जांचने के लिए कि आपका build किसी खास location से config file पढ़ता है या नहीं, एक test file बनाइए जो किसी clearly-bad 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 से connect करने की कोशिश करता है, तो उसने file पढ़ ली।
Windows पर Proxy Environment Variables कैसे सेट करें
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/
Permanent (reboot के बाद भी बना रहे):
setx http_proxy http://HOST:PORT/
setx https_proxy http://HOST:PORT/
setx के बाद आपको एक नई terminal window खोलनी होगी। Current session में बदलाव नहीं दिखेगा।
Corporate Proxy की आम उलझनें: PAC Files, NTLM Auth, और Proxy Address कैसे ढूँढ़ें
Corporate users को हर बार जिन तीन चीज़ों से दिक्कत होती है:
PAC files: कई कंपनियाँ Proxy Auto-Configuration (PAC) files इस्तेमाल करती हैं — JavaScript-based scripts जो browser को बताते हैं कि कौन-सी URL के लिए कौन-सा proxy उपयोग करना है। Wget में JavaScript interpreter नहीं होता, इसलिए यह PAC files पढ़ नहीं सकता। Curl documentation भी यही कहती है। उपाय: PAC file खोलें (या IT से पूछें), अपने target domain के लिए PROXY host:port result खोजें, और वही static address Wget में configure करें।
NTLM authentication: Wget की proxy authentication सिर्फ Basic auth implement करती है। अगर आपका corporate proxy NTLM मांगता है और आपको 407 Proxy Authentication Required मिल रहा है, तो --proxy-user की अलग-अलग syntax आज़माने में समय मत गँवाइए। Cntlm install करें — यह एक local relay है जो NTLM/NTLMv2 authentication संभालता है और Wget को Basic-auth interface देता है। Cntlm अभी भी maintained है (last update October 2025, लगभग 395 downloads/week)।
Corporate proxy users के लिए decision tree:
set http_proxy=http://YOUR_PROXY:PORT/करें और Wget चलाएँ।- अगर
407error आए और आपकी company NTLM इस्तेमाल करती हो → Cntlm install करें, इसे अपने domain credentials से configure करें, और Wget को Cntlm के local port पर point करें (आमतौर परhttp://127.0.0.1:3128/)। - अगर company PAC file इस्तेमाल करती है → PAC file से असली
PROXY host:portनिकालें या static proxy address के लिए IT से पूछें।
Common corporate proxy ports: 3128 (Squid-style), 8080 (general HTTP proxy), 8888 (Fiddler/Charles जैसे debugging proxies)। ये conventions हैं, guarantees नहीं।
Proxy के साथ Wget इस्तेमाल करते समय आम गलतियाँ (असल Error Output के साथ)
अब आता है title में वादा किया गया असली payoff। नीचे दिया गया हर output Wget 1.25.0 (macOS, Homebrew) पर 2026-06-01 को reproduce किया गया था।
गलती 1: http:// Prefix न होना
कुछ पुराने guides कहते हैं कि इससे हमेशा समस्या होती है। लेकिन 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 से connect कर रहा था। लेकिन फिर भी मैं सलाह दूँगा कि proxy URL में हमेशा http:// prefix और trailing slash शामिल करें। इससे Wget versions के बीच ambiguity कम होती है और credential syntax (http://user:pass@host:port/) भी साफ़ रहती है।
गलती 2: use_proxy=yes बनाम use_proxy=on
मेरे Wget 1.25.0 tests में yes और on दोनों चले। लेकिन invalid values एक साफ़ error के साथ fail होते हैं:
wget: use_proxy: Invalid boolean 'true'; use `on' or `off'.
Broadest compatibility के लिए on इस्तेमाल करें — यह manual के documented boolean format और Wget की अपनी error hint दोनों से मेल खाता है।
गलती 3: Uppercase HTTP_PROXY का चुपचाप ignore होना
यह सबसे frustrating गलती है क्योंकि कोई error ही नहीं आता। Wget बस direct connect कर देता है, जैसे आपने proxy set ही न किया हो।
Uppercase (गलत — 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
Lowercase (सही — 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.
फर्क दिखा? Uppercase version ने example.com को सीधे resolve किया। Lowercase version ने proxy try किया। दोनों में warning नहीं आई। Curl में भी ऐसा ही व्यवहार है — वह ज़्यादातर proxy variables के लिए uppercase स्वीकार करता है, लेकिन security reasons से uppercase HTTP_PROXY को explicitly reject करता है।
Fix: हमेशा lowercase http_proxy और https_proxy इस्तेमाल करें।
गलती 4: .wgetrc में पुराना Proxy होने से "Connection Refused" आना
अगर आपने (या आपके sysadmin ने, या किसी Docker image ने) config file में पुराना proxy address छोड़ दिया, तो ऐसा error मिलेगा:
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 पुराने proxy IP की ओर इशारा करता है, target site की ओर नहीं। Diagnose करने का क्रम (precedence hierarchy के अनुसार):
- अपने command में
-eflags या shell aliases जांचें ~/.wgetrc(याWGETRCसे बताए गए file) को देखें- system config देखें (
wget --versionमें दिखा path) - environment जांचें:
env | grep -i proxy
Debugging के लिए --no-config आपका दोस्त है — यह Wget को सभी config files छोड़ने को कहता है:
wget --no-config --spider http://example.com/
अगर यह काम करता है, तो समस्या config file में है।
गलती 5: HTTPS Proxy Syntax को लेकर भ्रम
यह बहुत लोगों को उलझाता है। जब आप https_proxy सेट करते हैं, तो proxy URL आम तौर पर http:// होता है, https:// नहीं। क्योंकि Wget proxy के through एक HTTP CONNECT request भेजता है, ताकि encrypted HTTPS session के लिए tunnel बने।
सही:
https_proxy=http://proxy.company.com:8080/
wget https://example.com/
Wget proxy को CONNECT example.com:443 HTTP/1.1 भेजता है, फिर HTTPS को उसके through tunnel करता है।
गलत (HTTP target URLs के लिए HTTPS proxy endpoint के रूप में):
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 targets के लिए proxy URL में https:// को सीधे reject कर देता है। जब तक आपकी organization ने खास तौर पर HTTPS proxy endpoint document न किया हो और आपने उसे अपने Wget build पर test न किया हो, https_proxy=http://HOST:PORT/ ही इस्तेमाल करें।
Wget Proxy Command Cheat Sheet (बुकमार्क करने लायक Quick Reference)
इस table को bookmark कर लें। इसमें proxy से जुड़े हर Wget flag और config directive एक जगह दिए गए हैं।
| Flag / Directive | Context | Example | Notes |
|---|---|---|---|
-e use_proxy=on | CLI | -e use_proxy=on | on सबसे सुरक्षित है; कुछ builds yes भी स्वीकार करते हैं |
-e http_proxy= | CLI | -e http_proxy=http://proxy:8080/ | http:// prefix और trailing / शामिल करें |
-e https_proxy= | CLI | -e https_proxy=http://proxy:8080/ | HTTPS targets के लिए भी proxy URL आम तौर पर http:// ही होता है |
--proxy-user | CLI | --proxy-user=admin | Inline user:pass@ को override करता है |
--proxy-password | CLI | --proxy-password=secret | ps में दिख सकता है — shared systems पर बचें |
--no-proxy | CLI | --no-proxy | हर source से आने वाली ALL proxy settings bypass करता है |
--no-config | CLI | --no-config | सभी config files छोड़ देता है — debugging के लिए उपयोगी |
--config=FILE | CLI | --config=/tmp/wgetrc | Deterministic config path — Windows और CI के लिए बढ़िया |
http_proxy | .wgetrc / env | http_proxy = http://proxy:8080/ | Config file में = के आसपास spaces होते हैं; env var lowercase होता है |
https_proxy | .wgetrc / env | https_proxy = http://proxy:8080/ | Format वही है जो http_proxy का है |
ftp_proxy | .wgetrc / env | ftp_proxy = http://proxy:8080/ | FTP retrievals के लिए |
no_proxy | .wgetrc / env | no_proxy = localhost,127.0.0.1,.corp | Comma-separated domain list |
proxy_user | .wgetrc | proxy_user = admin | --proxy-user के बराबर |
proxy_password | .wgetrc | proxy_password = secret | File को chmod 600 से सुरक्षित रखें |
जब Wget + Proxy सही Tool न हो (और उसकी जगह क्या इस्तेमाल करें)
इतनी proxy configuration के बाद एक अलग नज़रिया: कभी-कभी आपको यह सब करने की ज़रूरत ही नहीं होती।
"wget proxy" खोजने वाले बहुत से लोग असल में सिर्फ एक file डाउनलोड नहीं करना चाहते। वे websites से structured data इकट्ठा करना चाहते हैं — product prices, contact lists, real estate listings — और Wget इसलिए चुन लेते हैं क्योंकि वही command-line tool उन्हें आता है। समस्या यह है कि Wget आपको raw HTML देता है। उसे फिर भी parse, clean, और structure करना पड़ता है। और अगर blocks से बचने के लिए आप rotating proxies इस्तेमाल कर रहे हैं, तो अब आपको proxy list, download script, parser, और export pipeline — सब maintain करना पड़ रहा है।
| आपका लक्ष्य | सबसे अच्छा टूल | क्यों |
|---|---|---|
| Proxy के through एक single file डाउनलोड करना | Proxy flags के साथ wget | आसान, एक ही command |
| Proxy के through site या directory mirror करना | wget --recursive + proxy config | Wget की recursive retrieval इसकी core strength है |
| Structured data scrape करना (tables, listings, contacts) | Thunderbit | Wget raw HTML देता है — फिर भी parsing करनी पड़ती है। Thunderbit का AI page पढ़कर data को Excel, Google Sheets, Airtable, या Notion में बिना code के structured रूप में निकाल देता है। इसकी cloud scraping IP rotation और anti-bot measures संभालती है, इसलिए आपको proxy setup की ज़रूरत नहीं पड़ती। |
| Proxy के through REST API calls | curl | बेहतर header control, native JSON support, SOCKS5 support |
| नियमित scheduled data collection | Thunderbit Scheduled Scraper या cron + wget | Page layout बदलने पर Thunderbit adapt कर लेता है; cron + wget scripts चुपचाप टूट सकती हैं |
Wget file downloads के लिए शानदार है। लेकिन "proxy configure करो → IP rotate करो → HTML डाउनलोड करो → parser लिखो → spreadsheet में export करो" वाला workflow, तब बहुत भारी लगने लगता है जब असल में आपको data की table चाहिए होती है। अगर आपकी स्थिति ऐसी है, तो हमारा Chrome extension सिर्फ दो clicks में पूरा pipeline संभाल लेता है। इस approach पर और पढ़ने के लिए हमारे AI web scraping और बिना coding के web scraping guides देखें।
लेकिन अगर आपका लक्ष्य है "इस ZIP file को corporate proxy के through डाउनलोड करना" — तो Wget अभी भी सही tool है, और अब आप इसे सही तरह से configure करना जानते हैं।
मुख्य निष्कर्ष
संक्षेप में:
- चार methods, साफ़ precedence: CLI flags user config को override करते हैं, user config system config को, और system config environment variables को।
--no-proxyसब कुछ override करता है। - Environment variables के लिए हमेशा lowercase इस्तेमाल करें (
http_proxy,HTTP_PROXYनहीं)। Uppercase चुपचाप ignore हो जाता है। - Proxy URL में हमेशा
http://शामिल करें, भलेhttps_proxyही क्यों न हो। Proxy endpoint HTTP होता है; HTTPS को CONNECT के माध्यम से tunnel किया जाता है। .wgetrcऔर-eflags में boolean values के लिएonइस्तेमाल करें। Wget versions के बीच यही सबसे सुरक्षित विकल्प है।- Windows users: config-file ambiguity से बचने के लिए
--config=C:\path\to\wgetrcइस्तेमाल करें। Session proxy variables के लिएset(CMD) या$env:(PowerShell) प्रयोग करें। - Corporate proxy users: Wget PAC files नहीं पढ़ सकता और NTLM auth native रूप से सपोर्ट नहीं करता। ज़रूरत हो तो local relay के रूप में Cntlm इस्तेमाल करें।
- ऊपर दिया गया cheat sheet bookmark कर लें — flag name याद करने के लिए बार-बार article पढ़ने से बचेंगे।
अगर आपका असल लक्ष्य structured data extraction है, तो Thunderbit या curl बेहतर fit हो सकते हैं। सबसे अच्छी debugging session वही है जिसकी शुरुआत ही न करनी पड़े।
FAQs
1. क्या Wget SOCKS5 proxies सपोर्ट करता है?
नहीं। GNU Wget 1.x सिर्फ HTTP, HTTPS, और FTP proxies सपोर्ट करता है। Wget2 project में SOCKS5 एक feature request के रूप में मौजूद रहा है, लेकिन यह standard documented option नहीं है। SOCKS5 के लिए curl के native socks5:// या socks5h:// schemes इस्तेमाल करें, या Wget को proxychains4 के साथ wrap करें ताकि SOCKS routing force हो सके।
2. Uppercase HTTP_PROXY इस्तेमाल करने पर मेरी proxy setting ignore क्यों हो जाती है?
Wget environment variable names सिर्फ lowercase में पढ़ता है (http_proxy, https_proxy, ftp_proxy, no_proxy)। HTTP_PROXY जैसी uppercase variants चुपचाप ignore कर दी जाती हैं — न error, न warning। यह सबसे common और frustrating समस्याओं में से एक है, क्योंकि कोई संकेत ही नहीं मिलता कि कुछ गलत है। हमेशा lowercase ही इस्तेमाल करें।
3. Specific domains के लिए proxy कैसे bypass करें?
no_proxy directive इस्तेमाल करें, चाहे environment variable के रूप में हो या .wgetrc में:
export no_proxy=localhost,127.0.0.1,.mycompany.com
या ~/.wgetrc में:
no_proxy = localhost,127.0.0.1,.mycompany.com
Domains को comma से अलग किया जाता है। शुरू में dot (.mycompany.com) रखने से सभी subdomains match हो जाते हैं।
4. क्या मैं Wget को rotating proxies के साथ इस्तेमाल कर सकता हूँ?
Wget में built-in proxy rotation नहीं है। आपके पास दो रास्ते हैं: ऐसा proxy provider इस्तेमाल करें जो server-side IP rotate करता हो (आप हमेशा एक ही gateway address hit करते हैं, लेकिन exit IP बदलती रहती हैं), या एक shell script लिखें जो list से random proxy चुने और हर invocation में -e http_proxy=... के ज़रिए pass करे। इससे भी ज़्यादा complex चीज़ों — automatic rotation, retry logic, anti-bot handling — के लिए dedicated scraping tool आमतौर पर बेहतर होता है।
5. Wget में http_proxy और https_proxy में क्या अंतर है?
जब target URL http:// हो, तब http_proxy इस्तेमाल होता है। जब target URL https:// हो, तब https_proxy इस्तेमाल होता है। दोनों मामलों में proxy URL itself आमतौर पर http:// address होता है। HTTPS targets के लिए Wget proxy के through HTTP CONNECT request भेजता है ताकि tunnel बने, और actual HTTPS encryption सीधे Wget और target server के बीच end-to-end होती है। Proxy hostname को देख सकता है (CONNECT request से), लेकिन encrypted traffic नहीं पढ़ सकता।
AI Web Scraping के लिए Thunderbit आज़माएँ Get Started Free
और जानें
