Πώς να χρησιμοποιήσετε το Wget με proxy (και να αποφύγετε τα συνηθισμένα λάθη)

Η ρύθμιση proxy στο Wget μοιάζει με δουλειά πέντε δευτερολέπτων — μέχρι να περάσει μία ώρα προσπαθώντας να καταλάβετε γιατί τα αιτήματά σας παρακάμπτουν εντελώς το proxy, χωρίς κανένα μήνυμα σφάλματος. Το έχω δει να συμβαίνει τόσο σε έμπειρους sysadmins όσο και σε junior devs.

Η βασική αιτία σχεδόν ποτέ δεν είναι το ίδιο το proxy. Είναι τα τέσσερα διαφορετικά σημεία από τα οποία μπορεί να διαβάσει ρυθμίσεις proxy το Wget, τα σιωπηλά failures όταν χρησιμοποιείτε λάθος πεζά/κεφαλαία σε μεταβλητές, και οι ιδιοτροπίες των εταιρικών δικτύων που δεν εξηγεί κανένα man page. Αυτός ο οδηγός καλύπτει κάθε τρόπο παραμετροποίησης του Wget με proxy, τους ακριβείς κανόνες προτεραιότητας όταν συγκρούονται πολλαπλές μέθοδοι, πραγματικό terminal output για κάθε συνηθισμένο σφάλμα, και ξεχωριστή ενότητα για χρήστες Windows και corporate firewalls — δηλαδή το κοινό που σχεδόν όλα τα άλλα tutorials προσποιούνται ότι δεν υπάρχει.

• Δυσκολία: Αρχάριο προς Μεσαίο επίπεδο
• Χρόνος που απαιτείται: ~15 λεπτά για ανάγνωση και ρύθμιση· ~2 λεπτά όταν ξέρετε τι κάνετε
• Τι θα χρειαστείτε: Μια λειτουργική εγκατάσταση Wget (οδηγίες παρακάτω), μια διεύθυνση proxy (host + port) και προαιρετικά στοιχεία σύνδεσης

Δοκιμάστε το Thunderbit για εξαγωγή δομημένων δεδομένων

Τι είναι το Wget και γιατί να το χρησιμοποιήσετε με proxy;

Το Wget είναι ένα εργαλείο γραμμής εντολών που κατεβάζει αρχεία και ιστοσελίδες από το διαδίκτυο χωρίς browser. Η δική του περιγραφή από το GNU το αποκαλεί «non-interactive network downloader» — δηλαδή εκτελείται στο background, συνεχίζει διακοπείσες λήψεις και χειρίζεται recursive downloads χωρίς να χρειάζεται να κάνει κάτι άνθρωπος.

Το proxy, σε αυτό το πλαίσιο, είναι ένας ενδιάμεσος διακομιστής. Αντί το μηχάνημά σας να συνδέεται απευθείας σε έναν στόχο, το Wget στέλνει το αίτημα στο proxy και εκείνο το προωθεί. Οι βασικοί λόγοι για να το χρησιμοποιήσετε είναι οι εξής:

• Συμμόρφωση με εταιρικό firewall — η εταιρεία σας απαιτεί όλη η εξερχόμενη κίνηση να περνά από εγκεκριμένο proxy
• Ιδιωτικότητα και διαχείριση IP — τα αιτήματα εμφανίζονται από το IP του proxy, όχι το δικό σας
• Geo-testing — πρόσβαση σε πόρους με γεωγραφικούς περιορισμούς ή έλεγχος συμπεριφοράς CDN από συγκεκριμένη τοποθεσία
• Pipeline συλλογής δεδομένων — λήψη HTML μέσω rotating proxies για έρευνα ή monitoring
• CI/CD περιβάλλοντα — build runners σε κλειστά δίκτυα που μπορούν να βγουν στο internet μόνο μέσω proxy

Το Wget υποστηρίζει εγγενώς HTTP, HTTPS και FTP proxies. Δεν υποστηρίζει SOCKS5. Αν χρειάζεστε SOCKS5, το curl υποστηρίζει εγγενώς τα socks4://, socks5:// και socks5h:// schemes — ή μπορείτε να «τυλίξετε» το 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

