تنظیم پروکسی برای curl و wget: مثال‌های عملی برای مدیران سیستم و DevOps

اگر شما سرورها را مدیریت می‌کنید، اسکریپت‌های اتوماسیون می‌نویسید یا برنامه‌ها را در زیرساخت شرکتی مستقر می‌کنید — دیر یا زود با نیاز به هدایت ترافیک curl یا wget از طریق پروکسی مواجه خواهید شد. این می‌تواند پروکسی شرکتی، دور زدن مسدودیت‌های جغرافیایی هنگام دانلود بسته‌ها، یا چرخش IP در درخواست‌های انبوه به API‌های خارجی باشد. در این مقاله — فقط عمل: دستورات، پیکربندی‌ها، مثال‌های کد بدون حاشیه.

1. چگونه curl و wget با پروکسی کار می‌کنند: مکانیزم‌های پایه

قبل از اینکه به پیکربندی‌ها بپردازیم، مهم است که بفهمیم زیر کاپوت چه اتفاقی می‌افتد. هر دو ابزار از دو پروتکل اصلی پروکسی پشتیبانی می‌کنند: HTTP/HTTPS و SOCKS5. مکانیک آن‌ها متفاوت است و این بر نوع پروکسی که باید برای وظیفه خاص انتخاب کنید تأثیر می‌گذارد.

پروکسی HTTP به عنوان واسطه‌ای در سطح پروتکل کاربردی عمل می‌کند. وقتی curl درخواست را از طریق پروکسی HTTP ارسال می‌کند، به طور واقعی به سرور پروکسی می‌گوید: «یک درخواست GET به این URL به جای من انجام بده». برای ترافیک HTTPS از روش CONNECT استفاده می‌شود — curl از پروکسی می‌خواهد که یک تونل به میزبان هدف ایجاد کند، پس از آن دست دادن TLS به طور مستقیم بین مشتری و سرور مقصد انجام می‌شود. این مهم است: در این حالت پروکسی محتوای ترافیک HTTPS را نمی‌بیند.

SOCKS5 در سطح پایین‌تری کار می‌کند — این پروکسی TCP/UDP را بدون وابستگی به پروتکل سطح کاربردی پروکسی می‌کند. این SOCKS5 را عمومی‌تر می‌کند: از طریق آن می‌توان نه تنها HTTP/HTTPS، بلکه پروتکل‌های دیگر را نیز هدایت کرد. علاوه بر این، SOCKS5 از حل DNS در سمت سرور پروکسی پشتیبانی می‌کند — این برای جلوگیری از نشت DNS به شدت مهم است.

curl از هر دو پروتکل به طور بومی از نسخه‌های بسیار قدیمی پشتیبانی می‌کند. wget به طور تاریخی پشتیبانی محدودتری از SOCKS5 داشته است — در نسخه‌های قدیمی‌تر (قبل از 1.19) اصلاً پشتیبانی از SOCKS5 وجود ندارد، فقط پروکسی HTTP. این باید در هنگام نوشتن اسکریپت‌هایی که باید در توزیع‌های مختلف کار کنند، در نظر گرفته شود.

برای بررسی نسخه wget می‌توانید از دستور wget --version استفاده کنید. برای curl — curl --version، در آنجا همچنین خواهید دید که با کدام پروتکل‌ها کتابخانه libcurl ساخته شده است.

2. متغیرهای محیطی: سریع‌ترین راه تنظیم

بهترین و زیباترین راه برای تنظیم پروکسی برای curl و wget — از طریق متغیرهای محیطی است. این به صورت سیستمی کار می‌کند: نیازی به تغییر هر اسکریپت نیست، فقط کافی است متغیرها را یک بار در جلسه تنظیم کنید یا آن‌ها را به پروفایل کاربر اضافه کنید.

هر دو ابزار یکسان متغیرهای استاندارد را می‌خوانند:

# برای ترافیک HTTP
export http_proxy="http://proxy.example.com:3128"

# برای ترافیک HTTPS
export https_proxy="http://proxy.example.com:3128"

