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

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 हटाने पर यह निष्क्रिय हो जाती है।

कुंजी	प्रकार	डिफ़ॉल्ट	टिप्पणियाँ
`proxy.proxyUrl`	स्ट्रिंग	सेट नहीं	`http://` या `https://` फ़ॉरवर्ड प्रॉक्सी URL। URL में अंतर्निहित क्रेडेंशियल को संवेदनशील माना जाता है और स्नैपशॉट/लॉग में छिपा दिया जाता है।
`proxy.tls.caFile`	स्ट्रिंग	सेट नहीं	निजी CA द्वारा हस्ताक्षरित `https://` प्रॉक्सी एंडपॉइंट को सत्यापित करने के लिए CA बंडल।
`proxy.loopbackMode`	`gateway-only` \| `proxy` \| `block`	`gateway-only`	लूपबैक बायपास व्यवहार नियंत्रित करता है; नीचे देखें।

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

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 प्रॉक्सी एंडपॉइंट

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: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 निकास ट्रैफ़िक को प्रॉक्सी के माध्यम से रूट करती हैं:

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-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 सेट न करें।

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

प्रॉक्सी की गंतव्य नीति वास्तविक सुरक्षा सीमा है; 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 <url>`	कॉन्फ़िगरेशन/पर्यावरण को हल करने के बजाय इस URL को सत्यापित करें।
`--proxy-ca-file <path>`	HTTPS प्रॉक्सी एंडपॉइंट के लिए CA बंडल।
`--allowed-url <url>`	वह गंतव्य जिसके सफल होने की अपेक्षा है (दोहराया जा सकता है)।
`--denied-url <url>`	वह गंतव्य जिसके अवरुद्ध होने की अपेक्षा है (दोहराया जा सकता है)।
`--apns-reachable`	यह भी सत्यापित करें कि प्रॉक्सी सीधे सैंडबॉक्स APNs HTTP/2 प्रोब को टनल कर सकता है।
`--apns-authority <url>`	`--apns-reachable` के साथ जाँचे गए APNs अथॉरिटी को ओवरराइड करें।
`--timeout-ms <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, दोनों आउटपुट से संपादित कर दिए जाते हैं।

{
  "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 आपके बाहरी प्रॉक्सी में इन नियमों को निर्यात या लागू नहीं करता।

रेंज या होस्ट	अवरुद्ध करने का कारण
`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 आपकी प्रॉक्सी नीति का निरीक्षण, परीक्षण या प्रमाणन नहीं करता। प्रॉक्सी नीति में परिवर्तनों को सुरक्षा-संवेदनशील परिचालन परिवर्तनों के रूप में मानें।

Gateway

Remote access

Security

Nodes and media

Web interfaces

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

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

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

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

Gateway लूपबैक मोड

कंटेनर

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

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

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

सीमाएँ

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

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

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

​Gateway लूपबैक मोड

​कंटेनर

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

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

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

​सीमाएँ

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

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

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

Gateway लूपबैक मोड

कंटेनर

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

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

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

सीमाएँ