← Back to Blog
RUENESZHARPTDEFRJAKOITTRIDVIFAHI

लॉगिन और पासवर्ड के साथ प्रॉक्सी: gost, 3proxy, Squid और proxychains पर स्थानीय गेटवे बिना प्रमाणीकरण के

प्रोग्राम केवल पता और पोर्ट मांगता है, और प्रॉक्सी में लॉगिन और पासवर्ड है? स्थानीय गेटवे उठाएं: gost एक कमांड के साथ, 3proxy प्रत्येक प्रोफ़ाइल के लिए पोर्ट के साथ, Squid लॉग के साथ या proxychains-ng सॉफ़्टवेयर के लिए जो प्रॉक्सी का समर्थन नहीं करता है। कमांड, कॉन्फ़िग और त्रुटियाँ, जिनके कारण असली IP लीक होता है।

📅October 11, 2026
लॉगिन और पासवर्ड के साथ प्रॉक्सी: gost, 3proxy, Squid और proxychains पर स्थानीय गेटवे बिना प्रमाणीकरण के

आपने प्रॉक्सी खरीदी, आपको login:password@host:port जैसा स्ट्रिंग मिला, और प्रोग्राम केवल "पता और पोर्ट" मांग रहा है। यह एक परिचित स्थिति है: Chrome में --proxy-server फ्लैग, Windows और Android की सिस्टम सेटिंग्स, पुराना पार्सर, Selenium-grid, बिना पासवर्ड के उपयोगिता। समाधान वही है जो कई वर्षों से है — स्थानीय गेटवे: आपकी मशीन पर एक छोटा प्रॉक्सी जो बिना पासवर्ड के कनेक्शन स्वीकार करता है और असली प्रॉक्सी से कनेक्ट करते समय लॉगिन खुद डालता है। हम चार परीक्षण किए गए उपकरणों, प्रत्येक के लिए कमांड और उन गलतियों का विश्लेषण करते हैं, जिन पर आमतौर पर समय और पैसे बर्बाद होते हैं।

क्यों प्रोग्राम पासवर्ड वाले प्रॉक्सी को "समझते" नहीं हैं

प्रॉक्सी प्रदाता के साथ प्रमाणीकृत होने के दो तरीके हैं: लॉगिन और पासवर्ड (बेसिक ऑथ) द्वारा या IP की श्वेत सूची द्वारा। दूसरा विकल्प समस्या को हल करता है, लेकिन केवल तभी काम करता है जब आपके पास स्थायी बाहरी IP हो — घरेलू इंटरनेट और मोबाइल नेटवर्क में अक्सर यह नहीं होता है, और क्लाउड फ़ंक्शंस हर बार शुरू होने पर बदलते हैं। हमने दोनों तरीकों की तुलना प्रॉक्सी प्रमाणीकरण गाइड में की है।

लॉगिन और पासवर्ड के साथ हम प्रोग्रामों की सीमाओं पर अटक जाते हैं:

  • Chrome और Chromium। Chromium के दस्तावेज़ के अनुसार --proxy-server फ्लैग स्कीमा, होस्ट और पोर्ट स्वीकार करता है (उदाहरण के लिए, --proxy-server="foopy:8080") — इस सिंटैक्स में क्रेडेंशियल्स के लिए कोई फ़ील्ड नहीं है। सामान्य ब्राउज़र विंडो में पासवर्ड के साथ एक संवाद प्रदर्शित होगा, लेकिन हेडलेस मोड और ऑटो-टेस्ट में इसे भरने के लिए कोई नहीं है।
  • सिस्टम सेटिंग्स। Windows में प्रॉक्सी की मैनुअल सेटिंग और अधिकांश Android फर्मवेयर में Wi-Fi सेटिंग्स में केवल होस्ट और पोर्ट होते हैं। पासवर्ड या तो किसी विशेष एप्लिकेशन द्वारा पूछा जाएगा, या इसे कहीं नहीं डाला जा सकता।
  • पुराना और स्वयं-लिखित सॉफ़्टवेयर। कई उपयोगिताएँ और पुस्तकालय प्रॉक्सी का समर्थन करते हैं, लेकिन बिना प्रमाणीकरण के, या पासवर्ड में विशेष वर्णों पर टूट जाते हैं।
  • प्रोग्राम जो प्रॉक्सी का समर्थन नहीं करते। कंसोल उपयोगिताएँ, जो न तो पर्यावरण चर पढ़ती हैं, न ही सेटिंग्स।