# تکرار در حروف بزرگ (برخی برنامه‌ها فقط آن‌ها را می‌خوانند)
export HTTP_PROXY="http://proxy.example.com:3128"
export HTTPS_PROXY="http://proxy.example.com:3128"

# برای FTP (اگر نیاز باشد)
export ftp_proxy="http://proxy.example.com:3128"

# استثناها — آدرس‌هایی که از طریق پروکسی نمی‌روند
export no_proxy="localhost,127.0.0.1,::1,192.168.0.0/16,.internal.company.com"

نکته مهم: curl به حروف بزرگ و کوچک متغیرها حساس است بسته به نسخه. برای جلوگیری از سورپرایز — همیشه هر دو نسخه را تنظیم کنید: در حروف کوچک و بزرگ. این یک عمل استاندارد در DevOps است.

برای اینکه تنظیمات به طور مداوم برای یک کاربر خاص اعمال شود، خطوط را به ~/.bashrc یا ~/.profile اضافه کنید. برای اسکریپت‌ها و سرویس‌های سیستمی — در /etc/environment یا در فایل واحد systemd از طریق دستور Environment= قرار دهید.

# /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

اگر پروکسی نیاز به احراز هویت دارد، نام کاربری و رمز عبور به طور مستقیم در URL متغیر قرار می‌گیرند:

export http_proxy="http://username:[email protected]:3128"
export https_proxy="http://username:[email protected]:3128"

3. پرچم‌های curl برای کار با پروکسی: بررسی کامل

curl مجموعه غنی از پرچم‌ها را برای مدیریت پروکسی مستقیماً از خط فرمان ارائه می‌دهد. این زمانی مفید است که نیاز به انجام یک درخواست یک‌باره از طریق پروکسی دارید، بدون اینکه تنظیمات سیستمی را تغییر دهید.

پرچم اصلی — -x یا --proxy:

# پروکسی HTTP پایه
curl -x http://proxy.example.com:3128 https://api.example.com/data

# فرم کوتاه
curl -x proxy.example.com:3128 https://api.example.com/data

# با مشخص کردن پروتکل به وضوح
curl --proxy http://proxy.example.com:3128 https://api.example.com/data

# بررسی IP خارجی از طریق پروکسی
curl -x http://proxy.example.com:3128 https://api.ipify.org

برای نادیده گرفتن متغیرهای محیطی و اتصال مستقیم (دور زدن پروکسی تنظیم شده) از پرچم --noproxy استفاده می‌شود:

# نادیده گرفتن پروکسی برای میزبان خاص
curl --noproxy "internal.company.com" https://internal.company.com/api

# نادیده گرفتن پروکسی به طور کامل (حتی اگر متغیرهای env تنظیم شده باشند)
curl --noproxy "*" https://api.example.com/data

پرچم‌های مفید برای اشکال‌زدایی اتصالات پروکسی:

# حالت verbose: همه هدرها را می‌بینید، از جمله CONNECT به پروکسی
curl -v -x http://proxy.example.com:3128 https://api.example.com/data

# فقط هدرهای پاسخ
curl -I -x http://proxy.example.com:3128 https://api.example.com/data

# زمان اتصال از طریق پروکسی را نشان دهید
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

تنظیم پروکسی از طریق فایل پیکربندی ~/.curlrc — راحت است، اگر نمی‌خواهید هر بار پرچم‌ها را بنویسید:

# ~/.curlrc
proxy = http://proxy.example.com:3128
proxy-user = username:password
noproxy = localhost,127.0.0.1,.internal.company.com

برای اسکریپت‌های سیستمی می‌توانید یک پیکربندی جداگانه ایجاد کنید و آن را به وضوح از طریق curl -K /path/to/config مشخص کنید — این امکان را می‌دهد که پروفایل‌های مختلف پروکسی برای وظایف مختلف داشته باشید.

4. تنظیم پروکسی در wget: پرچم‌ها و فایل پیکربندی