# Verify
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. Το εκτελέσιμο συνήθως εγκαθίσταται στο C:\ProgramData\chocolatey\bin\wget.exe.

Μια σημαντική σημείωση για χρήστες Windows: το πού ψάχνει το Wget για .wgetrc διαφέρει ανά build. Περισσότερα στην ενότητα για Windows παρακάτω.

4 τρόποι να χρησιμοποιήσετε το Wget με proxy (και ποιον να διαλέξετε)

Τέσσερις μέθοδοι, καθεμία με διαφορετικό scope και επίπεδο προτεραιότητας:

1. Command-line flags -e — μία φορά, για μία εντολή
2. Αρχείο ρυθμίσεων χρήστη (~/.wgetrc) — ισχύει για κάθε εντολή Wget που εκτελείτε
3. Αρχείο συστήματος (/etc/wgetrc) — ισχύει για όλους τους χρήστες του μηχανήματος
4. Μεταβλητές περιβάλλοντος (http_proxy, https_proxy) — ισχύει για όλη τη συνεδρία του shell

Μέθοδος 1: Flags στη γραμμή εντολών (one-off proxy)

Ιδανικό για γρήγορα tests. Οι ρυθμίσεις εξαφανίζονται μόλις τελειώσει η εντολή.

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/

Γρήγορο smoke test — δείτε το εμφανές σας IP μέσω του proxy:

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

Αν το output δείχνει το 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 το τεκμηριώνει ως global startup file — η ακριβής διαδρομή εξαρτάται από το install prefix σας. Συνήθεις τοποθεσίες:

• /etc/wgetrc (οι περισσότερες Linux διανομές/package managers)
• /usr/local/etc/wgetrc (ορισμένα Homebrew builds)
• Η διαδρομή που εμφανίζεται στο wget --version κάτω από το "Wgetrc:"

Αυτό είναι χρήσιμο για shared servers, Docker containers ή οποιοδήποτε περιβάλλον όπου όλοι οι χρήστες πρέπει να περνούν από το ίδιο 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 (κεφαλαία) αγνοείται σιωπηλά. Καμία προειδοποίηση, κανένα μήνυμα, τίποτα. Θα δείξω το ακριβές terminal output στην ενότητα με τα gotchas, αλλά αξίζει να το θυμάστε από τώρα.

Προτεραιότητα μεθόδων proxy: τι υπερισχύει όταν έχουν οριστεί πολλαπλές μέθοδοι

Αν έχετε proxy ορισμένο στις μεταβλητές περιβάλλοντος και στο .wgetrc και στη γραμμή εντολών, ποιο κερδίζει; Κανείς δεν το εξηγεί καθαρά, οπότε το δοκίμασα.

Να η δοκιμασμένη και τεκμηριωμένη σειρά προτεραιότητας:

Προτεραιότητα	Μέθοδος	Scope	Τι υπερισχύει
1 (υψηλότερη)	-e flags στη γραμμή εντολών	Μία εντολή	Τα πάντα
2	~/.wgetrc	Τρέχων χρήστης	System config + env vars
3	/etc/wgetrc	Σε όλο το σύστημα	Μόνο env vars
4 (χαμηλότερη)	env vars http_proxy / https_proxy	Συνεδρία shell	Τίποτα

Το επιβεβαίωσα στο Wget 1.25.0 ορίζοντας αντικρουόμενα proxies σε κάθε επίπεδο. Με το environment να δείχνει στην πόρτα 3128, το config file στην 3129 και το CLI στην 3130:

• Το config υπερισχύει του environment: Το Wget συνδέθηκε στην πόρτα 3129, αγνοώντας την 3128.
• Το CLI υπερισχύει του config: Το Wget συνδέθηκε στην πόρτα 3130, αγνοώντας τόσο την 3129 όσο και την 3128.

Το «παραθυράκι διαφυγής» είναι το --no-proxy. Παρακάμπτει κάθε ρύθμιση proxy, ανεξάρτητα από το πού ορίστηκε:

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

