Eğer sunucuları yönetiyorsanız, otomasyon betikleri yazıyorsanız veya kurumsal altyapıda uygulamaları dağıtıyorsanız, bir gün mutlaka curl veya wget trafiğini bir proxy üzerinden yönlendirme ihtiyacı ile karşılaşacaksınız. Bu, bir kurumsal proxy, paketleri indirirken coğrafi engelleri aşmak veya dış API'lere yapılan toplu isteklerde IP döndürme olabilir. Bu makalede yalnızca pratik var: komutlar, yapılandırmalar, suyu olmayan kod örnekleri.
1. curl ve wget proxy ile nasıl çalışır: temel mekanizmalar
Yapılandırmalara girmeden önce, arka planda neler olduğunu anlamak önemlidir. Her iki araç da iki temel proxy protokolünü destekler: HTTP/HTTPS ve SOCKS5. Mekanikleri farklıdır ve bu, belirli bir görev için hangi tür proxy seçileceğini etkiler.
HTTP proxy, uygulama protokolü seviyesinde bir aracı olarak çalışır. curl, HTTP proxy üzerinden bir istek gönderdiğinde, proxy sunucusuna "bunu benim yerime bu URL'ye GET isteği yap" der. HTTPS trafiği için CONNECT yöntemi kullanılır — curl, proxy'den hedef ana bilgisayara bir tünel kurmasını ister, ardından TLS el sıkışması doğrudan istemci ile hedef sunucu arasında gerçekleşir. Bu önemlidir: bu durumda proxy, HTTPS trafiğinin içeriğini göremez.
SOCKS5, daha düşük bir seviyede çalışır — uygulama protokolüne bağlı olmaksızın TCP/UDP bağlantılarını proxy'ler. Bu, SOCKS5'i daha evrensel hale getirir: sadece HTTP/HTTPS değil, diğer protokolleri de geçirebilir. Ayrıca, SOCKS5, proxy sunucusunda DNS çözümlemesini destekler — bu, DNS sızıntılarını önlemek için kritik öneme sahiptir.
💡 Pratik için ana fark:
Sadece bir dosya indirmek veya API isteği yapmak gerekiyorsa — HTTP proxy yeterlidir. Tam anonimlik, DNS sızıntılarını aşma veya standart dışı protokollerle çalışma gerekiyorsa — SOCKS5 kullanın.
curl, çok erken sürümlerden itibaren her iki protokolü de yerel olarak destekler. wget, tarihsel olarak SOCKS5 desteği daha sınırlıdır — eski sürümlerde (1.19'dan önce) SOCKS5 desteği yoktur, sadece HTTP proxy vardır. Bu, farklı dağıtımlarda çalışması gereken betikler yazarken dikkate alınmalıdır.
wget sürümünü kontrol etmek için wget --version komutunu kullanabilirsiniz. curl için ise curl --version komutunu kullanın, burada libcurl kütüphanesinin hangi protokollerle derlendiğini göreceksiniz.
2. Ortam değişkenleri: en hızlı ayar yöntemi
curl ve wget için proxy'yi ayarlamanın en şık yolu, ortam değişkenleri aracılığıyla yapılır. Bu sistemsel olarak çalışır: her betiği değiştirmeye gerek yoktur, bir kez oturumda değişkenleri ayarlamak yeterlidir veya bunları kullanıcı profilinize ekleyebilirsiniz.
Her iki araç da aynı standart değişkenleri okur:
# HTTP trafiği için export http_proxy="http://proxy.example.com:3128" # HTTPS trafiği için export https_proxy="http://proxy.example.com:3128" # Büyük harfle tekrarlıyoruz (bazı programlar sadece bunları okur) export HTTP_PROXY="http://proxy.example.com:3128" export HTTPS_PROXY="http://proxy.example.com:3128" # FTP için (gerekirse) export ftp_proxy="http://proxy.example.com:3128" # İstisnalar — proxy üzerinden geçmeyen adresler export no_proxy="localhost,127.0.0.1,::1,192.168.0.0/16,.internal.company.com"
Önemli bir ayrıntı: curl, sürüme bağlı olarak değişkenlere duyarlıdır. Sürpriz yaşamamak için — her zaman iki versiyonu da ayarlayın: küçük ve büyük harfle. Bu, DevOps'ta standart bir uygulamadır.
Ayarların belirli bir kullanıcı için sürekli uygulanmasını istiyorsanız, satırları ~/.bashrc veya ~/.profile dosyasına ekleyin. Sistem betikleri ve servisler için — /etc/environment dosyasına veya systemd birim dosyasına Environment= direktifi ile ekleyin.
# /etc/systemd/system/myservice.service
[Service]
Environment="http_proxy=http://proxy.example.com:3128"
Environment="https_proxy=http://proxy.example.com:3128"
Environment="no_proxy=localhost,127.0.0.1"
ExecStart=/usr/bin/myapp
Eğer proxy kimlik doğrulaması gerektiriyorsa, kullanıcı adı ve şifre doğrudan değişkenin URL'sine eklenir:
export http_proxy="http://username:[email protected]:3128" export https_proxy="http://username:[email protected]:3128"
⚠️ Güvenlik:
Şifreleri açık bir şekilde .bashrc dosyasında veya üretim sunucularında ortam değişkenlerinde saklamayın. Vault çözümleri (HashiCorp Vault, AWS Secrets Manager) kullanın veya en azından değişkenler dosyasının izinlerini kısıtlayın.
3. Proxy ile çalışmak için curl bayrakları: kapsamlı inceleme
curl, komut satırından proxy'yi yönetmek için zengin bir bayrak seti sunar. Bu, sistem ayarlarını değiştirmeden proxy üzerinden tek seferlik bir istek yapmak gerektiğinde kullanışlıdır.
Ana bayrak — -x veya --proxy:
# Temel HTTP proxy curl -x http://proxy.example.com:3128 https://api.example.com/data # Kısa form curl -x proxy.example.com:3128 https://api.example.com/data # Protokolün açıkça belirtilmesi curl --proxy http://proxy.example.com:3128 https://api.example.com/data # Proxy üzerinden dış IP'yi kontrol et curl -x http://proxy.example.com:3128 https://api.ipify.org
Ortam değişkenlerini yoksaymak ve doğrudan bağlantı (ayarlanmış proxy'yi atlamak) için --noproxy bayrağı kullanılır:
# Belirli bir ana bilgisayar için proxy'yi yoksay curl --noproxy "internal.company.com" https://internal.company.com/api # Proxy'yi tamamen yoksay (ortam değişkenleri ayarlanmış olsa bile) curl --noproxy "*" https://api.example.com/data
Proxy bağlantılarını hata ayıklamak için yararlı bayraklar:
# Ayrıntılı mod: tüm başlıklar görünür, proxy'ye CONNECT dahil curl -v -x http://proxy.example.com:3128 https://api.example.com/data # Sadece yanıt başlıkları curl -I -x http://proxy.example.com:3128 https://api.example.com/data # Proxy üzerinden bağlantı süresini göster curl -w "Connect: %{time_connect}s\nTotal: %{time_total}s\n" \ -x http://proxy.example.com:3128 \ -o /dev/null -s https://api.example.com/data
Proxy'yi ~/.curlrc yapılandırma dosyası aracılığıyla ayarlamak — her seferinde bayrakları yazmak istemiyorsanız kullanışlıdır:
# ~/.curlrc
proxy = http://proxy.example.com:3128
proxy-user = username:password
noproxy = localhost,127.0.0.1,.internal.company.com
Sistem betikleri için ayrı bir yapılandırma oluşturabilir ve bunu açıkça curl -K /path/to/config ile belirtebilirsiniz — bu, farklı görevler için farklı proxy profilleri bulundurmanızı sağlar.
4. wget'de proxy ayarı: bayraklar ve yapılandırma dosyası
wget, curl'dan daha az esneklik sunar, ancak tipik görevler için — dosyaları indirmek, siteleri özyinelemeli olarak yansıtmak — yeterli olanakları vardır. wget'de proxy'yi ayarlamanın üç yolu vardır: ortam değişkenleri aracılığıyla (yukarıda inceledik), komut satırı bayrakları ile ve ~/.wgetrc yapılandırma dosyası ile.
wget için komut satırı bayrakları:
# Bayrak ile HTTP proxy wget -e use_proxy=yes \ -e http_proxy=http://proxy.example.com:3128 \ https://example.com/file.tar.gz # HTTPS üzerinden proxy wget -e use_proxy=yes \ -e https_proxy=http://proxy.example.com:3128 \ https://example.com/file.tar.gz # Kimlik doğrulaması ile wget -e use_proxy=yes \ -e http_proxy=http://username:[email protected]:3128 \ https://example.com/file.tar.gz # Belirli bir komut için proxy'yi devre dışı bırak (ortam değişkenleri ayarlanmışsa) wget --no-proxy https://internal.company.com/file.tar.gz
~/.wgetrc yapılandırma dosyası — kalıcı ayarlar için tercih edilen yöntemdir:
# ~/.wgetrc use_proxy = on http_proxy = http://proxy.example.com:3128 https_proxy = http://proxy.example.com:3128 ftp_proxy = http://proxy.example.com:3128 no_proxy = localhost,127.0.0.1,.internal.company.com # Eğer proxy kimlik doğrulaması gerektiriyorsa proxy_user = username proxy_password = secretpassword
Sistem uygulamaları için (tüm kullanıcılar) /etc/wgetrc kullanılır — aynı format, ancak küresel olarak uygulanır. Kurumsal proxy üzerinden tüm indirme işlemlerinin yapılması gereken sunucular için uygundur.
Pratik bir örnek: bir proxy üzerinden derinlik ve hız sınırlaması ile bir web sitesinin özyinelemeli olarak indirilmesi:
wget -e use_proxy=yes \
-e http_proxy=http://proxy.example.com:3128 \
--recursive \
--level=2 \
--limit-rate=500k \
--wait=1 \
--random-wait \
--user-agent="Mozilla/5.0 (compatible; Googlebot/2.1)" \
https://example.com/docs/
5. curl ve wget'de SOCKS5 proxy: ayar ve örnekler
SOCKS5, anonimlik veya standart dışı portlarla çalışma gereksinimi olan görevler için daha tercih edilen bir protokoldür. Sistem yöneticileri ve DevOps mühendisleri için SOCKS5, genellikle SSH tünelleri aracılığıyla çalışırken ve rezidans proxy'lerine bağlanırken kullanılır; bu proxy'ler gerçek kullanıcıların trafiğini taklit eder.
curl, SOCKS5'i proxy URL'sinde özel bir ön ek ile destekler:
# SOCKS5, istemci tarafında DNS çözümü (DNS sızıntısı olabilir!) curl --socks5 proxy.example.com:1080 https://api.example.com/data # SOCKS5, proxy tarafında DNS çözümü (önerilir!) curl --socks5-hostname proxy.example.com:1080 https://api.example.com/data # -x bayrağı ile açıkça protokol belirtilerek curl -x socks5h://proxy.example.com:1080 https://api.example.com/data # Kimlik doğrulaması ile curl -x socks5h://username:[email protected]:1080 https://api.example.com/data # Ortam değişkeni aracılığıyla SOCKS5 export all_proxy="socks5h://proxy.example.com:1080" curl https://api.example.com/data
📌 socks5 vs socks5h — fark nedir?
socks5 — DNS sorgusu yerel olarak gerçekleştirilir, proxy üzerinden yalnızca TCP bağlantısı IP ile geçer. DNS sızıntısı mümkündür.socks5h (h = hostname) — DNS sorgusu proxy sunucusunda gerçekleştirilir. Tam anonimlik. Çoğu görev için önerilir.
DevOps'ta popüler bir senaryo — SSH'yi SOCKS5 proxy olarak kullanarak trafiği bir bastion host üzerinden tünellemek:
# Yerel 1080 portunda SOCKS5 ile SSH tüneli açıyoruz ssh -D 1080 -f -C -q -N [email protected] # Şimdi bu tüneli curl'de kullanıyoruz curl -x socks5h://localhost:1080 https://internal-api.private.network/data # Ya da oturumda tüm istekler için ortam değişkeni aracılığıyla export all_proxy="socks5h://localhost:1080" wget https://internal-resource.private.network/file.tar.gz
wget, 1.19 sürümünden itibaren SOCKS5'i destekler. Daha eski sürümlerde (CentOS 7, Ubuntu 16.04) proxychains, tsocks gibi geçici çözümler kullanmanız veya SOCKS5 gerektiren görevler için curl'a geçmeniz gerekecek.
6. Proxy'de kimlik doğrulama: kullanıcı adı ve şifre
Çoğu ticari proxy ve kurumsal proxy sunucuları kimlik doğrulaması gerektirir. Kimlik bilgilerini iletmek için birkaç yöntem vardır — her birinin güvenlik açısından artıları ve eksileri vardır.
Yöntem 1: URL'de kimlik bilgileri — basit, ancak güvenli değil (şifre işlem listesinde görünür):
curl -x http://user:p%[email protected]:3128 https://api.example.com/data # Şifrelerdeki özel karakterler URL ile kodlanmalıdır: @ → %40, : → %3A
Yöntem 2: curl'de --proxy-user bayrağı — şifreyi komut satırında belirtmek zorunda değilsiniz, curl etkileşimli olarak isteyecektir:
# Bayrakta kullanıcı adı ve şifre (hala ps aux'da görünür) curl -x http://proxy.example.com:3128 \ --proxy-user "username:password" \ https://api.example.com/data # Sadece kullanıcı adı — curl etkileşimli olarak şifreyi soracak curl -x http://proxy.example.com:3128 \ --proxy-user "username" \ https://api.example.com/data
Yöntem 3: .netrc dosyası aracılığıyla — betikler için en güvenli yöntem:
# ~/.netrc machine proxy.example.com login username password secretpassword # Dosya erişim izinlerini kısıtlıyoruz chmod 600 ~/.netrc # curl'de kullanıyoruz curl -x http://proxy.example.com:3128 --proxy-netrc https://api.example.com/data
Yöntem 4: Gizli depodan ortam değişkenleri aracılığıyla — CI/CD ve üretim ortamları için önerilir:
# Betikte kimlik bilgilerini ortam değişkenlerinden okuyoruz (CI/CD tarafından ayarlanan)
#!/bin/bash
PROXY_URL="http://${PROXY_USER}:${PROXY_PASS}@proxy.example.com:3128"
curl -x "${PROXY_URL}" https://api.example.com/data
Kimlik doğrulama yöntemlerinin karşılaştırma tablosu:
| Yöntem | Kolaylık | Güvenlik | Uygun olduğu yerler |
|---|---|---|---|
| URL (user:pass@host) | ⭐⭐⭐ | ⭐ | Test |
| --proxy-user bayrağı | ⭐⭐⭐ | ⭐⭐ | Tek seferlik komutlar |
| .netrc dosyası | ⭐⭐ | ⭐⭐⭐ | Yerel betikler |
| Env değişkenleri vault'tan | ⭐⭐ | ⭐⭐⭐⭐⭐ | CI/CD, üretim |
7. İstisnalar ve no_proxy: yerel adresler için proxy'yi nasıl atlayabilirsiniz
Kurumsal ve bulut ortamlarında genellikle ince ayar gereklidir: dış trafik — proxy üzerinden, iç trafik — doğrudan. no_proxy (veya NO_PROXY) değişkeni, bir istisna listesi belirlemenizi sağlar.
# Temel istisnalar export no_proxy="localhost,127.0.0.1,::1" # Alan adına göre istisna (nokta ile — tüm alt alan adları) export no_proxy="localhost,127.0.0.1,.internal.company.com,.corp.local" # IP aralığına göre istisna (CIDR notasyonu her yerde çalışmaz!) export no_proxy="localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16" # AWS için: metadata endpoint ve iç adresleri hariç tut export no_proxy="localhost,127.0.0.1,169.254.169.254,.amazonaws.com.internal"
⚠️ no_proxy'nin önemli bir özelliği:
CIDR notasyonu (10.0.0.0/8) her araç tarafından desteklenmez. curl, 7.86.0 sürümünden itibaren destekler. wget — hiç desteklemez. Uyumluluk için, belirli IP'leri veya 10. gibi maskeleri listelemek daha iyidir (10 ile başlayan her şey).
Kubernetes ortamı için pratik bir örnek, API sunucusunu ve iç hizmetleri hariç tutmaktır:
export no_proxy="localhost,127.0.0.1,10.96.0.0/12,10.244.0.0/16,.cluster.local,.svc,.default"
export NO_PROXY="${no_proxy}"
8. CI/CD'de proxy: GitHub Actions, GitLab CI, Docker
CI/CD boru hatlarında proxy ayarlamak, kurumsal ağlarda veya internete sınırlı erişimle çalışan DevOps mühendisleri için en sık karşılaşılan görevlerden biridir. Popüler platformlar için belirli yapılandırmaları inceleyelim.
GitHub Actions
# .github/workflows/deploy.yml
name: Deploy
on: [push]
jobs:
deploy:
runs-on: ubuntu-latest
env:
http_proxy: ${{ secrets.PROXY_URL }}
https_proxy: ${{ secrets.PROXY_URL }}
no_proxy: "localhost,127.0.0.1,.github.com"
steps:
- uses: actions/checkout@v3
- name: Bağımlılıkları indir
run: |
curl -x "${http_proxy}" https://external-api.example.com/config.json -o config.json
wget -e use_proxy=yes -e http_proxy="${http_proxy}" https://releases.example.com/app-v1.0.tar.gz
GitLab CI
# .gitlab-ci.yml
variables:
http_proxy: "http://proxy.company.com:3128"
https_proxy: "http://proxy.company.com:3128"
no_proxy: "localhost,127.0.0.1,.gitlab.company.com"
build:
stage: build
script:
- curl -x "${http_proxy}" https://registry.npmjs.org/package -o package.json
- wget -e use_proxy=yes -e http_proxy="${http_proxy}" https://example.com/resource.tar.gz
Docker: görüntü oluşturma sırasında proxy
# Proxy'yi build argümanları aracılığıyla geçirme docker build \ --build-arg http_proxy=http://proxy.example.com:3128 \ --build-arg https_proxy=http://proxy.example.com:3128 \ --build-arg no_proxy=localhost,127.0.0.1 \ -t myapp:latest . # Dockerfile'da değişkenleri almak için ARG kullanıyoruz
# Dockerfile FROM ubuntu:22.04 ARG http_proxy ARG https_proxy ARG no_proxy ENV http_proxy=${http_proxy} ENV https_proxy=${https_proxy} ENV no_proxy=${no_proxy} RUN apt-get update && apt-get install -y curl wget RUN curl -x "${http_proxy}" https://example.com/setup.sh | bash # Son görüntüde proxy değişkenlerini temizliyoruz (isteğe bağlı) ENV http_proxy="" ENV https_proxy=""
Docker daemon için küresel proxy ayarı (docker pull işlemlerinin proxy üzerinden yapılması için):
# /etc/systemd/system/docker.service.d/proxy.conf [Service] Environment="HTTP_PROXY=http://proxy.example.com:3128" Environment="HTTPS_PROXY=http://proxy.example.com:3128" Environment="NO_PROXY=localhost,127.0.0.1,.internal.registry.com" # docker'ı yeniden başlatıyoruz systemctl daemon-reload systemctl restart docker
9. Bash betiklerinde proxy döndürme
Eğer dış API'lere veya hizmetlere çok sayıda istek yapmanız gerekiyorsa — proxy döndürme, yükü dağıtmanıza ve IP'ye göre engellemelerden kaçınmanıza olanak tanır. Bu, fiyat izleme, veri toplama veya farklı bölgelerden kaynakların erişilebilirliğini test etme gibi durumlarda özellikle geçerlidir.
Bu tür görevler için datacenter proxy'leri iyi bir seçimdir — toplu isteklerde yüksek hız ve istikrar sağlarlar.
#!/bin/bash # rotate_proxy.sh — bir listeden proxy döndürme PROXY_LIST=( "http://user:[email protected]:3128" "http://user:[email protected]:3128" "http://user:[email protected]:3128" "http://user:[email protected]:3128" ) URLS_FILE="urls.txt" OUTPUT_DIR="./results" mkdir -p "${OUTPUT_DIR}" PROXY_COUNT=${#PROXY_LIST[@]} INDEX=0 while IFS= read -r url; do PROXY="${PROXY_LIST[$INDEX]}" FILENAME=$(echo "${url}" | md5sum | cut -d' ' -f1) echo "İstek yapılıyor: ${url} proxy $((INDEX + 1))/${PROXY_COUNT} üzerinden" curl -x "${PROXY}" \ --max-time 30 \ --retry 3 \ --retry-delay 2 \ --silent \ --output "${OUTPUT_DIR}/${FILENAME}.html" \ "${url}" if [ $? -eq 0 ]; then echo " ✓ Başarılı" else echo " ✗ Başarısız, bir sonraki proxy'yi deniyoruz..." INDEX=$(( (INDEX + 1) % PROXY_COUNT )) curl -x "${PROXY_LIST[$INDEX]}" \ --max-time 30 \ --silent \ --output "${OUTPUT_DIR}/${FILENAME}.html" \ "${url}" fi # Bir sonraki proxy'ye geçiyoruz INDEX=$(( (INDEX + 1) % PROXY_COUNT )) # İstekler arasında kısa bir ara sleep 0.5 done < "${URLS_FILE}" echo "Tamamlandı! Sonuçlar ${OUTPUT_DIR} dizinine kaydedildi"
Daha gelişmiş bir seçenek — kullanımdan önce proxy'nin çalışabilirliğini kontrol etmektir:
#!/bin/bash # check_proxy.sh — proxy erişilebilirliğini kontrol etme check_proxy() { local proxy_url="$1" local test_url="https://api.ipify.org" result=$(curl -x "${proxy_url}" \ --max-time 10 \ --silent \ --write-out "%{http_code}" \ --output /dev/null \ "${test_url}") if [ "${result}" -eq 200 ]; then echo "CANLI" else echo "ÖLÜ" fi } # Proxy üzerinden dış IP'yi alıyoruz get_proxy_ip() { local proxy_url="$1" curl -x "${proxy_url}" --max-time 10 --silent https://api.ipify.org } PROXY="http://user:[email protected]:3128" STATUS=$(check_proxy "${PROXY}") echo "Proxy durumu: ${STATUS}" if [ "${STATUS}" == "CANLI" ]; then EXTERNAL_IP=$(get_proxy_ip "${PROXY}") echo "Proxy üzerinden dış IP: ${EXTERNAL_IP}" fi
10. Hata ayıklama ve yaygın hatalar
Proxy ile çalışmak, özellikle ilk ayarlarda hatalarla kaçınılmaz olarak ilişkilidir. En yaygın sorunları ve bunların nasıl teşhis edileceğini inceleyelim.
Ayrıntılı mod ile teşhis
# curl için en ayrıntılı çıktı curl -vvv -x http://proxy.example.com:3128 https://api.example.com/data 2>&1 | head -50 # Çıktıda neye bakmalısınız: # * proxy.example.com'a bağlandı — proxy ile bağlantı kuruldu # CONNECT api.example.com:443 — tünel isteği # HTTP/1.1 200 Bağlantı kuruldu — tünel açıldı # * TLS kullanarak SSL bağlantısı — TLS çalışıyor # wget hata ayıklama wget -d -e use_proxy=yes -e http_proxy=http://proxy.example.com:3128 https://api.example.com/data
Yaygın hatalar ve çözümler
| Hata | Sebep | Çözüm |
|---|---|---|
407 Proxy Authentication Required |
Kimlik bilgileri iletilmedi | Proxy URL'sine user:pass ekleyin veya --proxy-user bayrağını kullanın |
Bağlantı reddedildi |
Yanlış port veya proxy erişilemez | Portu kontrol edin: nc -zv proxy.host 3128 |
SSL sertifika hatası |
Kurumsal proxy ile SSL denetimi | Kurumsal CA ekleyin: --cacert /path/to/ca.crt |
Proxy çözülemedi |
DNS proxy adını çözmüyor | İsim yerine IP kullanın veya DNS'i kontrol edin |
Zaman aşımı |
Proxy yavaş veya aşırı yüklenmiş | Zaman aşımını artırın: --max-time 60 |