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

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

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

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

proxy:  enabled: true  proxyUrl: http://127.0.0.1:3128

कॉन्फ़िगरेशन में proxy.enabled: true बनाए रखते हुए आप URL को एनवायरनमेंट के माध्यम से भी सेट कर सकते हैं:

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

proxy.proxyUrl को OPENCLAW_PROXY_URL पर प्राथमिकता मिलती है। यदि proxy.enabled, true है, लेकिन कोई मान्य URL रिज़ॉल्व नहीं होता, तो संरक्षित कमांड प्रत्यक्ष नेटवर्क पहुँच पर वापस जाने के बजाय स्टार्टअप में विफल हो जाते हैं।

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

openclaw config set proxy.enabled trueopenclaw 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:  enabled: true  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.enabled trueopenclaw config set proxy.proxyUrl https://proxy.corp.example:8443openclaw config set proxy.tls.caFile /etc/openclaw/proxy-ca.pemopenclaw gateway run

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

proxy.enabled: true और मान्य 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:  enabled: true  proxyUrl: http://127.0.0.1:3128  loopbackMode: gateway-only # gateway-only, proxy, or block

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 — डिफ़ॉल्ट रूप से कठोर DNS पिनिंग और होस्टनेम नीति बनाए रखते हुए, ऑपरेटर-नियंत्रित HTTP(S) एनवायरनमेंट प्रॉक्सी को DNS रिज़ॉल्व करने देने के लिए web_fetch हेतु ऑप्ट-इन। वेब फ़ेच देखें।
• चैनल- या प्रदाता-विशिष्ट प्रॉक्सी सेटिंग — एक ट्रांसपोर्ट के लिए स्वामी-विशिष्ट ओवरराइड। पूरे रनटाइम में केंद्रीकृत इग्रेस नियंत्रण के लिए प्रबंधित नेटवर्क प्रॉक्सी को प्राथमिकता दें।

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

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

• केवल लूपबैक या किसी निजी विश्वसनीय इंटरफ़ेस से बाइंड करें, जिस तक केवल OpenClaw प्रक्रिया/होस्ट/कंटेनर/सेवा खाता पहुँच सके।
• गंतव्यों को स्वयं रिज़ॉल्व करें और सादे HTTP तथा HTTPS CONNECT टनल—दोनों के लिए, कनेक्ट करते समय DNS रिज़ॉल्यूशन के बाद 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.enabled, true नहीं है और कोई --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 आपकी प्रॉक्सी नीति का निरीक्षण, परीक्षण या प्रमाणीकरण नहीं करता। प्रॉक्सी नीति परिवर्तनों को सुरक्षा-संवेदनशील परिचालन परिवर्तन मानें।