Wget’te proxy kurulumu ilk bakışta beş dakikalık iş gibi durur — ta ki isteklerinizin hiçbir hata vermeden proxy’yi tamamen atladığını fark edene kadar. Bunu hem tecrübeli sistem yöneticilerinde hem de yeni başlayan geliştiricilerde defalarca gördüm.
Asıl mesele neredeyse hiç proxy’nin kendisi değildir. Sorun; Wget’in proxy ayarlarını okuyabildiği dört ayrı konum, yanlış değişken harfi yüzünden oluşan sessiz hatalar ve hiçbir kullanım kılavuzunun düzgün anlatmadığı kurumsal ağ ayrıntılarıdır. Bu rehber, Wget’i proxy ile yapılandırmanın tüm yollarını, birden fazla yöntem çakıştığında hangi öncelik kurallarının geçerli olduğunu, her yaygın hata için gerçek terminal çıktısını ve özellikle Windows ile kurumsal güvenlik duvarının arkasındaki kullanıcılar için ayrı bir bölümü kapsıyor — yani diğer neredeyse tüm yazıların göz ardı ettiği kitleyi.
- Zorluk seviyesi: Başlangıç – Orta
- Gerekli süre: Okuyup yapılandırmak için yaklaşık 15 dakika; ne yaptığınızı biliyorsanız yaklaşık 2 dakika
- İhtiyacınız olacaklar: Çalışan bir Wget kurulumu (aşağıda anlatılıyor), bir proxy adresi (host + port) ve isteğe bağlı olarak proxy kimlik bilgileri
Yapılandırılmış Veri Çıkarmak için Thunderbit’i Deneyin
Wget Nedir ve Neden Proxy ile Kullanılır?
Wget, tarayıcı olmadan internetten dosya ve web sayfası indiren bir komut satırı aracıdır. GNU’nun kendi tanımı onu “etkileşimsiz bir ağ indiricisi” olarak tanımlar — yani arka planda çalışır, yarım kalan indirmeleri kaldığı yerden sürdürür ve bir insanın tıklamasına gerek kalmadan yinelemeli indirmeleri yönetir.
Bu bağlamda proxy, aracı bir sunucudur. Makineniz hedef siteye doğrudan bağlanmak yerine isteği proxy’ye gönderir; proxy de isteği ileri iletir. Bunu kullanmak istemenizin başlıca nedenleri şunlardır:
- Kurumsal güvenlik duvarı uyumluluğu — şirketiniz tüm dış trafiğin onaylı bir proxy üzerinden geçmesini ister
- Gizlilik ve IP yönetimi — istekler sizin IP’niz yerine proxy’nin IP’sinden görünür
- Coğrafi test — bölge kilitli içeriklere erişmek veya CDN davranışını belirli bir konumdan test etmek
- Veri toplama süreçleri — araştırma ya da izleme için dönen proxy’ler üzerinden HTML indirmek
- CI/CD ortamları — internete yalnızca proxy ile çıkabilen kısıtlı ağlardaki build runner’lar
Wget yerleşik olarak HTTP, HTTPS ve FTP proxy’lerini destekler. Ancak SOCKS5 desteği yoktur. SOCKS5 gerekiyorsa, socks4://, socks5:// ve socks5h:// şemaları için yerleşik desteğe sahip olan curl kullanabilirsiniz — ya da Wget’i proxychains4 gibi bir araçla sarmalayabilirsiniz.
Linux, macOS ve Windows’ta Wget Nasıl Kurulur?
Proxy ayarına geçmeden önce makinenizde Wget kurulu olmalı. Bu bölüm kısa — ana konu değil, ön koşul.
Linux (Debian/Ubuntu ve RHEL/CentOS)
# Debian/Ubuntu
sudo apt update
sudo apt install wget
# RHEL/CentOS/Fedora
sudo dnf install wget
# Doğrula
wget --version
Ubuntu 24.04 LTS, Wget 1.21.4 ile gelir; Debian Trixie’de 1.25.0 vardır. CentOS Stream 10 paketlerinde 1.24.5 görünüyor.
macOS (Homebrew)
brew install wget
wget --version
Homebrew formülü şu anda kararlı Wget 1.25.0 sürümünü sunuyor ve son bir yılda 396.818 kurulum almış durumda.
Windows (Chocolatey ve Manuel Kurulum)
choco install wget
wget --version
Chocolatey’nin GNU Wget paketi toplamda 10 milyondan fazla indirme sayısına ulaşmış durumda; ancak şu an sürüm 1.21.4. İkili dosya genellikle C:\ProgramData\chocolatey\bin\wget.exe altında bulunur.
Windows kullanıcıları için önemli bir not: Wget’in .wgetrc dosyasını nerede aradığı derlemeye göre değişebilir. Ayrıntılar aşağıdaki Windows bölümünde.
Wget’i Proxy ile Kullanmanın 4 Yolu (ve Hangisini Seçmelisiniz)
Dört yöntem var; her birinin kapsamı ve önceliği farklıdır:
- Komut satırı
-ebayrakları — tek seferlik, tek komutluk kullanım - Kullanıcı yapılandırma dosyası (
~/.wgetrc) — o kullanıcıyla çalıştırdığınız tüm Wget komutlarına uygulanır - Sistem yapılandırma dosyası (
/etc/wgetrc) — makinedeki tüm kullanıcılar için geçerlidir - Ortam değişkenleri (
http_proxy,https_proxy) — tüm kabuk oturumu boyunca geçerlidir
Yöntem 1: Komut Satırı Bayrakları (Tek Seferlik Proxy)
Hızlı denemeler için en uygunudur. Komut bittiğinde ayarlar da kaybolur.
wget -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://example.com/file.zip
HTTPS hedefleri için:
wget -e use_proxy=on -e https_proxy=http://HOST:PORT/ https://example.com/
Hızlı bir kontrol testi — görünen IP’nizi proxy üzerinden çekin:
wget -qO- -e use_proxy=on -e http_proxy=http://HOST:PORT/ http://ifconfig.me
Çıktı sizin IP’niz yerine proxy’nin IP’sini gösteriyorsa, iş tamamdır.
Yöntem 2: Kullanıcı Yapılandırma Dosyası (~/.wgetrc)
Aşağıdaki satırları ~/.wgetrc dosyasına ekleyin (dosya yoksa oluşturun):
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
= çevresindeki boşluklara dikkat edin — bu, belgelendirilmiş .wgetrc sözdizimidir. Bu kullanıcıyla çalıştırdığınız tüm Wget komutları artık proxy üzerinden gidecektir.
Yöntem 3: Sistem Genelinde Yapılandırma (/etc/wgetrc)
~/.wgetrc ile aynı yönergeler, ama sistem yapılandırma dosyasına yazılır. GNU bunu genel bir başlangıç dosyası olarak belgeler — kesin yol, kurulum önekine bağlıdır. Yaygın konumlar:
/etc/wgetrc(çoğu Linux paket yöneticisi)/usr/local/etc/wgetrc(bazı Homebrew kurulumları)wget --versionçıktısında “Wgetrc:” altında görünen yol
Bu yöntem paylaşılan sunucular, Docker konteynerleri veya tüm kullanıcıların aynı proxy üzerinden çıkması gereken ortamlar için kullanışlıdır.
Yöntem 4: Ortam Değişkenleri (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
Bunlar yalnızca Wget’i değil, tüm kabuk oturumunu etkiler. curl gibi araçlar da bunları kullanır.
Kritik uyarı: Wget yalnızca küçük harfli ortam değişkeni adlarını okur. HTTP_PROXY (büyük harfli) tamamen yok sayılır. Hata yok, uyarı yok, hiçbir şey yok. Gotcha bölümünde tam terminal çıktısını göstereceğim; ama bunu şimdiden akılda tutmakta fayda var.
Proxy Yöntemi Önceliği: Birden Fazla Yöntem Ayarlıysa Hangisi Geçerli Olur?
Proxy hem ortam değişkenlerinde hem .wgetrc içinde hem de komut satırında tanımlıysa hangisi kazanır? Bunu açıkça anlatan çok az kaynak var; ben test ettim.
İşte test edilen ve belgelenen öncelik sırası:
| Öncelik | Yöntem | Kapsam | Neyi Geçersiz Kılar |
|---|---|---|---|
| 1 (en yüksek) | -e CLI bayrakları | Tek komut | Her şey |
| 2 | ~/.wgetrc | Geçerli kullanıcı | Sistem yapılandırması + ortam değişkenleri |
| 3 | /etc/wgetrc | Sistem genelinde | Yalnızca ortam değişkenleri |
| 4 (en düşük) | http_proxy / https_proxy ortam değişkenleri | Kabuk oturumu | Hiçbir şey |
Bunu Wget 1.25.0 üzerinde, her seviyede çakışan proxy’ler ayarlayarak doğruladım. Ortam 3128 portunu, yapılandırma dosyası 3129’u, CLI ise 3130’u gösteriyordu:
- Yapılandırma, ortamı geçer: Wget 3128’i yok sayıp 3129’a bağlandı.
- CLI, yapılandırmayı geçer: Wget hem 3129’u hem 3128’i yok sayıp 3130’a bağlandı.
Acil çıkış anahtarı --no-proxy’dir. Nerede tanımlandığı fark etmeksizin tüm proxy ayarlarını atlar:
wget --no-proxy https://internal-server.company.com/report.pdf
Pratik senaryo: sistem yöneticiniz /etc/wgetrc içine proxy ekledi ama siz iç ağdaki bir sunucuya doğrudan ulaşmak istiyorsunuz. Sistem yapılandırmasını değiştirmek yerine bu tek komutta --no-proxy kullanın.
Kimlik Doğrulamalı Proxy ile Wget Nasıl Kullanılır?
Çoğu kurumsal ve ev tipi proxy kullanıcı adı ve parola ister. Wget bunu iki yöntemle destekler; ikisi de proxy kimlik bilgileri için HTTP Basic kimlik doğrulamasını kullanır.
Proxy URL’sine Doğrudan Kimlik Bilgisi Yazmak
wget -e use_proxy=on \
-e http_proxy=http://USERNAME:PASSWORD@proxy.company.com:8080/ \
http://example.com/file.zip
Bu yaklaşım .wgetrc içinde de çalışır:
http_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
https_proxy = http://USERNAME:PASSWORD@proxy.company.com:8080/
--proxy-user ve --proxy-password Bayraklarını Kullanmak
wget --proxy-user=USERNAME --proxy-password=PASSWORD \
-e use_proxy=on \
-e http_proxy=http://proxy.company.com:8080/ \
http://example.com/file.zip
Bu bayraklar, proxy URL’sine gömülü user:pass@ bilgisini geçersiz kılar.
Kimlik Bilgilerini Güvende Tutmak
Her iki yöntem de kimlik bilgilerini sızdırabilir. GNU, komut satırındaki parolaların ps veya işlem listesi araçlarıyla görülebileceği konusunda uyarır. Önlemler:
- Tek kullanıcı makineleri: Kimlik bilgilerini
~/.wgetrciçinde saklayın ve dosyayı kilitleyin:chmod 600 ~/.wgetrc - CI/CD hatları: GitHub Actions şifreli secret’ları veya platformunuzdaki benzer sistemi kullanın. Bunları adım tanımında küçük harfli ortam değişkenleri olarak verin — YAML içine asla sabitlemeyin.
- Docker build’leri: Sırlar için
ARGveyaENVkullanmayın. Docker dokümantasyonu açıkça build argümanlarının nihai imajda kalabileceği uyarısını yapar. Bunun yerine BuildKit secret mount’larını kullanın. - Sürüm kontrolü: Kimlik bilgisi içeren
.wgetrcdosyasını asla commit etmeyin.gitignoreiçine ekleyin.
GitHub Actions için Wget’e özgü bir ayrıntı: secret adları gelenek gereği büyük harfle saklanır; ancak Wget’e açtığınız ortam değişkenleri küçük harfli olmalıdır (HTTP_PROXY değil, http_proxy).
Windows’ta ve Kurumsal Güvenlik Duvarlarının Arkasında Wget’i Proxy ile Nasıl Kullanırsınız?
Bu konudaki çoğu yazı “Chocolatey ile kurun” noktasında bitiyor. Eğer Windows’taysanız veya kurumsal proxy arkasındaysanız, sorunlarınız aslında orada başlıyor.
Windows .wgetrc Dosyasını Nerede Arar?
GNU dokümantasyonu, WGETRC ortam değişkeni başka bir yeri göstermiyorsa Wget’in $HOME/.wgetrc dosyasını okuduğunu söyler. Windows’ta $HOME, kullandığınız ortama bağlı olarak %USERPROFILE% (ör. C:\Users\alice) ile eşleşebilir ya da eşleşmeyebilir — Chocolatey build, MSYS2 build, Git Bash veya bağımsız ikili dosya kullanmanıza göre değişir.
Benim önerim: tahmin etmeyi bırakın ve deterministik davranış için --config bayrağını kullanın:
wget --config=C:\Users\alice\wgetrc https://example.com/file.zip
Belirli bir konumdaki yapılandırma dosyasının okunup okunmadığını test etmek için, bilerek yanlış bir proxy’ye işaret eden bir deneme dosyası oluşturun:
; C:\Users\alice\wget-test.rc
use_proxy = on
http_proxy = http://127.0.0.1:3128/
Ardından şunu çalıştırın:
wget --config=C:\Users\alice\wget-test.rc --spider http://example.com/
Eğer Wget 127.0.0.1:3128 adresine bağlanmaya çalışırsa, dosyayı okumuş demektir.
Windows’ta Proxy Ortam Değişkenleri Nasıl Ayarlanır?
CMD (yalnızca oturum boyunca):
set http_proxy=http://HOST:PORT/
set https_proxy=http://HOST:PORT/
wget http://example.com/
PowerShell (yalnızca oturum boyunca):
$env:http_proxy = "http://HOST:PORT/"
$env:https_proxy = "http://HOST:PORT/"
wget http://example.com/
Kalıcı (yeniden başlatmadan sonra da kalır):
setx http_proxy http://HOST:PORT/
setx https_proxy http://HOST:PORT/
setx sonrasında yeni bir terminal penceresi açmanız gerekir. Mevcut oturum değişikliği görmez.
Kurumsal Proxy Gotchaları: PAC Dosyaları, NTLM Kimlik Doğrulama ve Proxy Adresini Bulma
Kurumsal kullanıcıların sürekli takıldığı üç konu:
PAC dosyaları: Birçok şirket Proxy Auto-Configuration (PAC) dosyaları kullanır — tarayıcıya hangi URL için hangi proxy’nin kullanılacağını söyleyen JavaScript tabanlı betikler. Wget’in JavaScript yorumlayıcısı yoktur, bu yüzden PAC dosyalarını okuyamaz. curl dokümantasyonu da aynı noktayı söyler. Çözüm: PAC dosyasını açın (veya IT’den isteyin), hedef etki alanınız için çıkan PROXY host:port sonucunu bulun ve Wget’te bu statik adresi kullanın.
NTLM kimlik doğrulama: Wget’in proxy kimlik doğrulaması yalnızca Basic auth uygular. Kurumsal proxy’niz NTLM istiyorsa ve 407 Proxy Authentication Required hatası alıyorsanız, farklı --proxy-user sözdizimleri denemeye vakit kaybetmeyin. Cntlm kurun — NTLM/NTLMv2 kimlik doğrulamasını yerelde karşılayıp Wget’e Basic auth arayüzü sunan bir ara katman. Cntlm hâlâ aktif olarak sürdürülüyor (son güncelleme Ekim 2025, haftada yaklaşık 395 indirme).
Kurumsal proxy kullanıcıları için karar ağacı:
set http_proxy=http://YOUR_PROXY:PORT/deneyin ve Wget’i çalıştırın.407hatası alırsanız ve şirketiniz NTLM kullanıyorsa → Cntlm kurun, etki alanı kimlik bilgilerinizle yapılandırın ve Wget’i Cntlm’in yerel portuna yönlendirin (genelliklehttp://127.0.0.1:3128/).- Şirket PAC dosyası kullanıyorsa → PAC dosyasından gerçek
PROXY host:portbilgisini çıkarın veya IT’den statik proxy adresini isteyin.
Yaygın kurumsal proxy portları: 3128 (Squid tarzı), 8080 (genel HTTP proxy), 8888 (Fiddler/Charles gibi hata ayıklama proxy’leri). Bunlar birer gelenektir, garanti değildir.
Wget ile Proxy Kullanırken Sık Yapılan Hatalar (Gerçek Hata Çıktılarıyla)
Şimdi başlıkta vaat edilen kısma gelelim. Aşağıdaki tüm çıktılar 2026-06-01 tarihinde Wget 1.25.0 (macOS, Homebrew) üzerinde yeniden üretildi.
Hata 1: http:// Önekinin Eksik Olması
Bazı eski rehberler bunun her zaman bozulacağını iddia eder. Wget 1.25.0’de http_proxy=127.0.0.1:3128 ayarlamak aslında çalışır — Wget sessizce başına http:// ekler:
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.
Yani doğru proxy’ye yine bağlanmaya çalıştı. Ama yine de her zaman http:// önekini ve sona eğik çizgi eklemenizi öneririm. Bu, Wget sürümleri arasındaki belirsizliği önler ve kimlik bilgisi yazımını (http://user:pass@host:port/) daha net hale getirir.
Hata 2: use_proxy=yes ile use_proxy=on Arasındaki Fark
Testlerimde Wget 1.25.0 için hem yes hem on çalıştı. Ancak geçersiz değerler net bir hata verir:
wget: use_proxy: Invalid boolean 'true'; use `on' or `off'.
En geniş uyumluluk için on kullanın — bu, kılavuzda belgelenen boolean biçimiyle ve Wget’in kendi hata ipucuyla uyumludur.
Hata 3: Büyük Harfli HTTP_PROXY’nin Sessizce Yok Sayılması
Bu en sinir bozucu hata, çünkü hiçbir hata mesajı çıkmaz. Wget sadece doğrudan bağlanır; sanki proxy hiç ayarlanmamış gibi.
Büyük harfli sürüm (bozuk — proxy kullanılmadı):
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
Küçük harfli sürüm (çalışıyor — proxy deneniyor):
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.
Farkı görüyor musunuz? Büyük harfli sürüm example.com adresini doğrudan çözdü. Küçük harfli sürüm proxy’ye gitmeye çalıştı. Her iki durumda da uyarı yok. curl’da da benzer bir durum var — çoğu proxy değişkeni için büyük harfi kabul eder, ancak güvenlik nedeniyle HTTP_PROXY için büyük harfi açıkça reddeder.
Çözüm: Her zaman küçük harfli http_proxy ve https_proxy kullanın.
Hata 4: .wgetrc İçindeki Eski Proxy’nin “Connection Refused” Hatasına Yol Açması
Siz, sistem yöneticiniz ya da bir Docker imajı yapılandırma dosyasında eski bir proxy adresi bırakmışsa şöyle bir çıktı görürsünüz:
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.
Hata, hedef siteyi değil eski proxy IP’sini işaret eder. Tanılama sırası (öncelik hiyerarşisine göre):
- Komutunuzda
-ebayrakları veya kabuk takma adları var mı kontrol edin ~/.wgetrcdosyasını (veyaWGETRCile gösterilen dosyayı) kontrol edin- Sistem yapılandırmasını kontrol edin (
wget --versionçıktısında görünen yol) - Ortamı kontrol edin:
env | grep -i proxy
Hata ayıklarken --no-config dostunuzdur — Wget’e tüm yapılandırma dosyalarını atlamasını söyler:
wget --no-config --spider http://example.com/
Bu çalışıyorsa sorun yapılandırma dosyalarından birindedir.
Hata 5: HTTPS Proxy Sözdizimi Karışıklığı
Bu çok kişiyi yanıltır. https_proxy ayarladığınızda, proxy URL’sinin kendisi çoğu zaman https:// değil, http:// olur. Çünkü Wget, şifreli HTTPS oturumu için tünel oluşturmak amacıyla proxy üzerinden bir HTTP CONNECT isteği gönderir.
Doğru:
https_proxy=http://proxy.company.com:8080/
wget https://example.com/
Wget, proxy’ye CONNECT example.com:443 HTTP/1.1 gönderir ve ardından HTTPS trafiğini onun içinden tüneller.
Yanlış (HTTP hedefleri için HTTPS proxy uç noktası kullanmak):
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 hedefleri için proxy URL’si olarak https:// kullanımını doğrudan reddeder. Kuruluşunuz özellikle bir HTTPS proxy uç noktası belgelemediyse ve Wget sürümünüzde test etmediyseniz https_proxy=http://HOST:PORT/ kullanın.
Wget Proxy Komutları Hızlı Referans Tablosu
Bu tabloyu yer imlerine ekleyin. Proxy ile ilgili tüm Wget bayraklarını ve yapılandırma yönergelerini tek yerde toplar.
| Bayrak / Yönerge | Bağlam | Örnek | Notlar |
|---|---|---|---|
-e use_proxy=on | CLI | -e use_proxy=on | on en güvenli seçenektir; bazı derlemeler yes değerini de kabul eder |
-e http_proxy= | CLI | -e http_proxy=http://proxy:8080/ | http:// önekini ve sonda / ekleyin |
-e https_proxy= | CLI | -e https_proxy=http://proxy:8080/ | HTTPS hedeflerinde bile proxy URL’si genellikle http:// olur |
--proxy-user | CLI | --proxy-user=admin | Gömülü user:pass@ bilgisini geçersiz kılar |
--proxy-password | CLI | --proxy-password=secret | ps içinde görünür — paylaşılan sistemlerde kullanmayın |
--no-proxy | CLI | --no-proxy | Tüm kaynaklardaki HER proxy ayarını atlar |
--no-config | CLI | --no-config | Tüm yapılandırma dosyalarını atlar — hata ayıklama için çok yararlı |
--config=FILE | CLI | --config=/tmp/wgetrc | Kesin yapılandırma yolu — Windows ve CI için ideal |
http_proxy | .wgetrc / env | http_proxy = http://proxy:8080/ | Yapılandırma dosyasında = çevresinde boşluk kullanılır; ortam değişkeni küçük harfli olur |
https_proxy | .wgetrc / env | https_proxy = http://proxy:8080/ | http_proxy ile aynı biçim |
ftp_proxy | .wgetrc / env | ftp_proxy = http://proxy:8080/ | FTP indirmeleri için |
no_proxy | .wgetrc / env | no_proxy = localhost,127.0.0.1,.corp | Virgülle ayrılmış alan adı listesi |
proxy_user | .wgetrc | proxy_user = admin | --proxy-user ile eşdeğer |
proxy_password | .wgetrc | proxy_password = secret | Dosyayı chmod 600 ile koruyun |
Wget + Proxy Doğru Araç Değilse Ne Yapmalı? (ve Yerine Ne Kullanmalı)
Tüm bu proxy kurulumlarından sonra biraz ters köşe bir görüş: Bazen hiç uğraşmamanız gerekir.
“wget proxy” diye arama yapanların çoğu aslında tek bir dosya indirmeye çalışmıyordur. Web sitelerinden yapılandırılmış veri toplamaya çalışıyorlardır — ürün fiyatları, iletişim listeleri, emlak ilanları — ve alıştıkları komut satırı aracı olduğu için otomatik olarak Wget’e yönelmişlerdir. Sorun şu: Wget size ham HTML verir. Bunu hâlâ ayrıştırmanız, temizlemeniz ve yapılandırmanız gerekir. Üstelik engelleri aşmak için proxy döndürüyorsanız, şimdi bir proxy listesi, bir indirme betiği, bir ayrıştırıcı ve bir dışa aktarma hattı yönetiyorsunuz demektir.
| Hedefiniz | En İyi Araç | Neden |
|---|---|---|
| Proxy üzerinden tek bir dosya indirmek | Proxy bayraklarıyla wget | Basit, tek komut |
| Bir siteyi veya dizini proxy üzerinden kopyalamak | wget --recursive + proxy yapılandırması | Wget’in yinelemeli indirme gücü burada çok işe yarar |
| Yapılandırılmış veri kazımak (tablolar, listeler, iletişim bilgileri) | Thunderbit | Wget ham HTML verir — yine de ayrıştırmanız gerekir. Thunderbit’in yapay zekâsı sayfayı okuyup veriyi kod yazmadan Excel, Google Sheets, Airtable veya Notion’a yapılandırılmış biçimde aktarır. Bulut tabanlı kazıma, IP döndürme ve bot karşıtı önlemleri yönetir; böylece proxy kurulumunu tamamen atlayabilirsiniz. |
| Bir proxy üzerinden REST API çağrıları yapmak | curl | Daha iyi başlık kontrolü, yerleşik JSON desteği, SOCKS5 desteği |
| Sürekli ve zamanlanmış veri toplama | Thunderbit Scheduled Scraper veya cron + wget | Thunderbit sayfa düzeni değiştiğinde uyum sağlar; cron + wget betikleri sessizce bozulabilir |
Wget dosya indirme işinde harikadır. Ama “proxy ayarla → IP değiştir → HTML indir → ayrıştırıcı yaz → tabloya aktar” akışı, sizin asıl ihtiyacınız veri tablosuyken oldukça fazla parçadan oluşur. Eğer durumunuz buysa, Chrome uzantımız tüm süreci iki tıklamada halleder. Bu yaklaşım hakkında daha fazlası için AI web scraping ve kod yazmadan web scraping rehberlerimize göz atın.
Ama hedefiniz “bu ZIP dosyasını kurumsal proxy üzerinden indir” ise — Wget hâlâ doğru araçtır ve artık onu nasıl doğru yapılandıracağınızı biliyorsunuz.
Önemli Çıkarımlar
Kısa özet:
- Dört yöntem, net öncelik sırası: CLI bayrakları kullanıcı yapılandırmasını, kullanıcı yapılandırması sistem yapılandırmasını, sistem yapılandırması da ortam değişkenlerini geçersiz kılar.
--no-proxyise her şeyi geçersiz kılar. - Ortam değişkenlerinde daima küçük harf kullanın (
HTTP_PROXYdeğil,http_proxy). Büyük harfli sürüm sessizce yok sayılır. - Proxy URL’nizde,
https_proxyiçin bile daimahttp://kullanın. Proxy uç noktası HTTP’dir; HTTPS’i CONNECT ile tüneller. .wgetrcve-ebayraklarında boolean değerler içinonkullanın. Sürümler arasında en güvenli seçim budur.- Windows kullanıcıları: Yapılandırma dosyası belirsizliğini önlemek için
--config=C:\path\to\wgetrckullanın. Oturum proxy değişkenleri içinset(CMD) veya$env:(PowerShell) kullanın. - Kurumsal proxy kullanıcıları: Wget PAC dosyalarını okuyamaz ve NTLM kimlik doğrulamasını yerel olarak desteklemez. Gerekirse yerel ara katman olarak Cntlm kullanın.
- Yukarıdaki hızlı referans tablosunu yer imlerine ekleyin — bir bayrak adına ihtiyaç duyduğunuzda bu makaleyi baştan okumanızı engeller.
Asıl hedefiniz yapılandırılmış veri çıkarmaksa, Thunderbit veya curl daha iyi bir seçenek olabilir. En iyi hata ayıklama oturumu, asla başlamak zorunda kalmadığınız oturumdur.
Sık Sorulan Sorular
1. Wget SOCKS5 proxy’lerini destekler mi?
Hayır. GNU Wget 1.x yalnızca HTTP, HTTPS ve FTP proxy’lerini destekler. Wget2 projesinde SOCKS5 için bir özellik talebi var, ancak bu standart ve belgelenmiş bir seçenek değil. SOCKS5 için, yerleşik socks5:// veya socks5h:// şemalarıyla curl kullanın ya da Wget’i SOCKS yönlendirmesine zorlamak için proxychains4 ile sarın.
2. Neden büyük harfli HTTP_PROXY kullandığımda proxy ayarım yok sayılıyor?
Wget yalnızca küçük harfli ortam değişkeni adlarını okur (http_proxy, https_proxy, ftp_proxy, no_proxy). HTTP_PROXY gibi büyük harfli sürümler sessizce yok sayılır — hata da vermez, uyarı da. Bu, en yaygın ve en sinir bozucu sorunlardan biridir; çünkü bir şeyin yanlış olduğuna dair hiçbir işaret yoktur. Her zaman küçük harf kullanın.
3. Belirli alan adları için proxy’yi nasıl atlarım?
no_proxy yönergesini ortam değişkeni olarak ya da .wgetrc içinde kullanın:
export no_proxy=localhost,127.0.0.1,.mycompany.com
Veya ~/.wgetrc içinde:
no_proxy = localhost,127.0.0.1,.mycompany.com
Alan adları virgülle ayrılır. Baştaki nokta (.mycompany.com) tüm alt alan adlarını eşleştirir.
4. Wget’i dönen proxy’lerle kullanabilir miyim?
Wget’in yerleşik proxy döndürme özelliği yoktur. İki seçeneğiniz vardır: IP’leri sunucu tarafında döndüren bir proxy sağlayıcı kullanmak (siz her zaman aynı gateway adresine gidersiniz, ama çıkış IP’si değişir) ya da bir listedeki rastgele bir proxy’yi seçip her çalıştırmada -e http_proxy=... ile aktaran bir kabuk betiği yazmak. Otomatik döndürme, yeniden deneme mantığı, bot önleme gibi daha karmaşık işler için genellikle özel bir kazıma aracı daha uygundur.
5. Wget’te http_proxy ile https_proxy arasındaki fark nedir?
Hedef URL http:// ise http_proxy kullanılır. Hedef URL https:// ise https_proxy kullanılır. Her iki durumda da proxy URL’si genellikle http:// adresidir. HTTPS hedeflerinde Wget, proxy üzerinden bir HTTP CONNECT isteği göndererek tünel kurar; gerçek HTTPS şifrelemesi Wget ile hedef sunucu arasında uçtan uca gerçekleşir. Proxy, CONNECT isteğinden alan adını görür ama şifrelenmiş trafiği okuyamaz.
AI Web Scraping için Thunderbit’i Deneyin Get Started Free
Daha Fazla Bilgi
