--- read_when: - आप SSRF और DNS रीबाइंडिंग हमलों के विरुद्ध बहुस्तरीय सुरक्षा चाहते हैं - OpenClaw रनटाइम ट्रैफ़िक के लिए बाहरी फ़ॉरवर्ड प्रॉक्सी कॉन्फ़िगर करना summary: ऑपरेटर-प्रबंधित फ़िल्टरिंग प्रॉक्सी के माध्यम से OpenClaw रनटाइम के HTTP और WebSocket ट्रैफ़िक को रूट करने का तरीका title: नेटवर्क प्रॉक्सी x-i18n: generated_at: "2026-07-27T20:01:51Z" model: gpt-5.6 postprocess_version: locale-links-v1 prompt_version: 32 provider: openai source_hash: e948189d691e2cfe32e911e24071fd77157397b510d606423ef738c2565071b5 source_path: security/network-proxy.md workflow: 16 --- OpenClaw रनटाइम HTTP और WebSocket ट्रैफ़िक को ऑपरेटर-प्रबंधित फ़ॉरवर्ड प्रॉक्सी के माध्यम से रूट कर सकता है। यह वैकल्पिक बहुस्तरीय सुरक्षा है: केंद्रीय निकास नियंत्रण, अधिक मजबूत SSRF सुरक्षा और नेटवर्क सीमा पर गंतव्य की ऑडिट-क्षमता। चूँकि प्रॉक्सी कनेक्ट करते समय, DNS रिज़ॉल्यूशन के बाद और अपस्ट्रीम कनेक्शन खोलने से ठीक पहले गंतव्य का मूल्यांकन करता है, इसलिए यह उस अंतराल को भी कम करता है जिस पर DNS-रीबाइंडिंग हमला पहले किए गए एप्लिकेशन-स्तरीय DNS जाँच और वास्तविक आउटबाउंड कनेक्शन के बीच निर्भर करता है। एकल प्रॉक्सी नीति ऑपरेटरों को OpenClaw का पुनर्निर्माण किए बिना गंतव्य नियम, नेटवर्क विभाजन, दर सीमाएँ या आउटबाउंड अनुमति-सूचियाँ लागू करने के लिए एक ही स्थान भी प्रदान करती है। OpenClaw किसी प्रॉक्सी को शामिल, डाउनलोड, प्रारंभ, कॉन्फ़िगर या प्रमाणित नहीं करता। आप अपने परिवेश के अनुकूल प्रॉक्सी तकनीक चलाते हैं; OpenClaw अपने HTTP और WebSocket क्लाइंट को उसके माध्यम से रूट करता है। ## कॉन्फ़िगरेशन ```yaml proxy: proxyUrl: http://127.0.0.1:3128 ``` आप परिवेश के माध्यम से भी URL सेट कर सकते हैं: ```bash OPENCLAW_PROXY_URL=http://127.0.0.1:3128 openclaw gateway run ``` `proxy.proxyUrl` को `OPENCLAW_PROXY_URL` पर प्राथमिकता मिलती है। कॉन्फ़िगर किया गया URL प्रबंधित प्रॉक्सी रूटिंग सक्रिय करता है; दोनों URL हटाने पर यह निष्क्रिय हो जाती है। | कुंजी | प्रकार | डिफ़ॉल्ट | टिप्पणियाँ | | -------------------- | ------------------------------------ | -------------- | ------------------------------------------------------------------------------------------------------------------------------------- | | `proxy.proxyUrl` | स्ट्रिंग | सेट नहीं | `http://` या `https://` फ़ॉरवर्ड प्रॉक्सी URL। URL में अंतर्निहित क्रेडेंशियल को संवेदनशील माना जाता है और स्नैपशॉट/लॉग में छिपा दिया जाता है। | | `proxy.tls.caFile` | स्ट्रिंग | सेट नहीं | निजी CA द्वारा हस्ताक्षरित `https://` प्रॉक्सी एंडपॉइंट को सत्यापित करने के लिए CA बंडल। | | `proxy.loopbackMode` | `gateway-only` \| `proxy` \| `block` | `gateway-only` | लूपबैक बायपास व्यवहार नियंत्रित करता है; नीचे देखें। | प्रबंधित Gateway सेवाओं के लिए URL को कॉन्फ़िगरेशन में संग्रहित करें, ताकि वह फ़ोरग्राउंड परिवेश पर निर्भर रहने के बजाय पुनः इंस्टॉल करने के बाद भी बना रहे: ```bash openclaw config set proxy.proxyUrl http://127.0.0.1:3128 openclaw gateway install --force openclaw gateway start ``` `OPENCLAW_PROXY_URL` परिवेश फ़ॉलबैक फ़ोरग्राउंड रन के लिए सबसे उपयुक्त है। इसे इंस्टॉल की गई सेवा के साथ उपयोग करने के लिए, इसे सेवा के स्थायी परिवेश (`$OPENCLAW_STATE_DIR/.env`, डिफ़ॉल्ट `~/.openclaw/.env`) में रखें, फिर पुनः इंस्टॉल करें ताकि launchd/systemd/Scheduled Tasks इसे अपना सके। ### निजी CA वाला HTTPS प्रॉक्सी एंडपॉइंट ```yaml 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` को प्राथमिकता दें: इसका दायरा पूरी प्रक्रिया के बजाय प्रबंधित प्रॉक्सी रूटिंग तक सीमित रहता है। ```bash openclaw config set proxy.proxyUrl https://proxy.corp.example:8443 openclaw config set proxy.tls.caFile /etc/openclaw/proxy-ca.pem openclaw gateway run ``` ## रूटिंग कैसे काम करती है मान्य प्रॉक्सी URL के साथ, संरक्षित रनटाइम प्रक्रियाएँ (`openclaw gateway run`, `openclaw node run`, `openclaw agent --local`) सामान्य HTTP और WebSocket निकास ट्रैफ़िक को प्रॉक्सी के माध्यम से रूट करती हैं: ```text OpenClaw प्रक्रिया fetch, node:http, node:https, WebSocket क्लाइंट -> ऑपरेटर प्रॉक्सी -> गंतव्य ``` आंतरिक रूप से, OpenClaw प्रक्रिया-स्तरीय रूटिंग रनटाइम के रूप में [Proxyline](https://github.com/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` नियंत्रित करता है कि यह ट्रैफ़िक प्रबंधित प्रॉक्सी को बायपास करता है या नहीं: ```yaml proxy: proxyUrl: http://127.0.0.1:3128 loopbackMode: gateway-only # gateway-only, proxy, या block ``` कॉन्फ़िगर किया गया `proxyUrl` या `OPENCLAW_PROXY_URL` प्रबंधित रूटिंग सक्षम करता है। केवल एक उन्नत ऑप्ट-आउट के रूप में `proxy.enabled: false` सेट करें, जो URL को सक्रिय किए बिना संग्रहित रखता है। | मोड | व्यवहार | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `gateway-only` (डिफ़ॉल्ट) | OpenClaw सक्रिय Gateway लूपबैक अथॉरिटी को डायरेक्ट-कनेक्ट अपवाद के रूप में पंजीकृत करता है, इसलिए स्थानीय Gateway WebSocket ट्रैफ़िक प्रॉक्सी के बिना कनेक्ट होता है। कस्टम लूपबैक पोर्ट काम करते हैं क्योंकि अपवाद सटीक कॉन्फ़िगर किए गए होस्ट/पोर्ट को लक्षित करता है। बंडल किया गया ब्राउज़र plugin, OpenClaw द्वारा लॉन्च किए गए प्रबंधित ब्राउज़र के सटीक स्थानीय CDP तत्परता और DevTools WebSocket URL के लिए उसी प्रकार का अपवाद पंजीकृत करता है; बंडल किए गए Ollama मेमोरी एम्बेडिंग प्रदाता के पास उसके सटीक कॉन्फ़िगर किए गए होस्ट-स्थानीय लूपबैक एम्बेडिंग ओरिजिन के लिए अधिक सीमित, सुरक्षित डायरेक्ट पथ है। | | `proxy` | कोई लूपबैक अपवाद पंजीकृत नहीं किया जाता; Gateway और Ollama लूपबैक ट्रैफ़िक प्रॉक्सी के माध्यम से जाता है। रिमोट प्रॉक्सी को OpenClaw होस्ट की लूपबैक सेवा तक वापस रूट करने में सक्षम होना आवश्यक है (उदाहरण के लिए, पहुँच योग्य होस्टनेम, IP या टनल के माध्यम से) — मानक रिमोट प्रॉक्सी `127.0.0.1`/`localhost` को OpenClaw होस्ट के विरुद्ध नहीं, बल्कि स्वयं के विरुद्ध रिज़ॉल्व करता है। | | `block` | OpenClaw सॉकेट खोलने से पहले Gateway लूपबैक नियंत्रण-प्लेन कनेक्शन और सुरक्षित Ollama लूपबैक एम्बेडिंग कनेक्शन अस्वीकार करता है। | 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 पहुँच के लिए इनबाउंड पहचान-सचेत रिवर्स-प्रॉक्सी प्रमाणीकरण। [विश्वसनीय प्रॉक्सी प्रमाणीकरण](/hi/gateway/trusted-proxy-auth) देखें। - `openclaw proxy` — विकास और सहायता के लिए स्थानीय डीबग प्रॉक्सी और कैप्चर निरीक्षक। [openclaw proxy](/hi/cli/proxy) देखें। - `tools.web.fetch.useTrustedEnvProxy` — `web_fetch` के लिए ऑप्ट-इन, जिससे ऑपरेटर-नियंत्रित HTTP(S) परिवेश प्रॉक्सी को DNS रिज़ॉल्व करने दिया जाता है, जबकि डिफ़ॉल्ट रूप से कड़ा DNS पिनिंग और होस्टनेम नीति बनाए रखी जाती है। [वेब फ़ेच](/hi/tools/web-fetch#trusted-env-proxy) देखें। - चैनल- या प्रदाता-विशिष्ट प्रॉक्सी सेटिंग — एक ट्रांसपोर्ट के लिए स्वामी-विशिष्ट ओवरराइड। पूरे रनटाइम में केंद्रीय निकास नियंत्रण के लिए प्रबंधित नेटवर्क प्रॉक्सी को प्राथमिकता दें। ## प्रॉक्सी का सत्यापन प्रॉक्सी की गंतव्य नीति वास्तविक सुरक्षा सीमा है; OpenClaw यह सत्यापित नहीं कर सकता कि आपका प्रॉक्सी सही लक्ष्यों को अवरुद्ध करता है। इसे इस प्रकार कॉन्फ़िगर करें: - केवल लूपबैक या निजी विश्वसनीय इंटरफ़ेस से बाइंड करें, जिस तक केवल OpenClaw प्रक्रिया/होस्ट/कंटेनर/सेवा खाता पहुँच सके। - गंतव्यों को स्वयं रिज़ॉल्व करें और DNS रिज़ॉल्यूशन के बाद, कनेक्ट करते समय, प्लेन HTTP तथा HTTPS `CONNECT` टनल दोनों के लिए IP के आधार पर अवरुद्ध करें। - लूपबैक, निजी, लिंक-स्थानीय, मेटाडेटा, मल्टीकास्ट, आरक्षित और दस्तावेज़ीकरण श्रेणियों के लिए गंतव्य-आधारित बायपास अस्वीकार करें। - होस्टनेम अनुमति-सूचियों से बचें, जब तक कि आपको DNS रिज़ॉल्यूशन पथ पर पूर्ण विश्वास न हो। - गंतव्य, निर्णय, स्थिति और कारण लॉग करें — अनुरोध बॉडी, प्राधिकरण हेडर, कुकी या अन्य सीक्रेट कभी नहीं। - नीति को संस्करण नियंत्रण के अंतर्गत रखें और परिवर्तनों की सुरक्षा-संवेदनशील मानकर समीक्षा करें। उसी होस्ट/कंटेनर/सेवा खाते से सत्यापित करें जो OpenClaw चलाता है: ```bash openclaw proxy validate --proxy-url http://127.0.0.1:3128 ``` निजी-CA वाले HTTPS प्रॉक्सी एंडपॉइंट के साथ: ```bash openclaw proxy validate --proxy-url https://proxy.corp.example:8443 --proxy-ca-file /etc/openclaw/proxy-ca.pem ``` | फ़्लैग | उद्देश्य | | ------------------------ | -------------------------------------------------------------------- | | `--proxy-url ` | कॉन्फ़िगरेशन/पर्यावरण को हल करने के बजाय इस URL को सत्यापित करें। | | `--proxy-ca-file ` | HTTPS प्रॉक्सी एंडपॉइंट के लिए CA बंडल। | | `--allowed-url ` | वह गंतव्य जिसके सफल होने की अपेक्षा है (दोहराया जा सकता है)। | | `--denied-url ` | वह गंतव्य जिसके अवरुद्ध होने की अपेक्षा है (दोहराया जा सकता है)। | | `--apns-reachable` | यह भी सत्यापित करें कि प्रॉक्सी सीधे सैंडबॉक्स APNs HTTP/2 प्रोब को टनल कर सकता है। | | `--apns-authority ` | `--apns-reachable` के साथ जाँचे गए APNs अथॉरिटी को ओवरराइड करें। | | `--timeout-ms ` | प्रति-अनुरोध टाइमआउट। | | `--json` | मशीन-पठनीय आउटपुट। | यदि कोई कॉन्फ़िगरेशन, पर्यावरण या `--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, दोनों आउटपुट से संपादित कर दिए जाते हैं। ```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` की अंतर्निहित कैनरी कर सकती है): ```bash 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 आपके बाहरी प्रॉक्सी में इन नियमों को निर्यात या लागू नहीं करता। | रेंज या होस्ट | अवरुद्ध करने का कारण | | ------------------------------------------------------------------------------------ | ------------------------------------------------- | | `127.0.0.0/8`, `localhost`, `localhost.localdomain` | IPv4 लूपबैक | | `::1/128` | IPv6 लूपबैक | | `0.0.0.0/8`, `::/128` | अनिर्दिष्ट / इस-नेटवर्क के पते | | `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16` | RFC 1918 निजी नेटवर्क | | `169.254.0.0/16`, `fe80::/10` | लिंक-लोकल, जिसमें सामान्य क्लाउड मेटाडेटा पथ शामिल हैं | | `169.254.169.254`, `metadata.google.internal` | क्लाउड मेटाडेटा सेवाएँ | | `100.64.0.0/10` | कैरियर-ग्रेड NAT साझा पता स्थान | | `198.18.0.0/15`, `2001:2::/48` | बेंचमार्किंग रेंज | | `192.0.0.0/24`, `192.0.2.0/24`, `198.51.100.0/24`, `203.0.113.0/24`, `2001:db8::/32` | विशेष-उपयोग और दस्तावेज़ीकरण रेंज | | `224.0.0.0/4`, `ff00::/8` | मल्टीकास्ट | | `240.0.0.0/4` | आरक्षित IPv4 | | `fc00::/7`, `fec0::/10` | IPv6 स्थानीय/निजी रेंज | | `100::/64`, `2001:20::/28` | IPv6 डिस्कार्ड और ORCHIDv2 रेंज | | `64:ff9b::/96`, `64:ff9b:1::/48` | एम्बेडेड IPv4 वाले NAT64 उपसर्ग | | `2002::/16`, `2001::/32` | एम्बेडेड IPv4 वाले 6to4 और Teredo | | `::/96`, `::ffff:0:0/96` | IPv4-संगत और IPv4-मैप किया गया IPv6 | अपने क्लाउड प्रदाता या नेटवर्क प्लेटफ़ॉर्म द्वारा दस्तावेज़ीकृत कोई भी अतिरिक्त मेटाडेटा होस्ट या आरक्षित रेंज जोड़ें। ## सीमाएँ | सतह | प्रबंधित प्रॉक्सी की स्थिति | | ------------------------------------------------------------ | -------------------------------------------------------------------------------------------------------------------------------------------------------- | | `fetch`, `node:http`, `node:https`, सामान्य WebSocket क्लाइंट | कॉन्फ़िगर होने पर प्रबंधित प्रॉक्सी हुक के माध्यम से रूट किए जाते हैं। | | APNs प्रत्यक्ष HTTP/2 | APNs प्रबंधित `CONNECT` सहायक के माध्यम से रूट किया जाता है। | | Gateway नियंत्रण-प्लेन लूपबैक | केवल सटीक कॉन्फ़िगर किए गए स्थानीय लूपबैक Gateway URL के लिए प्रत्यक्ष। | | डीबग प्रॉक्सी अपस्ट्रीम अग्रेषण | स्थानीय निदान के लिए स्पष्ट रूप से सक्षम किए बिना, प्रबंधित प्रॉक्सी मोड सक्रिय रहने के दौरान अक्षम। | | IRC | रॉ TCP/TLS; प्रबंधित HTTP प्रॉक्सी मोड द्वारा प्रॉक्सी नहीं किया जाता। यदि आपके परिनियोजन के लिए सभी इग्रेस को फ़ॉरवर्ड प्रॉक्सी के माध्यम से भेजना आवश्यक है, तो `channels.irc.enabled: false` सेट करें। | | अन्य रॉ `net`, `tls` या `http2` क्लाइंट कॉल | लैंड होने से पहले रॉ सॉकेट गार्ड द्वारा वर्गीकृत किया जाना आवश्यक है। | - यह JavaScript HTTP/WebSocket क्लाइंट के लिए प्रक्रिया-स्तरीय कवरेज है, OS-स्तरीय नेटवर्क सैंडबॉक्स नहीं। - रॉ `net`, `tls`, `http2` सॉकेट, नेटिव ऐड-ऑन और गैर-OpenClaw चाइल्ड प्रक्रियाएँ Node-स्तरीय रूटिंग को बायपास कर सकती हैं, जब तक कि वे प्रॉक्सी पर्यावरण चर इनहेरिट करके उनका सम्मान न करें। फ़ोर्क किए गए OpenClaw चाइल्ड CLI प्रबंधित प्रॉक्सी URL और `proxy.loopbackMode` स्थिति इनहेरिट करते हैं। - उपयोगकर्ता के स्थानीय WebUI और स्थानीय मॉडल सर्वर सामान्य स्थानीय-नेटवर्क बायपास के अंतर्गत नहीं आते — आवश्यकता होने पर उन्हें ऑपरेटर प्रॉक्सी नीति की अनुमति-सूची में जोड़ें। अपवाद बंडल किए गए Ollama मेमोरी एम्बेडिंग प्रदाता का संरक्षित प्रत्यक्ष पथ है, जो उसके कॉन्फ़िगर किए गए `baseUrl` से सटीक होस्ट-लोकल लूपबैक मूल तक सीमित है; LAN, टेलनेट, निजी-नेटवर्क और सार्वजनिक Ollama होस्ट अब भी प्रबंधित प्रॉक्सी का उपयोग करते हैं। - स्थानीय डीबग प्रॉक्सी का प्रत्यक्ष अपस्ट्रीम अग्रेषण (प्रॉक्सी अनुरोधों और `CONNECT` टनल के लिए) प्रबंधित प्रॉक्सी मोड सक्रिय रहने के दौरान डिफ़ॉल्ट रूप से अक्षम रहता है; इसे केवल अनुमोदित स्थानीय निदान के लिए सक्षम करें। - OpenClaw आपकी प्रॉक्सी नीति का निरीक्षण, परीक्षण या प्रमाणन नहीं करता। प्रॉक्सी नीति में परिवर्तनों को सुरक्षा-संवेदनशील परिचालन परिवर्तनों के रूप में मानें।