curl और wget के लिए प्रॉक्सी सेटअप: सिस्टम एडमिनिस्ट्रेटर्स और DevOps के लिए व्यावहारिक उदाहरण

यदि आप सर्वरों का प्रशासन करते हैं, स्वचालन स्क्रिप्ट लिखते हैं या कॉर्पोरेट अवसंरचना में एप्लिकेशन तैनात करते हैं — sooner या later आपको curl या wget के ट्रैफ़िक को प्रॉक्सी के माध्यम से भेजने की आवश्यकता होगी। यह एक कॉर्पोरेट प्रॉक्सी हो सकता है, पैकेज डाउनलोड करते समय भू-प्रतिबंधों को बायपास करना, या बाहरी API के लिए बड़े पैमाने पर अनुरोधों के लिए IP रोटेशन। इस लेख में — केवल प्रैक्टिस: कमांड, कॉन्फ़िग्स, कोड के उदाहरण बिना पानी के।

1. curl और wget प्रॉक्सी के साथ कैसे काम करते हैं: बुनियादी तंत्र

कॉन्फ़िग्स में जाने से पहले, यह समझना महत्वपूर्ण है कि पर्दे के पीछे क्या हो रहा है। दोनों उपकरण दो मुख्य प्रॉक्सी प्रोटोकॉल का समर्थन करते हैं: HTTP/HTTPS और SOCKS5। इनकी कार्यप्रणाली अलग है, और यह प्रभावित करता है कि किसी विशेष कार्य के लिए किस प्रकार की प्रॉक्सी का चयन करना है।

HTTP-प्रॉक्सी एप्लिकेशन प्रोटोकॉल स्तर पर एक मध्यस्थ के रूप में कार्य करता है। जब curl HTTP-प्रॉक्सी के माध्यम से अनुरोध भेजता है, तो वह वास्तव में प्रॉक्सी सर्वर से कहता है: "मेरे लिए इस URL पर GET अनुरोध करें"। 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

प्रॉक्सी कनेक्शन की डिबगिंग के लिए उपयोगी ध्वज:

# विस्तृत मोड: सभी हेडर दिखाई देते हैं, प्रॉक्सी के लिए 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. curl और wget में SOCKS5 प्रॉक्सी: सेटअप और उदाहरण

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 का उपयोग करना:

# स्थानीय पोर्ट 1080 पर SOCKS5 के साथ SSH टनल खोलें
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 SOCKS5 का समर्थन करता है 1.19 संस्करण से। पुराने संस्करणों (CentOS 7, Ubuntu 16.04) में आपको बायपास समाधान का उपयोग करना होगा: proxychains, tsocks, या SOCKS5 की आवश्यकता वाले कार्यों के लिए curl पर स्विच करना होगा।

6. प्रॉक्सी पर प्रमाणीकरण: लॉगिन और पासवर्ड

अधिकांश व्यावसायिक प्रॉक्सी और कॉर्पोरेट प्रॉक्सी सर्वर प्रमाणीकरण की आवश्यकता होती है। क्रेडेंशियल्स को पास करने के कई तरीके हैं — प्रत्येक के अपने सुरक्षा लाभ और हानि हैं।

विधि 1: URL में क्रेडेंशियल्स — सरल, लेकिन असुरक्षित (पासवर्ड प्रक्रियाओं की सूची में दिखाई देता है):

curl -x http://user:p%[email protected]:3128 https://api.example.com/data
# पासवर्ड में विशेष वर्णों को URL-कोडित करना आवश्यक है: @ → %40, : → %3A

विधि 2: curl में --proxy-user ध्वज — पासवर्ड को कमांड लाइन में निर्दिष्ट करने की आवश्यकता नहीं है, 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 के लिए: मेटाडेटा एंडपॉइंट और आंतरिक पते को छोड़ें
export no_proxy="localhost,127.0.0.1,169.254.169.254,.amazonaws.com.internal"

Kubernetes वातावरण के लिए व्यावहारिक उदाहरण, जहाँ API सर्वर और आंतरिक सेवाओं को छोड़ने की आवश्यकता है:

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 डेमन के लिए वैश्विक प्रॉक्सी सेटिंग (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 "Requesting: ${url} via proxy $((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 "  ✓ Success"
  else
    echo "  ✗ Failed, trying next proxy..."
    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 "Done! Results saved to ${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 "ALIVE"
  else
    echo "DEAD"
  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 "Proxy status: ${STATUS}"

if [ "${STATUS}" == "ALIVE" ]; then
  EXTERNAL_IP=$(get_proxy_ip "${PROXY}")
  echo "External IP via proxy: ${EXTERNAL_IP}"
fi

10. डिबगिंग और सामान्य त्रुटियाँ

प्रॉक्सी के साथ काम करना अनिवार्य रूप से त्रुटियों के साथ आता है — विशेष रूप से प्रारंभिक सेटअप के दौरान। सबसे सामान्य समस्याओं और उनके निदान के तरीकों पर चर्चा करते हैं।

विस्तृत मोड के माध्यम से निदान

# curl का अधिकतम विस्तृत आउटपुट
curl -vvv -x http://proxy.example.com:3128 https://api.example.com/data 2>&1 | head -50

# आउटपुट में क्या देखना है:
# * Connected to proxy.example.com — प्रॉक्सी से कनेक्शन स्थापित
# CONNECT api.example.com:443 — सुरंग के लिए अनुरोध
# HTTP/1.1 200 Connection established — सुरंग खुली
# * SSL connection using TLS — TLS कार्य कर रहा है

# wget डिबगिंग
wget -d -e use_proxy=yes -e http_proxy=http://proxy.example.com:3128 https://api.example.com/data

सामान्य त्रुटियाँ और समाधान