wget از curl کمتر انعطاف‌پذیر است، اما برای وظایف معمولی — دانلود فایل‌ها، آینه‌سازی بازگشتی سایت‌ها — امکانات آن کاملاً کافی است. پروکسی در wget را می‌توان به سه روش تنظیم کرد: از طریق متغیرهای محیطی (که در بالا بررسی کردیم)، از طریق پرچم‌های خط فرمان و از طریق فایل پیکربندی ~/.wgetrc.

پرچم‌های خط فرمان wget برای پروکسی:

# پروکسی HTTP از طریق پرچم
wget -e use_proxy=yes \
     -e http_proxy=http://proxy.example.com:3128 \
     https://example.com/file.tar.gz

# HTTPS از طریق پروکسی
wget -e use_proxy=yes \
     -e https_proxy=http://proxy.example.com:3128 \
     https://example.com/file.tar.gz

# با احراز هویت
wget -e use_proxy=yes \
     -e http_proxy=http://username:[email protected]:3128 \
     https://example.com/file.tar.gz

# غیرفعال کردن پروکسی برای یک دستور خاص (اگر متغیرهای env تنظیم شده باشند)
wget --no-proxy https://internal.company.com/file.tar.gz

فایل پیکربندی ~/.wgetrc — روش ترجیحی برای تنظیم دائمی:

# ~/.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

# اگر پروکسی نیاز به احراز هویت دارد
proxy_user = username
proxy_password = secretpassword

برای استفاده سیستمی (برای همه کاربران) از /etc/wgetrc استفاده می‌شود — همان فرمت، اما به طور جهانی اعمال می‌شود. این برای سرورهایی که همه عملیات دانلود باید از طریق پروکسی شرکتی انجام شود، راحت است.

مثال عملی: دانلود بازگشتی سایت از طریق پروکسی با محدودیت عمق و سرعت:

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. پروکسی SOCKS5 در curl و wget: تنظیم و مثال‌ها

SOCKS5 — پروتکلی ترجیحی‌تر برای وظایفی است که در آن ناشناسی یا کار با پورت‌های غیرمعمول مهم است. برای مدیران سیستم و مهندسان DevOps، SOCKS5 اغلب هنگام کار از طریق تونل‌های SSH و همچنین هنگام اتصال به پروکسی‌های مسکونی که ترافیک کاربران واقعی را شبیه‌سازی می‌کنند، استفاده می‌شود.

در curl، SOCKS5 از طریق پیشوند خاصی در URL پروکسی پشتیبانی می‌شود:

# SOCKS5 با حل DNS در سمت مشتری (ممکن است نشت DNS وجود داشته باشد!)
curl --socks5 proxy.example.com:1080 https://api.example.com/data

# SOCKS5 با حل DNS در سمت پروکسی (توصیه می‌شود!)
curl --socks5-hostname proxy.example.com:1080 https://api.example.com/data

# از طریق پرچم -x با مشخص کردن پروتکل به وضوح
curl -x socks5h://proxy.example.com:1080 https://api.example.com/data

# با احراز هویت
curl -x socks5h://username:[email protected]:1080 https://api.example.com/data

# SOCKS5 از طریق متغیر محیطی
export all_proxy="socks5h://proxy.example.com:1080"
curl https://api.example.com/data

سناریوی محبوب در DevOps — استفاده از SSH به عنوان پروکسی SOCKS5 برای تونل‌سازی ترافیک از طریق هاست باسیون:

# باز کردن تونل SSH با SOCKS5 در پورت محلی 1080
ssh -D 1080 -f -C -q -N [email protected]

# حالا از این تونل در curl استفاده کنید
curl -x socks5h://localhost:1080 https://internal-api.private.network/data

# یا از طریق متغیر محیطی برای همه درخواست‌ها در جلسه
export all_proxy="socks5h://localhost:1080"
wget https://internal-resource.private.network/file.tar.gz

