Bloga geri dön

Curl ve Wget için Proxy Ayarları: Sistem Yöneticileri ve DevOps için Pratik Örnekler

Curl ve wget için proxy ayarlarıyla ilgili kapsamlı bir rehber, pratik kod örnekleri, SOCKS5 desteği, kimlik doğrulama ve CI/CD boru hatlarında otomasyon.

📅3 Nisan 2026
```html

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
```