स्थानीय गेटवे इन चारों मामलों को हल करता है: प्रोग्राम प्रॉक्सी 127.0.0.1:8080 को बिना पासवर्ड के देखता है, जबकि गेटवे ट्रैफ़िक को प्रदाता के पास लॉगिन के साथ भेजता है।

स्कीमा कैसे काम करता है

  1. आपकी मशीन (या VPS, जहां पार्सर चलता है) पर एक हल्का प्रॉक्सी सर्वर शुरू होता है और स्थानीय पोर्ट सुनता है, उदाहरण के लिए 127.0.0.1:8080।
  2. गेटवे के कॉन्फ़िग में "माता-पिता" (upstream) प्रॉक्सी — प्रदाता का पता, लॉगिन और पासवर्ड लिखा होता है।
  3. प्रोग्राम बिना प्रमाणीकरण के स्थानीय पोर्ट से कनेक्ट होता है।
  4. गेटवे प्रदाता के साथ कनेक्शन खोलता है, प्रमाणीकरण करता है और ट्रैफ़िक को आगे बढ़ाता है। वेबसाइट के लिए आप प्रदाता के IP पते के रूप में दिखाई देते हैं, न कि अपने।

HTTPS इस दौरान डिक्रिप्ट नहीं होता: HTTP प्रॉक्सी के माध्यम से ब्राउज़र CONNECT विधि से एक टनल स्थापित करता है, और गेटवे बस एन्क्रिप्टेड बाइट्स को पास करता है।

विकल्प 1: gost — एक कमांड, बिना कॉन्फ़िग के

gost (GO Simple Tunnel) — Windows, macOS और Linux के लिए एक निष्पादन योग्य फ़ाइल। यह गेटवे को उठाने का सबसे तेज़ तरीका है। gost में -L फ्लैग स्थानीय सेवा को निर्धारित करता है, -F — नोड, जिसके माध्यम से ट्रैफ़िक को भेजना है। क्रेडेंशियल्स सीधे नोड के पते में दिए जाते हैं:

gost -L http://127.0.0.1:8080 -F socks5://LOGIN:PASSWORD@HOST:PORT