wget از نسخه 1.19 به بعد از SOCKS5 پشتیبانی می‌کند. در نسخه‌های قدیمی‌تر (CentOS 7، Ubuntu 16.04) باید از راه‌حل‌های دور زدن استفاده کنید: proxychains، tsocks، یا به curl برای وظایفی که نیاز به SOCKS5 دارند، منتقل شوید.

6. احراز هویت در پروکسی: نام کاربری و رمز عبور

بیشتر پروکسی‌های تجاری و سرورهای پروکسی شرکتی نیاز به احراز هویت دارند. چندین روش برای انتقال اعتبارنامه‌ها وجود دارد — هر کدام با مزایا و معایب خود از نظر امنیت.

روش 1: اعتبارنامه‌ها در URL — ساده، اما ناامن (رمز عبور در لیست فرآیندها قابل مشاهده است):

curl -x http://user:p%[email protected]:3128 https://api.example.com/data
# کاراکترهای خاص در رمز عبور باید URL-کدگذاری شوند: @ → %40، : → %3A

روش 2: پرچم --proxy-user در curl — می‌توانید رمز عبور را در خط فرمان مشخص نکنید، curl به صورت تعاملی از آن درخواست می‌کند:

# نام کاربری و رمز عبور در پرچم (هنوز هم در ps aux قابل مشاهده است)
curl -x http://proxy.example.com:3128 \
     --proxy-user "username:password" \
     https://api.example.com/data

# فقط نام کاربری — curl از رمز عبور به صورت تعاملی می‌پرسد
curl -x http://proxy.example.com:3128 \
     --proxy-user "username" \
     https://api.example.com/data

روش 3: از طریق فایل .netrc — امن‌ترین روش برای اسکریپت‌ها:

# ~/.netrc
machine proxy.example.com
login username
password secretpassword

# محدود کردن دسترسی به فایل
chmod 600 ~/.netrc

# استفاده در curl
curl -x http://proxy.example.com:3128 --proxy-netrc https://api.example.com/data

روش 4: از طریق متغیرهای محیطی از خزانه‌های مخفی — برای CI/CD و محیط‌های تولید توصیه می‌شود:

# در اسکریپت اعتبارنامه‌ها را از متغیرها می‌خوانیم (که CI/CD تعیین می‌کند)
#!/bin/bash
PROXY_URL="http://${PROXY_USER}:${PROXY_PASS}@proxy.example.com:3128"
curl -x "${PROXY_URL}" https://api.example.com/data

جدول مقایسه روش‌های احراز هویت:

7. استثناها و no_proxy: چگونه پروکسی را برای آدرس‌های محلی دور بزنیم

در محیط‌های شرکتی و ابری اغلب نیاز به تنظیمات دقیق است: ترافیک خارجی — از طریق پروکسی، داخلی — به طور مستقیم. متغیر no_proxy (یا NO_PROXY) امکان تعیین لیست استثناها را فراهم می‌کند.

# استثناهای پایه
export no_proxy="localhost,127.0.0.1,::1"

# استثنا بر اساس دامنه (با نقطه — همه زیر دامنه‌ها)
export no_proxy="localhost,127.0.0.1,.internal.company.com,.corp.local"

# استثنا بر اساس محدوده IP (نوتاسیون CIDR در همه جا کار نمی‌کند!)
export no_proxy="localhost,127.0.0.1,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16"

# برای AWS: نقطه انتهای metadata و آدرس‌های داخلی را استثنا کنید
export no_proxy="localhost,127.0.0.1,169.254.169.254,.amazonaws.com.internal"

مثال عملی برای محیط Kubernetes، جایی که باید API-server و سرویس‌های داخلی را استثنا کنید:

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: GitHub Actions، GitLab CI، Docker

تنظیم پروکسی در پایپ‌لاین‌های CI/CD — یکی از رایج‌ترین وظایف مهندسان DevOps است که در شبکه‌های شرکتی یا با دسترسی محدود به اینترنت کار می‌کنند. بیایید پیکربندی‌های خاصی را برای پلتفرم‌های محبوب بررسی کنیم.

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: Download dependencies
        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: پروکسی در هنگام ساخت تصاویر

