नेटवर्क प्रॉक्सी

OpenClaw रनटाइम HTTP और WebSocket ट्रैफ़िक को ऑपरेटर-प्रबंधित फ़ॉरवर्ड प्रॉक्सी के माध्यम से रूट कर सकता है। यह वैकल्पिक बहुस्तरीय सुरक्षा है: केंद्रीय निकास नियंत्रण, अधिक मजबूत SSRF सुरक्षा और नेटवर्क सीमा पर गंतव्य की ऑडिट-क्षमता। चूँकि प्रॉक्सी कनेक्ट करते समय, DNS रिज़ॉल्यूशन के बाद और अपस्ट्रीम कनेक्शन खोलने से ठीक पहले गंतव्य का मूल्यांकन करता है, इसलिए यह उस अंतराल को भी कम करता है जिस पर DNS-रीबाइंडिंग हमला पहले किए गए एप्लिकेशन-स्तरीय DNS जाँच और वास्तविक आउटबाउंड कनेक्शन के बीच निर्भर करता है। एकल प्रॉक्सी नीति ऑपरेटरों को OpenClaw का पुनर्निर्माण किए बिना गंतव्य नियम, नेटवर्क विभाजन, दर सीमाएँ या आउटबाउंड अनुमति-सूचियाँ लागू करने के लिए एक ही स्थान भी प्रदान करती है।

OpenClaw किसी प्रॉक्सी को शामिल, डाउनलोड, प्रारंभ, कॉन्फ़िगर या प्रमाणित नहीं करता। आप अपने परिवेश के अनुकूल प्रॉक्सी तकनीक चलाते हैं; OpenClaw अपने HTTP और WebSocket क्लाइंट को उसके माध्यम से रूट करता है।

कॉन्फ़िगरेशन

proxy:  proxyUrl: http://127.0.0.1:3128

आप परिवेश के माध्यम से भी URL सेट कर सकते हैं:

OPENCLAW_PROXY_URL=http://127.0.0.1:3128 openclaw gateway run

proxy.proxyUrl को OPENCLAW_PROXY_URL पर प्राथमिकता मिलती है। कॉन्फ़िगर किया गया URL प्रबंधित प्रॉक्सी रूटिंग सक्रिय करता है; दोनों URL हटाने पर यह निष्क्रिय हो जाती है।

प्रबंधित Gateway सेवाओं के लिए URL को कॉन्फ़िगरेशन में संग्रहित करें, ताकि वह फ़ोरग्राउंड परिवेश पर निर्भर रहने के बजाय पुनः इंस्टॉल करने के बाद भी बना रहे:

openclaw config set proxy.proxyUrl http://127.0.0.1:3128openclaw gateway install --forceopenclaw gateway start

OPENCLAW_PROXY_URL परिवेश फ़ॉलबैक फ़ोरग्राउंड रन के लिए सबसे उपयुक्त है। इसे इंस्टॉल की गई सेवा के साथ उपयोग करने के लिए, इसे सेवा के स्थायी परिवेश ($OPENCLAW_STATE_DIR/.env, डिफ़ॉल्ट ~/.openclaw/.env) में रखें, फिर पुनः इंस्टॉल करें ताकि launchd/systemd/Scheduled Tasks इसे अपना सके।

निजी CA वाला HTTPS प्रॉक्सी एंडपॉइंट

proxy:  proxyUrl: https://proxy.corp.example:8443  tls:    caFile: /etc/openclaw/proxy-ca.pem

proxy.tls.caFile प्रॉक्सी एंडपॉइंट के अपने TLS प्रमाणपत्र को सत्यापित करता है। यह गंतव्य MITM विश्वास सेटिंग, क्लाइंट प्रमाणपत्र या प्रॉक्सी की गंतव्य नीति का विकल्प नहीं है। इसके बजाय NODE_EXTRA_CA_CERTS का उपयोग केवल तब करें, जब संपूर्ण Node प्रक्रिया को प्रारंभ होने के समय से किसी अतिरिक्त CA पर विश्वास करना आवश्यक हो (उदाहरण के लिए, प्रत्येक HTTPS गंतव्य प्रमाणपत्र पर दोबारा हस्ताक्षर करने वाली एंटरप्राइज़ TLS-निरीक्षण प्रणाली) — वह वेरिएबल पूरी प्रक्रिया पर लागू होता है और उसे Node के प्रारंभ होने से पहले सेट करना आवश्यक है, इसलिए OpenClaw उसे रन के बीच में उस तरह लागू नहीं कर सकता जैसे वह proxy.tls.caFile को लागू करता है। HTTPS प्रॉक्सी एंडपॉइंट पर विश्वास के लिए proxy.tls.caFile को प्राथमिकता दें: इसका दायरा पूरी प्रक्रिया के बजाय प्रबंधित प्रॉक्सी रूटिंग तक सीमित रहता है।