अब कोई भी प्रोग्राम HTTP प्रॉक्सी 127.0.0.1:8080 का उपयोग कर सकता है बिना पासवर्ड के। यदि पासवर्ड में विशेष वर्ण हैं (@, :, #), तो gost की दस्तावेज़ीकरण में उन्हें auth पैरामीटर के माध्यम से base64 में पास करने का सुझाव दिया गया है:

echo -n LOGIN:PASSWORD | base64
gost -L http://127.0.0.1:8080 -F socks5://HOST:PORT?auth=<результат_base64>

ध्यान दें: यदि auth निर्दिष्ट किया गया है, तो पते में सीधे लिखे गए लॉगिन और पासवर्ड को gost नजरअंदाज कर देता है। कई -F फ्लैग एक साथ कई प्रॉक्सी की एक श्रृंखला बनाते हैं।

कब लें: जब आपको एक ब्राउज़र या स्क्रिप्ट को प्रॉक्सी के साथ जल्दी "दोस्ताना" बनाना हो, बिना पैकेज स्थापित किए और कॉन्फ़िग में संशोधन किए।

विकल्प 2: 3proxy — एक मशीन पर कई पोर्ट

3proxy — एक कॉम्पैक्ट प्रॉक्सी सर्वर जो एक फ़ाइल में कॉन्फ़िग होता है। कुंजी निर्देशिका — parent; इसकी दस्तावेज़ीकरण के अनुसार इसका सिंटैक्स: parent <weight> <type> <ip> <port> <username> <password>, और यह allow नियम के बाद आना चाहिए। गेटवे का न्यूनतम कॉन्फ़िग:

auth iponly
allow * 127.0.0.1
parent 1000 http HOST PORT LOGIN PASSWORD
proxy -p8080 -i127.0.0.1

यहाँ क्या महत्वपूर्ण है:

  • auth iponly — बिना पासवर्ड के, लेकिन ACL द्वारा जांच के साथ; नियम allow * 127.0.0.1 केवल स्थानीय कनेक्शनों की अनुमति देता है।
  • वजन 1000 का अर्थ है "हमेशा इस माता-पिता के माध्यम से"। 1000 से कम वजन वाले 3proxy का उपयोग यादृच्छिक श्रृंखलाएँ बनाने के लिए करता है।
  • माता-पिता का प्रकार: http, connect, socks4, socks5 और अन्य — उस प्रोटोकॉल को लें जो प्रदाता ने दिया है।
  • -i127.0.0.1 सेवा को स्थानीय इंटरफेस से बांधता है। डिफ़ॉल्ट रूप से 3proxy सभी इंटरफेस पर कनेक्शन स्वीकार करता है।

एक सुविधाजनक तकनीक: विभिन्न पोर्ट और प्रदाता के विभिन्न क्रेडेंशियल्स के साथ allow / parent / proxy ब्लॉक को कई बार दोहराना। इस प्रकार "पोर्ट = अलग प्रॉक्सी" प्राप्त होता है: 127.0.0.1:8081 — अमेरिका, :8082 — जर्मनी और इसी तरह। यह प्रारूप लगभग किसी भी सॉफ़्टवेयर द्वारा समझा जाता है, जिसमें वह भी शामिल है जहाँ प्रॉक्सी को "होस्ट:पोर्ट" की सूची में दर्ज किया जाता है।

कब लें: जब दर्जनों प्रोफाइल या स्ट्रीम हों, प्रत्येक को अपना आउटपुट चाहिए।

विकल्प 3: Squid — यदि कैश और लॉग की आवश्यकता हो

Squid भारी है, लेकिन कैशिंग, विस्तृत लॉग और लचीले ACL प्रदान करता है। प्रदाता को cache_peer के माध्यम से माता-पिता के नोड के रूप में लिखा जाता है, और never_direct allow all निर्देश Squid को सीधे माता-पिता के बाईपास करने से रोकता है:

http_port 127.0.0.1:3128
cache_peer HOST parent PORT 0 no-query default login=LOGIN:PASSWORD
never_direct allow all

Squid की दस्तावेज़ीकरण से कुछ बारीकियाँ:

  • ICP पोर्ट को 0 पर सेट करें, यदि माता-पिता इसे समर्थन नहीं करते — वाणिज्यिक प्रॉक्सी में यह नहीं होता है।
  • login= में URL-escape अनुक्रम (उदाहरण के लिए, %20 स्पेस के लिए) की अनुमति है, इसलिए पासवर्ड में % को %% के रूप में लिखना होगा।
  • बिना never_direct के, Squid यह तय कर सकता है कि सीधे वेबसाइट पर जाना अधिक लाभदायक है — और अनुरोध आपके असली IP के साथ चला जाएगा। पार्सिंग और मल्टी-एकाउंटिंग के लिए यह सबसे खराब परिदृश्य है।

कब लें: कार्यालय या टीम, जहाँ लॉग की आवश्यकता होती है कि कौन कहाँ गया, या एक ही संसाधनों के लिए दोहराए जाने वाले अनुरोध।

विकल्प 4: proxychains-ng — प्रोग्रामों के लिए जिनमें प्रॉक्सी का समर्थन नहीं है

यदि प्रोग्राम प्रॉक्सी का समर्थन नहीं करता है, तो proxychains-ng (Linux और macOS) मदद करेगा। यह प्रोग्राम के नेटवर्क कॉल को पकड़ता है और इसके TCP कनेक्शनों को प्रॉक्सी में लपेटता है। SOCKS4a, SOCKS5 और HTTP का समर्थन किया जाता है, प्रमाणीकरण — SOCKS के लिए लॉगिन और पासवर्ड और HTTP के लिए बेसिक। [ProxyList] अनुभाग में स्ट्रिंग का प्रारूप type ip port [login password] है:

strict_chain
proxy_dns
tcp_read_time_out 15000
tcp_connect_time_out 8000

[ProxyList]
http HOST PORT LOGIN PASSWORD

प्रारंभ: proxychains4 curl https://api.ipify.org — उत्तर में प्रदाता का IP होगा, न कि आपका।

  • strict_chain — सूची के सभी प्रॉक्सी क्रम से उपयोग किए जाते हैं, और यदि एक अनुपलब्ध है, तो कनेक्शन नहीं होगा। dynamic_chain की तुलना में अधिक सुरक्षित है, जो मृत नोड्स को छोड़ देता है।
  • proxy_dns — DNS अनुरोध भी प्रॉक्सी के माध्यम से जाते हैं। इसके बिना, आपके इंटरनेट प्रदाता को यह दिखाई देता है कि आप कौन से डोमेन अनुरोध कर रहे हैं, और वेबसाइट भौगोलिक स्थिति में DNS और IP के बीच असंगति को देख सकती है।
  • कॉन्फ़िग क्रम में खोजा जाता है: -f से फ़ाइल या PROXYCHAINS_CONF_FILE चर, फिर ./proxychains.conf, ~/.proxychains/proxychains.conf और /etc/proxychains.conf।

सीमाएँ, जिनके बारे में स्वयं लेखक लिखते हैं: केवल TCP (UDP और ICMP प्रॉक्सी नहीं होते), कई प्रक्रियाएँ उत्पन्न करने वाले प्रोग्रामों में विफलता हो सकती है, और macOS पर SIP सुरक्षा सिस्टम प्रोग्रामों को पकड़ने की अनुमति नहीं देती है।

कौन सा उपकरण चुनें: संक्षिप्त गाइड

  • एक ब्राउज़र या स्क्रिप्ट, "अभी" की आवश्यकता है — gost।
  • बहुत सारे प्रोफाइल, प्रत्येक के लिए अपना IP या देश — 3proxy एकाउंट के लिए अलग पोर्ट के साथ।
  • टीम, अनुरोधों का लॉग, कैश — Squid।
  • प्रोग्राम जो प्रॉक्सी सेटिंग्स के बिना है — proxychains-ng।

पाँच गलतियाँ जो सबसे महंगी साबित होती हैं

  1. गेटवे सभी इंटरफेस सुनता है। VPS पर -L http://:8080 के साथ gost चलाया — और आपके गीगाबाइट्स पर पूरे इंटरनेट के लिए एक खुला प्रॉक्सी मिला। ओपन प्रॉक्सी स्कैनर जल्दी से मिल जाते हैं। हमेशा 127.0.0.1 निर्दिष्ट करें, और यदि गेटवे का उपयोग अन्य मशीनों द्वारा किया जाता है — तो फ़ायरवॉल से पोर्ट बंद करें। हमने CARBONATO वर्म के विश्लेषण में लिखा है कि कैसे बोटनेट्स सर्वरों पर खुले पोर्ट जल्दी से खोजते हैं।
  2. गेटवे के बिना लीक। Squid बिना never_direct, proxychains बिना proxy_dns, ब्राउज़र जो WebRTC/UDP के माध्यम से सीधे जाता है — ये सभी आपके असली IP को उजागर करते हैं। IP पहचानने वाली सेवा और DNS लीक परीक्षण पर परिणाम की जांच करें।
  3. सभी खातों के लिए एक गेटवे। यदि 30 एंटी-डिटेक्ट प्रोफाइल एक पोर्ट पर एक ही स्टिकी सत्र को देख रहे हैं, तो सभी का एक ही IP होगा — यह खातों के बंडल की सीधी राह है। प्रोफाइल को पोर्ट के अनुसार अलग करें या प्रदाता के सत्र के पैरामीटर का उपयोग करें।
  4. पासवर्ड में विशेष वर्ण। @ और : login:pass@host जैसे पते के विश्लेषण को तोड़ते हैं। gost में base64 पैरामीटर का उपयोग करें, Squid में एस्केपिंग करें या बिना विशेष वर्णों के पासवर्ड उत्पन्न करें।
  5. गेटवे — एक अतिरिक्त हॉप और विफलता का बिंदु। स्थानीय मशीन पर देरी लगभग शून्य है, लेकिन यदि गेटवे दूसरे डेटा सेंटर में है, तो प्रत्येक अनुरोध में नेटवर्क देरी जुड़ती है। गेटवे को प्रोग्राम के पास रखें और ऑटो-स्टार्ट सेट करें (systemd, Windows सेवा), अन्यथा सर्वर को पुनः चालू करने के बाद पार्सर चुपचाप कहीं चला जाएगा।

गेटवे के पीछे कौन सी प्रॉक्सी स्थापित करें

गेटवे को इस बात की परवाह नहीं है कि इसके पीछे कौन सा प्रॉक्सी प्रकार है, — चयन कार्य पर निर्भर करता है:

  • रिहायशी प्रॉक्सी — सुरक्षित वेबसाइटों, मार्केटप्लेस और एंटी-डिटेक्ट प्रोफाइल के लिए: घरेलू उपयोगकर्ताओं के IP एंटी-बॉट्स द्वारा कम संदेह पैदा करते हैं।
  • मोबाइल प्रॉक्सी — सोशल मीडिया और ऐप्स के लिए, जहाँ जांच सबसे सख्त होती है: एक मोबाइल ऑपरेटर के एक IP (CGNAT के माध्यम से) आमतौर पर कई वास्तविक ग्राहकों के लिए नेटवर्क में जाता है, और इसे ब्लॉक करना प्लेटफ़ॉर्म के लिए जोखिम भरा होता है।
  • डेटा सेंटर प्रॉक्सी — बिना सख्त सुरक्षा के बड़े कार्यों के लिए: उपलब्धता की जांच, API, परीक्षण। प्रति गीगाबाइट सबसे सस्ता।

यदि प्रॉक्सी रोटेशन के साथ है, तो IP बदलने की लॉजिक आमतौर पर प्रदाता द्वारा निर्धारित की जाती है — लॉगिन में पैरामीटर या डैशबोर्ड में सेटिंग्स के माध्यम से। गेटवे इसे नहीं तोड़ता: यह लॉगिन को जैसा है वैसा ही पास करता है। इसलिए विभिन्न सत्र पैरामीटर के साथ कई पोर्ट उठाना सुविधाजनक है — एक प्रत्येक अनुरोध पर नए IP के साथ, दूसरा 30 मिनट के लिए स्थिर IP के साथ।

निष्कर्ष

लॉगिन और पासवर्ड के साथ प्रॉक्सी किसी भी प्रोग्राम के लिए उपयुक्त है, यदि उनके बीच एक स्थानीय गेटवे स्थापित किया जाए। gost एक कमांड में समस्या को हल करता है, 3proxy "पोर्ट = प्रोफ़ाइल" के लिए सुविधाजनक है, Squid टीमों के लिए लॉग के साथ है, और proxychains-ng प्रॉक्सी से कनेक्ट करता है, यहां तक कि सॉफ़्टवेयर जो प्रॉक्सी के बारे में कुछ नहीं जानता। मुख्य नियम: केवल 127.0.0.1 को सुनें, माता-पिता के बाईपास में सीधे कनेक्शन को मना करें और यह सुनिश्चित करें कि वेबसाइट प्रदाता के IP को देखती है, न कि आपके।