Πρακτικό σενάριο: ο sysadmin σας έβαλε proxy στο /etc/wgetrc, αλλά εσείς πρέπει να φτάσετε απευθείας σε έναν εσωτερικό server. Χρησιμοποιήστε --no-proxy μόνο για εκείνη την εντολή αντί να πειράξετε το system config.

Πώς να χρησιμοποιήσετε το Wget με proxy που απαιτεί αυθεντικοποίηση

Οι περισσότεροι business και residential proxies απαιτούν username και password. Το Wget το υποστηρίζει αυτό με δύο τρόπους, και οι δύο χρησιμοποιούν HTTP Basic authentication για τα διαπιστευτήρια του proxy.

Διαπιστευτήρια ενσωματωμένα στη διεύθυνση του 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/

Χρήση των flags --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

Αυτά τα flags υπερισχύουν οποιουδήποτε user:pass@ είναι ενσωματωμένο στο URL του proxy.

Πώς να κρατήσετε ασφαλή τα credentials

Και οι δύο μέθοδοι εκθέτουν διαπιστευτήρια. Το GNU προειδοποιεί ότι τα passwords στη γραμμή εντολών είναι ορατά μέσω ps ή εργαλείων που εμφανίζουν λίστα διεργασιών. Τρόποι περιορισμού:

• Μηχανήματα με έναν χρήστη: Αποθηκεύστε τα credentials στο ~/.wgetrc και κλειδώστε το αρχείο: chmod 600 ~/.wgetrc
• CI/CD pipelines: Χρησιμοποιήστε τα κρυπτογραφημένα secrets του GitHub Actions ή το αντίστοιχο της πλατφόρμας σας. Περάστε τα ως lowercase environment variables στον ορισμό του βήματος — ποτέ hardcode μέσα σε YAML.
• Docker builds: Μην χρησιμοποιείτε ARG ή ENV για secrets. Η τεκμηρίωση του Docker προειδοποιεί ρητά ότι τα build arguments μπορούν να παραμείνουν στο τελικό image. Χρησιμοποιήστε BuildKit secret mounts αντί για αυτά.
• Έλεγχος έκδοσης: Ποτέ μην κάνετε commit το .wgetrc με credentials. Προσθέστε το στο .gitignore.

Μια λεπτομέρεια ειδική για το Wget στο GitHub Actions: τα ονόματα των secrets αποθηκεύονται παραδοσιακά με κεφαλαία, αλλά οι μεταβλητές περιβάλλοντος που εκθέτετε στο Wget πρέπει να είναι πεζές (http_proxy, όχι HTTP_PROXY).

Πώς να χρησιμοποιήσετε το Wget με proxy στα Windows και πίσω από corporate firewalls

Τα περισσότερα άρθρα σε αυτό το θέμα σταματούν στο «εγκαταστήστε το με Chocolatey». Αν είστε σε Windows ή πίσω από corporate proxy, εκεί αρχίζουν τα προβλήματά σας.

Πού ψάχνουν τα Windows για το .wgetrc

Η τεκμηρίωση του GNU λέει ότι το Wget διαβάζει το $HOME/.wgetrc εκτός αν η μεταβλητή WGETRC δείχνει αλλού. Στα Windows, το $HOME μπορεί να αντιστοιχεί στο %USERPROFILE% (π.χ. C:\Users\alice), αλλά μπορεί και όχι — ανάλογα με το αν χρησιμοποιείτε Chocolatey build, MSYS2 build, Git Bash ή standalone binary.

Η σύστασή μου: αποφύγετε τις υποθέσεις και χρησιμοποιήστε το flag --config για προβλέψιμη συμπεριφορά:

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

Για να δοκιμάσετε αν το build σας διαβάζει config file από συγκεκριμένη τοποθεσία, δημιουργήστε ένα δοκιμαστικό αρχείο που δείχνει σε 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, τότε διάβασε το αρχείο.

Ρύθμιση μεταβλητών proxy στα 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, πρέπει να ανοίξετε νέο παράθυρο terminal. Η τρέχουσα συνεδρία δεν θα δει την αλλαγή.