openclaw config set proxy.proxyUrl https://proxy.corp.example:8443openclaw config set proxy.tls.caFile /etc/openclaw/proxy-ca.pemopenclaw gateway run

रूटिंग कैसे काम करती है

मान्य प्रॉक्सी URL के साथ, संरक्षित रनटाइम प्रक्रियाएँ (openclaw gateway run, openclaw node run, openclaw agent --local) सामान्य HTTP और WebSocket निकास ट्रैफ़िक को प्रॉक्सी के माध्यम से रूट करती हैं:

OpenClaw प्रक्रिया  fetch, node:http, node:https, WebSocket क्लाइंट  -> ऑपरेटर प्रॉक्सी -> गंतव्य

आंतरिक रूप से, OpenClaw प्रक्रिया-स्तरीय रूटिंग रनटाइम के रूप में Proxyline इंस्टॉल करता है। यह fetch, undici-समर्थित क्लाइंट, node:http/node:https, सामान्य WebSocket क्लाइंट और सहायक द्वारा बनाए गए CONNECT टनल को कवर करता है, और यह कॉलर द्वारा प्रदान किए गए Node HTTP एजेंट को प्रतिस्थापित करता है ताकि स्पष्ट एजेंट (जिनमें axios, got, node-fetch और इसी तरह के Node-एजेंट-आधारित क्लाइंट शामिल हैं) प्रॉक्सी को चुपचाप बायपास न कर सकें।

प्रॉक्सी URL स्कीम OpenClaw से प्रॉक्सी तक के हॉप का वर्णन करती है, अंतिम गंतव्य तक के हॉप का नहीं:

• http://proxy.example:3128 — प्रॉक्सी तक प्लेन TCP; OpenClaw HTTP प्रॉक्सी अनुरोध भेजता है, जिनमें HTTPS गंतव्यों के लिए CONNECT शामिल है।
• https://proxy.example:8443 — OpenClaw स्वयं प्रॉक्सी तक TLS खोलता है (प्रॉक्सी के प्रमाणपत्र को सत्यापित करते हुए), फिर उस सत्र के भीतर HTTP प्रॉक्सी अनुरोध भेजता है।

गंतव्य TLS, प्रॉक्सी-एंडपॉइंट TLS से स्वतंत्र है: HTTPS गंतव्य के लिए OpenClaw हमेशा प्रॉक्सी से CONNECT टनल माँगता है और उस टनल के माध्यम से गंतव्य TLS प्रारंभ करता है।

प्रॉक्सी सक्रिय रहने के दौरान OpenClaw no_proxy/NO_PROXY को साफ़ कर देता है। वे बायपास सूचियाँ गंतव्य-आधारित होती हैं; उनमें localhost या 127.0.0.1 छोड़ने से SSRF लक्ष्य प्रॉक्सी को पूरी तरह छोड़ सकते हैं। बंद होने पर OpenClaw पिछले प्रॉक्सी परिवेश को पुनर्स्थापित करता है और कैश की गई रूटिंग स्थिति रीसेट करता है।

कुछ plugins के पास एक कस्टम ट्रांसपोर्ट होता है, जिसके लिए प्रक्रिया-स्तरीय रूटिंग सक्रिय होने पर भी अलग प्रॉक्सी वायरिंग आवश्यक होती है। Telegram का Bot API क्लाइंट अपने स्वयं के HTTP/1 undici डिस्पैचर का उपयोग करता है और प्रक्रिया प्रॉक्सी परिवेश के साथ OPENCLAW_PROXY_URL फ़ॉलबैक का भी अलग से पालन करता है।