# انتقال پروکسی از طریق آرگومان‌های ساخت
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 از ARG برای دریافت متغیرها استفاده کنید

# 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

# پاک کردن متغیرهای پروکسی در تصویر نهایی (اختیاری)
ENV http_proxy=""
ENV https_proxy=""

تنظیم جهانی پروکسی برای Docker daemon (برای docker pull از طریق پروکسی):

# /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
systemctl daemon-reload
systemctl restart docker

9. چرخش پروکسی در اسکریپت‌های bash

اگر نیاز دارید تعداد زیادی درخواست به API‌های خارجی یا خدمات ارسال کنید — چرخش پروکسی به توزیع بار کمک می‌کند و از مسدود شدن IP جلوگیری می‌کند. این به ویژه در هنگام نظارت بر قیمت‌ها، جمع‌آوری داده‌ها یا تست دسترسی منابع از مناطق مختلف اهمیت دارد.

برای چنین وظایفی، پروکسی‌های دیتاسنتر بسیار مناسب هستند — آن‌ها سرعت و ثبات بالایی را در درخواست‌های انبوه فراهم می‌کنند.

#!/bin/bash
# rotate_proxy.sh — چرخش پروکسی از لیست

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 "در حال درخواست: ${url} از طریق پروکسی $((INDEX + 1))/${PROXY_COUNT}"
  
  curl -x "${PROXY}" \
       --max-time 30 \
       --retry 3 \
       --retry-delay 2 \
       --silent \
       --output "${OUTPUT_DIR}/${FILENAME}.html" \
       "${url}"
  
  if [ $? -eq 0 ]; then
    echo "  ✓ موفق"
  else
    echo "  ✗ ناموفق، در حال تلاش برای پروکسی بعدی..."
    INDEX=$(( (INDEX + 1) % PROXY_COUNT ))
    curl -x "${PROXY_LIST[$INDEX]}" \
         --max-time 30 \
         --silent \
         --output "${OUTPUT_DIR}/${FILENAME}.html" \
         "${url}"
  fi
  
  # رفتن به پروکسی بعدی
  INDEX=$(( (INDEX + 1) % PROXY_COUNT ))
  
  # یک وقفه کوچک بین درخواست‌ها
  sleep 0.5
  
done < "${URLS_FILE}"

echo "تمام شد! نتایج در ${OUTPUT_DIR} ذخیره شد" 

یک گزینه پیشرفته‌تر — بررسی قابلیت دسترسی پروکسی قبل از استفاده:

#!/bin/bash
# check_proxy.sh — بررسی قابلیت دسترسی پروکسی

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 "زنده"
  else
    echo "مرده"
  fi
}

# به دست آوردن IP خارجی از طریق پروکسی
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 "وضعیت پروکسی: ${STATUS}"

if [ "${STATUS}" == "زنده" ]; then
  EXTERNAL_IP=$(get_proxy_ip "${PROXY}")
  echo "IP خارجی از طریق پروکسی: ${EXTERNAL_IP}"
fi

10. اشکال‌زدایی و خطاهای متداول

کار با پروکسی به طور اجتناب‌ناپذیری با خطاها همراه است — به ویژه در هنگام تنظیم اولیه. بیایید رایج‌ترین مشکلات و روش‌های تشخیص آن‌ها را بررسی کنیم.

تشخیص با استفاده از حالت verbose

# خروجی حداکثر جزئیات curl
curl -vvv -x http://proxy.example.com:3128 https://api.example.com/data 2>&1 | head -50

# چه چیزی را در خروجی مشاهده کنید:
# * به proxy.example.com متصل شد — اتصال به پروکسی برقرار شد
# CONNECT api.example.com:443 — درخواست برای تونل
# HTTP/1.1 200 Connection established — تونل باز شد
# * اتصال SSL با استفاده از TLS — TLS کار می‌کند

# اشکال‌زدایی wget
wget -d -e use_proxy=yes -e http_proxy=http://proxy.example.com:3128 https://api.example.com/data

خطاهای متداول و راه‌حل‌ها