Corporate proxy gotchas: PAC files, NTLM auth και πώς να βρείτε τη διεύθυνση proxy

Τρία πράγματα που μπερδεύουν σταθερά τους εταιρικούς χρήστες:

PAC files: Πολλές επιχειρήσεις χρησιμοποιούν Proxy Auto-Configuration (PAC) files — scripts βασισμένα σε JavaScript που λένε στους browsers ποιο proxy να χρησιμοποιήσουν για κάθε URL. Το Wget δεν έχει JavaScript interpreter, οπότε δεν μπορεί να διαβάσει PAC files. Η τεκμηρίωση του Curl λέει το ίδιο. Η λύση: ανοίξτε το PAC file (ή ρωτήστε το IT), βρείτε το αποτέλεσμα PROXY host:port για τον στόχο σας και ρυθμίστε αυτή τη στατική διεύθυνση στο Wget.

NTLM authentication: Η proxy authentication του Wget υλοποιεί μόνο Basic auth. Αν το εταιρικό σας proxy απαιτεί NTLM και βλέπετε 407 Proxy Authentication Required, μην χάνετε χρόνο δοκιμάζοντας διαφορετική σύνταξη --proxy-user. Εγκαταστήστε το Cntlm — έναν τοπικό relay που χειρίζεται NTLM/NTLMv2 authentication και παρουσιάζει Basic-auth interface στο Wget. Το Cntlm εξακολουθεί να συντηρείται (τελευταία ενημέρωση Οκτώβριος 2025, ~395 λήψεις/εβδομάδα).

Δέντρο απόφασης για χρήστες corporate proxy:

1. Δοκιμάστε set http_proxy=http://YOUR_PROXY:PORT/ και τρέξτε Wget.
2. Αν πάρετε 407 και η εταιρεία σας χρησιμοποιεί NTLM → εγκαταστήστε Cntlm, ρυθμίστε το με τα domain credentials σας και κατευθύνετε το Wget στην τοπική πόρτα του Cntlm (συνήθως http://127.0.0.1:3128/).
3. Αν η εταιρεία χρησιμοποιεί PAC file → εξάγετε το πραγματικό PROXY host:port από το PAC file ή ζητήστε από το IT τη στατική διεύθυνση proxy.

Συνηθισμένες πόρτες corporate proxy: 3128 (τύπου Squid), 8080 (γενικό HTTP proxy), 8888 (debugging proxies όπως Fiddler/Charles). Αυτά είναι συμβάσεις, όχι εγγυήσεις.

Συνηθισμένα λάθη όταν χρησιμοποιείτε Wget με proxy (με πραγματικό error output)

Και τώρα το payoff που υποσχέθηκε ο τίτλος. Όλα τα outputs παρακάτω αναπαράχθηκαν στο 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 και γίνεται σαφής η σύνταξη των credentials (http://user:pass@host:port/).

Λάθος 2: use_proxy=yes αντί για use_proxy=on

Και τα δύο, yes και on, δούλεψαν στις δοκιμές μου στο Wget 1.25.0. Όμως οι μη έγκυρες τιμές αποτυγχάνουν με καθαρό μήνυμα σφάλματος:

wget: use_proxy: Invalid boolean 'true'; use `on' or `off'.

Χρησιμοποιήστε on για τη μέγιστη συμβατότητα — ταιριάζει με τη τεκμηριωμένη boolean μορφή του manual και με την ίδια την υπόδειξη σφάλματος του 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: Παλιό proxy στο .wgetrc που προκαλεί "Connection refused"

Αν εσείς (ή ο sysadmin σας, ή ένα Docker image) αφήσατε παλιά διεύθυνση 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, όχι προς τον τελικό ιστότοπο. Σειρά διάγνωσης (ακολουθώντας την ιεραρχία προτεραιότητας):

1. Ελέγξτε την εντολή σας για -e flags ή shell aliases
2. Ελέγξτε το ~/.wgetrc (ή το αρχείο που ορίζει το WGETRC)
3. Ελέγξτε το system config (τη διαδρομή που δείχνει το wget --version)
4. Ελέγξτε το environment: env | grep -i proxy

Για debugging, το --no-config είναι ο φίλος σας — λέει στο Wget να αγνοήσει όλα τα config files:

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

Αν αυτό λειτουργεί, το πρόβλημα βρίσκεται σε κάποιο config file.

Λάθος 5: Σύγχυση στη σύνταξη του HTTPS proxy

Αυτό μπερδεύει πολύ κόσμο. Όταν ορίζετε https_proxy, το ίδιο το URL του proxy είναι συνήθως http://, όχι https://. Αυτό συμβαίνει επειδή το Wget στέλνει ένα HTTP CONNECT request μέσω του proxy για να δημιουργήσει tunnel για την κρυπτογραφημένη HTTPS συνεδρία.

Σωστό:

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

Το Wget στέλνει CONNECT example.com:443 HTTP/1.1 στο proxy και μετά περνά το HTTPS μέσω 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 απορρίπτει εντελώς το https:// ως proxy URL για HTTP targets. Χρησιμοποιήστε https_proxy=http://HOST:PORT/ εκτός αν ο οργανισμός σας έχει τεκμηριώσει ειδικά ένα HTTPS proxy endpoint και το έχετε δοκιμάσει με το δικό σας Wget build.

Cheat sheet εντολών Wget για proxy (γρήγορη αναφορά για αποθήκευση)

Αποθηκεύστε αυτόν τον πίνακα. Συγκεντρώνει όλα τα Wget flags και directives για proxy σε ένα σημείο.

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:// και το τελικό /
-e https_proxy=	CLI	-e https_proxy=http://proxy:8080/	Το URL του proxy είναι συνήθως http:// ακόμη και για HTTPS στόχους
--proxy-user	CLI	--proxy-user=admin	Υπερισχύει του inline user:pass@
--proxy-password	CLI	--proxy-password=secret	Εμφανίζεται στο ps — αποφύγετέ το σε shared συστήματα
--no-proxy	CLI	--no-proxy	Παρακάμπτει ΟΛΕΣ τις ρυθμίσεις proxy από κάθε πηγή
--no-config	CLI	--no-config	Παραλείπει όλα τα config files — χρήσιμο για debugging
--config=FILE	CLI	--config=/tmp/wgetrc	Προβλέψιμη διαδρομή config — ιδανικό για Windows και CI
http_proxy	.wgetrc / env	http_proxy = http://proxy:8080/	Το config file χρησιμοποιεί κενά γύρω από το =· η env μεταβλητή είναι πεζή
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	Λίστα domains χωρισμένη με κόμμα
proxy_user	.wgetrc	proxy_user = admin	Ισοδύναμο με --proxy-user
proxy_password	.wgetrc	proxy_password = secret	Προστατέψτε το αρχείο με chmod 600

Πότε το Wget + proxy δεν είναι το σωστό εργαλείο (και τι να χρησιμοποιήσετε αντί γι’ αυτό)

Μετά από όλη αυτή τη ρύθμιση proxy, να μια πιο αντίθετη άποψη: μερικές φορές δεν αξίζει καν να μπλέξετε.

Πολλοί που ψάχνουν "wget proxy" στην πραγματικότητα δεν προσπαθούν να κατεβάσουν ένα μόνο αρχείο. Θέλουν να συλλέξουν δομημένα δεδομένα από websites — τιμές προϊόντων, λίστες επαφών, αγγελίες ακινήτων — και κατέληξαν στο Wget επειδή είναι το command-line εργαλείο που ξέρουν. Το πρόβλημα είναι ότι το Wget σας δίνει raw HTML. Πρέπει ακόμα να το αναλύσετε, να το καθαρίσετε και να το δομήσετε. Και αν κάνετε rotating proxies για να αποφεύγετε blocks, τώρα διαχειρίζεστε λίστα proxy, script λήψης, parser και export pipeline.

| Ο στόχος σας | Καλύτερο εργαλείο | Γιατί | |---|---|---|---| | Λήψη ενός μόνο αρχείου μέσω proxy | wget με proxy flags | Απλό, μία εντολή | | Mirroring site ή καταλόγου μέσω proxy | wget --recursive + proxy config | Η recursive λήψη είναι βασικό πλεονέκτημα του Wget | | Εξαγωγή δομημένων δεδομένων (πίνακες, λίστες, επαφές) | Thunderbit | Το Wget δίνει raw HTML — χρειάζεται ακόμα parsing. Το Thunderbit διαβάζει τη σελίδα με AI και εξάγει δομημένα δεδομένα σε Excel, Google Sheets, Airtable ή Notion χωρίς κώδικα. Το cloud scraping του χειρίζεται rotation IP και anti-bot μέτρα, οπότε παρακάμπτετε εντελώς τη ρύθμιση proxy. | | REST API calls μέσω proxy | curl | Καλύτερος έλεγχος headers, εγγενής υποστήριξη JSON, υποστήριξη SOCKS5 | | Συνεχής προγραμματισμένη συλλογή δεδομένων | Thunderbit Scheduled Scraper ή cron + wget | Το Thunderbit προσαρμόζεται όταν αλλάζει το layout της σελίδας· τα cron + wget scripts αποτυγχάνουν σιωπηλά |

Το Wget είναι εξαιρετικό στις λήψεις αρχείων. Όμως το workflow «ρύθμιση proxy → εναλλαγή IPs → λήψη HTML → γράψιμο parser → export σε spreadsheet» έχει πάρα πολλά κινούμενα μέρη όταν αυτό που θέλετε είναι απλώς ένας πίνακας δεδομένων. Αν αυτό μοιάζει με τη δική σας περίπτωση, η επέκταση Chrome αναλαμβάνει όλο το pipeline με δύο κλικ. Για περισσότερα πάνω σε αυτή την προσέγγιση, δείτε τους οδηγούς μας για AI web scraping και web scraping χωρίς κώδικα.

Αλλά αν ο στόχος σας είναι «κατέβασε αυτό το ZIP αρχείο μέσω corporate proxy» — το Wget παραμένει το σωστό εργαλείο, και τώρα ξέρετε πώς να το ρυθμίσετε σωστά.

Βασικά συμπεράσματα

Η σύντομη εκδοχή:

• Τέσσερις μέθοδοι, καθαρή προτεραιότητα: Τα CLI flags υπερισχύουν του user config, το οποίο υπερισχύει του system config, το οποίο υπερισχύει των μεταβλητών περιβάλλοντος. Το --no-proxy υπερισχύει των πάντων.
• Χρησιμοποιείτε πάντα πεζά για μεταβλητές περιβάλλοντος (http_proxy, όχι HTTP_PROXY). Τα κεφαλαία αγνοούνται σιωπηλά.
• Βάζετε πάντα το http:// στο proxy URL σας, ακόμη και για https_proxy. Το endpoint του proxy είναι HTTP· κάνει tunnel το HTTPS μέσω CONNECT.
• Χρησιμοποιείτε on για boolean τιμές σε .wgetrc και flags -e. Είναι η ασφαλέστερη επιλογή σε όλες τις εκδόσεις Wget.
• Χρήστες Windows: Χρησιμοποιήστε --config=C:\path\to\wgetrc για να αποφύγετε ασάφεια στο config file. Χρησιμοποιήστε set (CMD) ή $env: (PowerShell) για session proxy variables.
• Χρήστες corporate proxy: Το Wget δεν μπορεί να διαβάσει PAC files και δεν υποστηρίζει εγγενώς NTLM auth. Χρησιμοποιήστε το Cntlm ως τοπικό relay αν χρειάζεται.
• Αποθηκεύστε το cheat sheet παραπάνω — θα σας γλιτώσει από το να ξαναδιαβάζετε το άρθρο κάθε φορά που χρειάζεστε όνομα flag.

Αν ο πραγματικός σας στόχος είναι εξαγωγή δομημένων δεδομένων, το Thunderbit ή το curl ίσως είναι καλύτερη επιλογή. Το καλύτερο debugging session είναι εκείνο που δεν χρειάζεται ποτέ να ξεκινήσετε.

Συχνές ερωτήσεις

1. Υποστηρίζει το Wget SOCKS5 proxies;

Όχι. Το GNU Wget 1.x υποστηρίζει μόνο HTTP, HTTPS και FTP proxies. Το πρότζεκτ Wget2 έχει το SOCKS5 ως feature request, αλλά δεν αποτελεί τυπική τεκμηριωμένη επιλογή. Για SOCKS5, χρησιμοποιήστε το curl με τα εγγενή schemes socks5:// ή socks5h://, ή τυλίξτε το Wget με proxychains4 ώστε να εξαναγκάσετε τη δρομολόγηση μέσω SOCKS.

2. Γιατί αγνοείται η ρύθμιση proxy όταν χρησιμοποιώ κεφαλαίο HTTP_PROXY;

Το Wget διαβάζει μόνο πεζά ονόματα μεταβλητών περιβάλλοντος (http_proxy, https_proxy, ftp_proxy, no_proxy). Οι κεφαλαίες εκδοχές όπως HTTP_PROXY αγνοούνται σιωπηλά — χωρίς σφάλμα, χωρίς προειδοποίηση. Αυτό είναι ένα από τα πιο συνηθισμένα και εκνευριστικά προβλήματα, επειδή δεν υπάρχει καμία ένδειξη ότι κάτι πάει στραβά. Χρησιμοποιείτε πάντα πεζά.

3. Πώς παρακάμπτω το proxy για συγκεκριμένα domains;

Χρησιμοποιήστε το directive no_proxy, είτε ως μεταβλητή περιβάλλοντος είτε στο .wgetrc:

export no_proxy=localhost,127.0.0.1,.mycompany.com

Ή στο ~/.wgetrc:

no_proxy = localhost,127.0.0.1,.mycompany.com

Τα domains χωρίζονται με κόμμα. Μια τελεία στην αρχή (.mycompany.com) ταιριάζει σε όλα τα subdomains.

4. Μπορώ να χρησιμοποιήσω το Wget με rotating proxies;

Το ίδιο το Wget δεν έχει ενσωματωμένη εναλλαγή proxy. Έχετε δύο επιλογές: να χρησιμοποιήσετε provider που κάνει rotation IP server-side (ώστε να χτυπάτε πάντα το ίδιο gateway address, αλλά να αλλάζει το exit IP), ή να γράψετε ένα shell script που επιλέγει τυχαίο proxy από λίστα και το περνά μέσω -e http_proxy=... σε κάθε εκτέλεση. Για οτιδήποτε πιο σύνθετο — αυτόματο rotation, retry logic, anti-bot handling — ένα ειδικό scraping tool είναι συνήθως καλύτερη λύση.

5. Ποια είναι η διαφορά μεταξύ http_proxy και https_proxy στο Wget;

Το http_proxy χρησιμοποιείται όταν το target URL είναι http://. Το https_proxy χρησιμοποιείται όταν το target URL είναι https://. Και στις δύο περιπτώσεις, το ίδιο το URL του proxy είναι συνήθως μια διεύθυνση http://. Για HTTPS στόχους, το Wget στέλνει ένα HTTP CONNECT request μέσω του proxy για να δημιουργήσει tunnel, και η πραγματική κρυπτογράφηση HTTPS γίνεται end-to-end ανάμεσα στο Wget και στον target server. Το proxy βλέπει το hostname (από το CONNECT request) αλλά δεν μπορεί να διαβάσει την κρυπτογραφημένη κίνηση.

Δοκιμάστε το Thunderbit για AI Web Scraping Get Started Free

Μάθετε περισσότερα

• Τα καλύτερα αυτοματοποιημένα εργαλεία Web Scraping
• Πώς να εξαγάγετε δεδομένα από website με Python
• Οι καλύτερες υπηρεσίες Web Scraping
• Web Scraping χωρίς να μπλοκάρεστε
• Πώς να ρυθμίσετε έναν proxy server