Gateway लूपबैक मोड

स्थानीय Gateway नियंत्रण-प्लेन क्लाइंट सामान्यतः ws://127.0.0.1:18789 जैसे लूपबैक WebSocket से कनेक्ट होते हैं। proxy.loopbackMode नियंत्रित करता है कि यह ट्रैफ़िक प्रबंधित प्रॉक्सी को बायपास करता है या नहीं:

proxy:  proxyUrl: http://127.0.0.1:3128  loopbackMode: gateway-only # gateway-only, proxy, या block

कॉन्फ़िगर किया गया proxyUrl या OPENCLAW_PROXY_URL प्रबंधित रूटिंग सक्षम करता है। केवल एक उन्नत ऑप्ट-आउट के रूप में proxy.enabled: false सेट करें, जो URL को सक्रिय किए बिना संग्रहित रखता है।

Gateway नियंत्रण-प्लेन बायपास localhost और शाब्दिक लूपबैक IP URL तक सीमित है — ws://127.0.0.1:18789, ws://[::1]:18789 या ws://localhost:18789 का उपयोग करें। अन्य होस्टनेम सामान्य ट्रैफ़िक की तरह रूट होते हैं।

कंटेनर

openclaw --container ... कमांड के लिए, सेट होने पर OpenClaw OPENCLAW_PROXY_URL को कंटेनर-लक्षित चाइल्ड CLI में फ़ॉरवर्ड करता है। URL कंटेनर के भीतर से पहुँच योग्य होना आवश्यक है — वहाँ 127.0.0.1 होस्ट को नहीं, स्वयं कंटेनर को संदर्भित करता है। कंटेनर-लक्षित कमांड के लिए OpenClaw लूपबैक प्रॉक्सी URL अस्वीकार करता है, जब तक कि आप उस जाँच को स्पष्ट रूप से ओवरराइड करने के लिए OPENCLAW_CONTAINER_ALLOW_LOOPBACK_PROXY_URL=1 सेट न करें।

संबंधित प्रॉक्सी शब्द

• proxy.enabled / proxy.proxyUrl — रनटाइम निकास के लिए आउटबाउंड फ़ॉरवर्ड-प्रॉक्सी रूटिंग। यह पृष्ठ।
• gateway.auth.mode: "trusted-proxy" — Gateway पहुँच के लिए इनबाउंड पहचान-सचेत रिवर्स-प्रॉक्सी प्रमाणीकरण। विश्वसनीय प्रॉक्सी प्रमाणीकरण देखें।
• openclaw proxy — विकास और सहायता के लिए स्थानीय डीबग प्रॉक्सी और कैप्चर निरीक्षक। openclaw proxy देखें।
• tools.web.fetch.useTrustedEnvProxy — web_fetch के लिए ऑप्ट-इन, जिससे ऑपरेटर-नियंत्रित HTTP(S) परिवेश प्रॉक्सी को DNS रिज़ॉल्व करने दिया जाता है, जबकि डिफ़ॉल्ट रूप से कड़ा DNS पिनिंग और होस्टनेम नीति बनाए रखी जाती है। वेब फ़ेच देखें।
• चैनल- या प्रदाता-विशिष्ट प्रॉक्सी सेटिंग — एक ट्रांसपोर्ट के लिए स्वामी-विशिष्ट ओवरराइड। पूरे रनटाइम में केंद्रीय निकास नियंत्रण के लिए प्रबंधित नेटवर्क प्रॉक्सी को प्राथमिकता दें।

प्रॉक्सी का सत्यापन

प्रॉक्सी की गंतव्य नीति वास्तविक सुरक्षा सीमा है; OpenClaw यह सत्यापित नहीं कर सकता कि आपका प्रॉक्सी सही लक्ष्यों को अवरुद्ध करता है। इसे इस प्रकार कॉन्फ़िगर करें:

• केवल लूपबैक या निजी विश्वसनीय इंटरफ़ेस से बाइंड करें, जिस तक केवल OpenClaw प्रक्रिया/होस्ट/कंटेनर/सेवा खाता पहुँच सके।
• गंतव्यों को स्वयं रिज़ॉल्व करें और DNS रिज़ॉल्यूशन के बाद, कनेक्ट करते समय, प्लेन HTTP तथा HTTPS CONNECT टनल दोनों के लिए IP के आधार पर अवरुद्ध करें।
• लूपबैक, निजी, लिंक-स्थानीय, मेटाडेटा, मल्टीकास्ट, आरक्षित और दस्तावेज़ीकरण श्रेणियों के लिए गंतव्य-आधारित बायपास अस्वीकार करें।
• होस्टनेम अनुमति-सूचियों से बचें, जब तक कि आपको DNS रिज़ॉल्यूशन पथ पर पूर्ण विश्वास न हो।
• गंतव्य, निर्णय, स्थिति और कारण लॉग करें — अनुरोध बॉडी, प्राधिकरण हेडर, कुकी या अन्य सीक्रेट कभी नहीं।
• नीति को संस्करण नियंत्रण के अंतर्गत रखें और परिवर्तनों की सुरक्षा-संवेदनशील मानकर समीक्षा करें।

उसी होस्ट/कंटेनर/सेवा खाते से सत्यापित करें जो OpenClaw चलाता है:

openclaw proxy validate --proxy-url http://127.0.0.1:3128

निजी-CA वाले HTTPS प्रॉक्सी एंडपॉइंट के साथ:

openclaw proxy validate --proxy-url https://proxy.corp.example:8443 --proxy-ca-file /etc/openclaw/proxy-ca.pem

यदि कोई कॉन्फ़िगरेशन, पर्यावरण या --proxy-url मान उपलब्ध नहीं है, तो कमांड कॉन्फ़िगरेशन की समस्या की रिपोर्ट करता है; कॉन्फ़िगरेशन बदलने से पहले एकबारगी प्रीफ़्लाइट के लिए --proxy-url पास करें।

--allowed-url/--denied-url न होने पर, डिफ़ॉल्ट जाँचें हैं: https://example.com/ का सफल होना आवश्यक है और एक अस्थायी लूपबैक कैनरी सर्वर, जिस तक प्रॉक्सी को नहीं पहुँचना चाहिए, अवरुद्ध होना आवश्यक है। लूपबैक जाँच ट्रांसपोर्ट विफलता पर, या ऐसे गैर-2xx प्रतिसाद पर सफल होती है जिसमें कैनरी का प्रति-रन टोकन न हो; यह टोकन के बिना 2xx प्रतिसाद पर विफल होती है (कैनरी के अलावा किसी अन्य स्रोत से अप्रत्याशित सफलता) और विशेष रूप से, मेल खाने वाला टोकन रखने वाले किसी भी प्रतिसाद पर विफल होती है, क्योंकि इससे सिद्ध होता है कि प्रॉक्सी ने वास्तव में ऐसे लूपबैक गंतव्य को अग्रेषित किया जिसे उसे अस्वीकार करना चाहिए था। कस्टम --denied-url लक्ष्यों में ऐसा कैनरी टोकन नहीं होता, इसलिए वे विफलता-सुरक्षित हैं: कोई भी HTTP प्रतिसाद पहुँच योग्य माना जाता है (विफलता), और ट्रांसपोर्ट त्रुटि को प्रमाणित-अवरुद्ध के बजाय अनिर्णायक बताया जाता है, क्योंकि OpenClaw यह पुष्टि नहीं कर सकता कि आपके प्रॉक्सी ने पहुँच योग्य मूल को अस्वीकार किया या कोई अन्य समस्या हुई। --apns-reachable जानबूझकर अमान्य प्रदाता टोकन भेजता है, इसलिए 403 InvalidProviderToken प्रतिसाद को इस बात का प्रमाण माना जाता है कि टनल Apple तक पहुँची। किसी भी सत्यापन विफलता पर कमांड 1 के साथ बाहर निकलता है; प्रॉक्सी URL क्रेडेंशियल टेक्स्ट और JSON, दोनों आउटपुट से संपादित कर दिए जाते हैं।

{  "ok": true,  "config": {    "enabled": true,    "proxyUrl": "http://127.0.0.1:3128/",    "source": "override",    "errors": []  },  "checks": [    { "kind": "allowed", "url": "https://example.com/", "ok": true, "status": 200 },    { "kind": "apns", "url": "https://api.sandbox.push.apple.com", "ok": true, "status": 403 }  ]}

