प्रॉक्सी के साथ काम करते समय डेवलपर्स अक्सर इस समस्या का सामना करते हैं कि क्लासिक HTTP प्रॉक्सी सेटिंग्स WebSocket कनेक्शनों के लिए काम नहीं करती हैं, और gRPC तो TLS हैंडशेक की त्रुटियों के साथ टूट जाता है। समस्या यह है कि WebSocket, HTTP/2 और gRPC केवल "HTTP के विकल्प" नहीं हैं, बल्कि विभिन्न परिवहन मॉडल हैं जिनकी टनलिंग, मल्टीप्लेक्सिंग और हेडर प्रोसेसिंग के लिए अपनी आवश्यकताएँ हैं। इस लेख में हम देखेंगे कि इन प्रोटोकॉल में से प्रत्येक को कैसे प्रॉक्सी किया जाए, प्रैक्टिस में कौन सी समस्याएँ आती हैं और किसी विशेष कार्य के लिए प्रोटोकॉल और प्रॉक्सी प्रकार का चयन कैसे करें - WebSocket के माध्यम से पार्सिंग से लेकर उच्च लोड वाले gRPC माइक्रोसर्विसेज तक।
प्रोटोकॉल में क्या अंतर है और यह प्रॉक्सी के लिए क्यों महत्वपूर्ण है
HTTP/1.1 "अनुरोध - उत्तर" मॉडल पर काम करता है: क्लाइंट कनेक्शन खोलता है, अनुरोध भेजता है, उत्तर प्राप्त करता है और या तो कनेक्शन बंद करता है या अगले अनुरोध के लिए इसे खुला रखता है (कीप-एलाइव)। प्रॉक्सी सर्वर दशकों से इस मॉडल के लिए अनुकूलित किए गए हैं - हेडर का पार्सिंग, अनुरोध के शरीर का बफरिंग, Host हेडर के माध्यम से सरल रूटिंग।
WebSocket इस मॉडल को तोड़ता है: प्रारंभिक HTTP हैंडशेक (Upgrade: websocket) के बाद कनेक्शन एक स्थायी द्विदिश चैनल में बदल जाता है, जहाँ डेटा किसी भी समय दोनों दिशाओं में जा सकता है। प्रॉक्सी को इस कनेक्शन को "छोड़ना" चाहिए और बस दोनों दिशाओं में बाइट्स को भेजना चाहिए, बिना उन्हें HTTP अनुरोधों के रूप में व्याख्या करने की कोशिश किए।
HTTP/2 मल्टीप्लेक्सिंग जोड़ता है - एक ही TCP कनेक्शन के माध्यम से कई तार्किक अनुरोध समानांतर में जाते हैं, टेक्स्ट हेडर के बजाय बाइनरी फ्रेम का उपयोग करते हैं। प्रॉक्सी के लिए इसका मतलब है कि इसे बस टेक्स्ट को पंक्ति दर पंक्ति पढ़ने की अनुमति नहीं है - प्रॉक्सी स्तर पर HTTP/2 बाइनरी प्रोटोकॉल का समर्थन या TLS के ऊपर पारदर्शी TCP टनलिंग की आवश्यकता है।
gRPC और भी आगे बढ़ता है: यह HTTP/2 पर सख्ती से आधारित है, Protocol Buffers का उपयोग करता है और क्लाइंट से सर्वर तक के पूरे रास्ते पर HTTP/2-संगत परिवहन की आवश्यकता होती है। यदि प्रॉक्सी किसी बिंदु पर कनेक्शन को HTTP/1.1 में "डाउनग्रेड" करता है, तो gRPC अनुरोध बस नहीं пройдет।
इन भिन्नताओं को समझना महत्वपूर्ण है, क्योंकि गलत प्रकार के प्रॉक्सी का चयन या टनलिंग की गलत सेटिंग कनेक्शन के टूटने, टाइमआउट और कठिनाई से समझ में आने वाली त्रुटियों का कारण बनती है, जिन्हें परिवहन स्तर की समझ के बिना निदान करना मुश्किल है।
WebSocket के माध्यम से प्रॉक्सी: सेटअप और कोड
WebSocket के लिए प्रॉक्सी के माध्यम से दो मुख्य परिदृश्य हैं: HTTP प्रॉक्सी के साथ CONNECT विधि (WSS के लिए, यानी TLS के माध्यम से WebSocket) और SOCKS5 प्रॉक्सी, जो प्रोटोकॉल की परवाह किए बिना TCP कनेक्शन को टनल करता है। SOCKS5 आमतौर पर कम समस्याएँ देता है, क्योंकि इसे किसी भी TCP ट्रैफ़िक के लिए "पारदर्शी पाइप" के रूप में डिज़ाइन किया गया था।
Python में websockets
और python-socks
पुस्तकालय के साथ SOCKS5 प्रॉक्सी के माध्यम से WebSocket से कनेक्ट करने का उदाहरण:
import asyncio
from python_socks.sync import Proxy
import websockets
import websockets.sync.client as ws_client
def connect_ws_via_proxy():
proxy = Proxy.from_url("socks5://user:pass@proxy_host:1080")
sock = proxy.connect(dest_host="echo.websocket.events", dest_port=443)
ws = ws_client.connect(
"wss://echo.websocket.events",
sock=sock,
server_hostname="echo.websocket.events"
)
ws.send("Hello via proxy")
print(ws.recv())
ws.close()
connect_ws_via_proxy()
Node.js में समान कार्य को ws
पैकेज के माध्यम से socks-proxy-agent के साथ हल किया जाता है:
const WebSocket = require('ws');
const { SocksProxyAgent } = require('socks-proxy-agent');
const agent = new SocksProxyAgent('socks5://user:pass@proxy_host:1080');
const socket = new WebSocket('wss://echo.websocket.events', { agent });
socket.on('open', () => socket.send('Hello via proxy'));
socket.on('message', (data) => console.log(data.toString()));यदि प्रॉक्सी केवल HTTP (CONNECT विधि के साथ) के माध्यम से उपलब्ध है, तो योजना समान है - अधिकांश आधुनिक WebSocket क्लाइंट HTTP टनल के माध्यम से काम करने में सक्षम होते हैं, केवल यह सुनिश्चित करना महत्वपूर्ण है कि प्रॉक्सी लंबे समय तक चलने वाले कनेक्शन को टाइमआउट के कारण बंद नहीं करती है। यह सस्ते डेटा सेंटर प्रॉक्सी के साथ एक सामान्य समस्या है, जिनमें निष्क्रिय कनेक्शन पर 30-60 सेकंड का सख्त सीमा निर्धारित होती है - स्ट्रीमिंग WebSocket कार्यों के लिए यह महत्वपूर्ण है, और प्रदाता से कीप-एलाइव पैरामीटर की पुष्टि करना बेहतर है।
HTTP/2 के माध्यम से प्रॉक्सी: मल्टीप्लेक्सिंग और समस्याएँ
HTTP/2 के माध्यम से प्रॉक्सी के साथ मुख्य कठिनाई यह है कि कई प्रॉक्सी सर्वर (विशेष रूप से पुराने Squid या सरल फॉरवर्ड प्रॉक्सी) केवल HTTP/1.1 पर काम करते हैं और स्वचालित रूप से कनेक्शन को "डाउनग्रेड" करते हैं। क्लाइंट के लिए यह अक्सर अदृश्य होता है (अनुरोध फिर भी पूरा होता है), लेकिन मल्टीप्लेक्सिंग के लाभ खो जाते हैं - देरी बढ़ जाती है, विशेष रूप से एक ही होस्ट के लिए कई समानांतर अनुरोधों के साथ।
यह जांचने के लिए कि क्या प्रॉक्सी के माध्यम से कनेक्शन HTTP/2 का समर्थन करता है, आप cURL का उपयोग कर सकते हैं
--http2
ध्वज और विस्तृत आउटपुट के साथ:
curl -v --http2 -x http://user:pass@proxy_host:8080 https://example.com
# आउटपुट में इस पंक्ति की तलाश करें:
# * Using HTTP2, server supports multiplexing
# यदि यह नहीं है - कनेक्शन HTTP/1.1 पर गिर गया
Python में HTTP/2 के लिए प्रॉक्सी के माध्यम से httpx
पुस्तकालय की आवश्यकता होती है जिसमें HTTP/2 का समर्थन शामिल है:
import httpx
proxies = {
"http://": "http://user:pass@proxy_host:8080",
"https://": "http://user:pass@proxy_host:8080",
}
with httpx.Client(proxies=proxies, http2=True) as client:
response = client.get("https://example.com")
print(response.http_version) # अपेक्षित "HTTP/2"
print(response.status_code)एक महत्वपूर्ण बिंदु: HTTP/2 को प्रोटोकॉल के समन्वय के लिए ALPN विस्तार के साथ TLS की आवश्यकता होती है, इसलिए प्रॉक्सी को CONNECT के माध्यम से TLS ट्रैफ़िक को पारदर्शी रूप से टनल करना चाहिए, न कि TLS को स्वयं समाप्त करना चाहिए (यदि यह एक विशेष HTTP/2-संगत प्रॉक्सी नहीं है)। यही कारण है कि HTTP/2 कार्यों के लिए निवासी प्रॉक्सी और डेटा सेंटर प्रॉक्सी अलग-अलग व्यवहार करते हैं - यह महत्वपूर्ण है कि प्रदाता से यह स्पष्ट करें कि क्या ALPN बातचीत के बिना पारदर्शी TLS टनलिंग का समर्थन किया जाता है।
gRPC के माध्यम से प्रॉक्सी: TLS, ALPN और विशेष आवश्यकताएँ
gRPC इस सेट में सबसे अधिक मांग वाला प्रोटोकॉल है। यह HTTP/2 पर सख्ती से निर्भर करता है और अक्सर
प्रमाणीकरण के लिए द्विदिश TLS (mTLS) का उपयोग करता है। सामान्य फॉरवर्ड प्रॉक्सी, जो HTTP/2 CONNECT
टनलिंग का समर्थन नहीं करता है, gRPC ट्रैफ़िक को "जैसा है" पास नहीं करेगा - कनेक्शन त्रुटियों के साथ गिर जाएगा
जैसे UNAVAILABLE: upstream connect error.
Python में gRPC के प्रॉक्सीकरण के लिए (पुस्तकालय grpc)
प्रॉक्सी को पर्यावरण चर के माध्यम से सेट किया जाता है, क्योंकि चैनल विकल्पों में प्रॉक्सी के लिए अंतर्निहित समर्थन
ऐतिहासिक रूप से नहीं रहा है:
import os
import grpc
os.environ["grpc_proxy"] = "http://user:pass@proxy_host:8080"
os.environ["https_proxy"] = "http://user:pass@proxy_host:8080"
channel = grpc.secure_channel(
"grpc.example.com:443",
grpc.ssl_channel_credentials()
)
# उत्पन्न स्टब के माध्यम से कॉल का उदाहरण
# stub = YourServiceStub(channel)
# response = stub.YourMethod(request)
Node.js में gRPC के लिए प्रॉक्सी को grpc-js
के चैनल विकल्पों के माध्यम से सेट किया जाता है
HTTP/2-संगत प्रॉक्सी एजेंट के साथ:
const grpc = require('@grpc/grpc-js');
const { HttpsProxyAgent } = require('https-proxy-agent');
process.env.grpc_proxy = 'http://user:pass@proxy_host:8080';
process.env.https_proxy = 'http://user:pass@proxy_host:8080';
const client = new YourServiceClient(
'grpc.example.com:443',
grpc.credentials.createSsl()
);gRPC के लिए प्रॉक्सी के माध्यम से स्थिरता से काम करने के लिए कम देरी और स्थिर TCP कनेक्शन बिना बार-बार टूटने की आवश्यकता होती है - मल्टीप्लेक्स किए गए gRPC स्ट्रीम नेटवर्क विफलताओं के प्रति अधिक संवेदनशील होते हैं बनाम सामान्य HTTP/1.1 अनुरोध। ऐसे परिदृश्यों में निवासी प्रॉक्सी अक्सर सस्ते डेटा सेंटर पूलों की तुलना में बेहतर स्थिरता दिखाते हैं, क्योंकि लक्षित सर्वर तक मार्ग अधिक पूर्वानुमानित नेटवर्क अवसंरचना के माध्यम से होता है।
प्रोटोकॉल की तुलना तालिका
| प्रोटोकॉल | कनेक्शन का प्रकार | प्रॉक्सी की आवश्यकताएँ | अनुशंसित प्रॉक्सी का प्रकार |
|---|---|---|---|
| HTTP/1.1 | अनुरोध-उत्तर, कीप-एलाइव | न्यूनतम, कोई भी HTTP प्रॉक्सी | डेटा सेंटर प्रॉक्सी |
| WebSocket | स्थायी द्विदिश चैनल | लंबे कनेक्शनों का समर्थन, बिना टाइमआउट | निवासी प्रॉक्सी |
| HTTP/2 | मल्टीप्लेक्स किए गए बाइनरी स्ट्रीम | पारदर्शी TLS टनलिंग, ALPN | निवासी या डेटा सेंटर प्रॉक्सी |
| gRPC | HTTP/2 + Protobuf, अक्सर mTLS | कम देरी, स्थिरता, HTTP/2 CONNECT | मोबाइल प्रॉक्सी कठोर फ़िल्टरों को बायपास करने के लिए |
अपने स्टैक के लिए प्रोटोकॉल और प्रॉक्सी कैसे चुनें
प्रोटोकॉल का चयन कभी-कभी स्वतंत्र निर्णय नहीं होता - यह लक्षित API द्वारा निर्धारित होता है। लेकिन इस प्रोटोकॉल के लिए प्रॉक्सी के प्रकार का चयन आपकी जिम्मेदारी है, और यहाँ आपको विशेष परिदृश्य पर निर्भर रहना चाहिए:
WebSocket के माध्यम से डेटा पार्सिंग (उदाहरण के लिए, मार्केटप्लेस साइटों से कीमतों या रियल-टाइम डेटा का स्ट्रीमिंग) एक स्थिर लंबे कनेक्शन की आवश्यकता होती है जो टाइमआउट के कारण टूटता नहीं है। यहाँ निवासी प्रॉक्सी बेहतर काम करते हैं - वे लक्षित सेवा के एंटी-फ्रॉड एल्गोरिदम के तहत कम आते हैं और कनेक्शन को सामान्य डेटा सेंटर पूलों की तुलना में अधिक समय तक बनाए रखते हैं।
gRPC माइक्रोसर्विसेज के साथ बाहरी प्रॉक्सी के माध्यम से एकीकरण (उदाहरण के लिए, विभिन्न भू-स्थान से API का परीक्षण करते समय) कम देरी और पूरे रास्ते पर HTTP/2 का समर्थन आवश्यक है। इसके लिए अच्छे रूटिंग के साथ निवासी IP उपयुक्त हैं, और समय-संवेदनशील कार्यों के लिए - यदि लक्षित सेवा डेटा सेंटर रेंज को आक्रामक रूप से फ़िल्टर करती है तो मोबाइल प्रॉक्सी।
REST/GraphQL API के लिए बड़े HTTP/2 अनुरोध मल्टीप्लेक्सिंग के साथ - यह सबसे सामान्य परिदृश्य है, जहाँ तेज और सस्ते डेटा सेंटर प्रॉक्सी पर्याप्त होते हैं, यदि लक्षित सेवा डिफ़ॉल्ट रूप से डेटा सेंटर रेंज को ब्लॉक नहीं करती है।
सामान्य नियम: जितना "कप्रीज़" प्रोटोकॉल कनेक्शन की स्थिरता के प्रति (WebSocket, gRPC) होता है, उतना ही अधिक निवास या मोबाइल IP में अर्थ होता है। जितना सरल और छोटा अनुरोध (सामान्य HTTP/1.1 या HTTP/2 बिना लंबे सत्रों के) होता है, उतना ही आरामदायक डेटा सेंटर प्रॉक्सी के साथ काम करना होता है - वे तेज होते हैं और उच्च बैंडविड्थ प्रदान करते हैं।
सामान्य गलतियाँ और उनके समाधान
त्रुटि 1: WebSocket हर 30-60 सेकंड में टूटता है। कारण - प्रॉक्सी या मध्यवर्ती लोड बैलेंसर "निष्क्रिय" कनेक्शनों को बंद कर देता है। समाधान: प्रॉक्सी के टाइमआउट से कम अंतराल पर एप्लिकेशन स्तर पर पिंग/पोंग फ्रेम सक्षम करें (आमतौर पर 20-25 सेकंड पर्याप्त होता है)।
त्रुटि 2: gRPC प्रॉक्सी के माध्यम से UNAVAILABLE के साथ गिरता है, जबकि सीधे काम करता है। प्रॉक्सी HTTP/2 CONNECT टनलिंग का समर्थन नहीं करता है। समाधान: प्रदाता की दस्तावेज़ीकरण की जाँच करें कि क्या HTTP/2 का समर्थन है, या SOCKS5 प्रॉक्सी का उपयोग करें, जो प्रोटोकॉल की व्याख्या किए बिना TCP को टनल करता है।
त्रुटि 3: HTTP/2 अदृश्य रूप से HTTP/1.1 में डाउनग्रेड हो जाता है। यह अक्सर प्रॉक्सी पर ALPN समर्थन की कमी के कारण होता है। कोड में स्पष्ट रूप से प्रोटोकॉल संस्करण की जाँच करें (जैसे कि ऊपर के httpx उदाहरण में) - यदि आपने प्रतिक्रिया में http_version की जाँच नहीं की है तो "सब कुछ काम करता है" पर भरोसा न करें।
त्रुटि 4: प्रॉक्सी के माध्यम से gRPC के मल्टीप्लेक्सिंग में उच्च देरी। अक्सर प्रॉक्सी प्रदाता के पास कई मध्यवर्ती नोड्स के कारण होती है। समाधान: सरल RTT अनुरोध के माध्यम से पहले से विलंबता का परीक्षण करें और सीधे रूटिंग वाले प्रदाता का चयन करें, विशेष रूप से समय-संवेदनशील gRPC कॉल के लिए।
निष्कर्ष
WebSocket, HTTP/2 और gRPC प्रॉक्सी सेटअप के लिए विभिन्न दृष्टिकोणों की आवश्यकता होती है क्योंकि वे विभिन्न परिवहन मॉडलों पर काम करते हैं: WebSocket के लिए सरल "TCP कनेक्शन को छोड़ना" से लेकर gRPC के लिए HTTP/2 CONNECT और ALPN के सख्त समर्थन तक। कोड में प्रोटोकॉल संस्करण की स्पष्ट रूप से जाँच करें, लंबे कनेक्शनों की स्थिरता का पहले से परीक्षण करें और SOCKS5 का चयन करें जहाँ अधिकतम टनलिंग पारदर्शिता की आवश्यकता होती है।
यदि आपका स्टैक लंबे समय तक चलने वाले WebSocket कनेक्शनों या देरी के प्रति संवेदनशील gRPC कॉल को शामिल करता है, तो हम निवासी प्रॉक्सी का प्रयास करने की सिफारिश करते हैं - वे सामान्य डेटा सेंटर पूलों की तुलना में अधिक स्थिर और पूर्वानुमानित कनेक्शन प्रदान करते हैं। उच्च बैंडविड्थ के साथ साधारण HTTP/2 अनुरोधों के लिए डेटा सेंटर प्रॉक्सी उपयुक्त हैं, और लक्षित सेवा के आक्रामक एंटी-फ्रॉड फ़िल्टरिंग कार्यों के लिए - मोबाइल प्रॉक्सी।