मैन्युअल curl जाँच (सार्वजनिक अनुरोध सफल होना चाहिए; लूपबैक और मेटाडेटा अनुरोध स्वयं प्रॉक्सी द्वारा अवरुद्ध होने चाहिए — केवल curl प्रॉक्सी द्वारा अस्वीकार किए जाने और किसी अनुपलब्ध मूल के बीच उस तरह अंतर नहीं कर सकता, जैसा openclaw proxy validate की अंतर्निहित कैनरी कर सकती है):

curl -x http://127.0.0.1:3128 https://example.com/curl -x http://127.0.0.1:3128 http://127.0.0.1/curl -x http://127.0.0.1:3128 http://169.254.169.254/

अनुशंसित अवरुद्ध गंतव्य

किसी भी फ़ॉरवर्ड प्रॉक्सी, फ़ायरवॉल या इग्रेस नीति के लिए आरंभिक अस्वीकरण-सूची। OpenClaw का अपना SSRF वर्गीकारक src/infra/net/ssrf.ts और packages/net-policy/src/ip.ts में स्थित है (BLOCKED_HOSTNAMES, BLOCKED_IPV4_SPECIAL_USE_RANGES, BLOCKED_IPV6_SPECIAL_USE_RANGES, RFC 2544 बेंचमार्क उपसर्ग और NAT64/6to4/Teredo/ISATAP/IPv4-मैप किए गए रूपों के लिए एम्बेडेड-IPv4 प्रबंधन) — ये उपयोगी संदर्भ हैं, लेकिन OpenClaw आपके बाहरी प्रॉक्सी में इन नियमों को निर्यात या लागू नहीं करता।

अपने क्लाउड प्रदाता या नेटवर्क प्लेटफ़ॉर्म द्वारा दस्तावेज़ीकृत कोई भी अतिरिक्त मेटाडेटा होस्ट या आरक्षित रेंज जोड़ें।

सीमाएँ

• यह JavaScript HTTP/WebSocket क्लाइंट के लिए प्रक्रिया-स्तरीय कवरेज है, OS-स्तरीय नेटवर्क सैंडबॉक्स नहीं।
• रॉ net, tls, http2 सॉकेट, नेटिव ऐड-ऑन और गैर-OpenClaw चाइल्ड प्रक्रियाएँ Node-स्तरीय रूटिंग को बायपास कर सकती हैं, जब तक कि वे प्रॉक्सी पर्यावरण चर इनहेरिट करके उनका सम्मान न करें। फ़ोर्क किए गए OpenClaw चाइल्ड CLI प्रबंधित प्रॉक्सी URL और proxy.loopbackMode स्थिति इनहेरिट करते हैं।
• उपयोगकर्ता के स्थानीय WebUI और स्थानीय मॉडल सर्वर सामान्य स्थानीय-नेटवर्क बायपास के अंतर्गत नहीं आते — आवश्यकता होने पर उन्हें ऑपरेटर प्रॉक्सी नीति की अनुमति-सूची में जोड़ें। अपवाद बंडल किए गए Ollama मेमोरी एम्बेडिंग प्रदाता का संरक्षित प्रत्यक्ष पथ है, जो उसके कॉन्फ़िगर किए गए baseUrl से सटीक होस्ट-लोकल लूपबैक मूल तक सीमित है; LAN, टेलनेट, निजी-नेटवर्क और सार्वजनिक Ollama होस्ट अब भी प्रबंधित प्रॉक्सी का उपयोग करते हैं।
• स्थानीय डीबग प्रॉक्सी का प्रत्यक्ष अपस्ट्रीम अग्रेषण (प्रॉक्सी अनुरोधों और CONNECT टनल के लिए) प्रबंधित प्रॉक्सी मोड सक्रिय रहने के दौरान डिफ़ॉल्ट रूप से अक्षम रहता है; इसे केवल अनुमोदित स्थानीय निदान के लिए सक्षम करें।
• OpenClaw आपकी प्रॉक्सी नीति का निरीक्षण, परीक्षण या प्रमाणन नहीं करता। प्रॉक्सी नीति में परिवर्तनों को सुरक्षा-संवेदनशील परिचालन परिवर्तनों के रूप में मानें।