> ## Documentation Index
> Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# وكيل الشبكة

يمكن لـ OpenClaw توجيه حركة مرور HTTP وWebSocket وقت التشغيل عبر وكيل تمرير مُدار من المشغّل. هذا دفاع اختياري متعدد الطبقات لعمليات النشر التي تريد تحكماً مركزياً في الخروج، وحماية أقوى من SSRF، وقابلية أفضل لتدقيق الشبكة.

لا يوفّر OpenClaw وكيلاً ولا ينزّله ولا يبدأه ولا يهيّئه ولا يصادق عليه. أنت تشغّل تقنية الوكيل التي تناسب بيئتك، وOpenClaw يوجّه عملاء HTTP وWebSocket المحليين العاديين للعملية عبرها.

## لماذا تستخدم وكيلاً

يوفّر الوكيل للمشغّلين نقطة تحكم شبكية واحدة لحركة HTTP وWebSocket الصادرة. قد يكون ذلك مفيداً حتى خارج تقوية SSRF:

* السياسة المركزية: حافظ على سياسة خروج واحدة بدلاً من الاعتماد على كل موضع استدعاء HTTP في التطبيق لضبط قواعد الشبكة بشكل صحيح.
* فحوصات وقت الاتصال: قيّم الوجهة بعد حل DNS ومباشرة قبل أن يفتح الوكيل الاتصال الصاعد.
* دفاع ضد إعادة ربط DNS: قلّل الفجوة بين فحص DNS على مستوى التطبيق والاتصال الصادر الفعلي.
* تغطية JavaScript أوسع: وجّه عملاء `fetch` و`node:http` و`node:https` وWebSocket وaxios وgot وnode-fetch والعملاء المشابهين عبر المسار نفسه.
* قابلية التدقيق: سجّل الوجهات المسموح بها والمرفوضة عند حد الخروج.
* التحكم التشغيلي: افرض قواعد الوجهات، أو تقسيم الشبكة، أو حدود المعدل، أو قوائم السماح الصادرة من دون إعادة بناء OpenClaw.

توجيه الوكيل حاجز حماية على مستوى العملية لخروج HTTP وWebSocket العادي. يمنح المشغّلين مساراً يفشل بإغلاق لتوجيه عملاء JavaScript HTTP المدعومين عبر وكيل الترشيح الخاص بهم، لكنه ليس بيئة عزل شبكية على مستوى نظام التشغيل ولا يجعل OpenClaw يصادق على سياسة وجهات الوكيل.

## كيف يوجّه OpenClaw حركة المرور

عندما تكون `proxy.enabled=true` ويكون عنوان URL للوكيل مهيّأً، توجّه عمليات وقت التشغيل المحمية مثل `openclaw gateway run` و`openclaw node run` و`openclaw agent --local` خروج HTTP وWebSocket العادي عبر الوكيل المهيّأ:

```text theme={"theme":{"light":"min-light","dark":"min-dark"}}
OpenClaw process
  fetch                  -> operator-managed filtering proxy -> public internet
  node:http and https    -> operator-managed filtering proxy -> public internet
  WebSocket clients      -> operator-managed filtering proxy -> public internet
```

العقد العام هو سلوك التوجيه، وليس خطافات Node الداخلية المستخدمة لتنفيذه. يستخدم عملاء WebSocket لمستوى التحكم في OpenClaw Gateway مساراً مباشراً ضيقاً لحركة RPC الخاصة بـ local loopback Gateway عندما يستخدم عنوان URL الخاص بـ Gateway القيمة `localhost` أو عنوان IP حرفياً للـ loopback مثل `127.0.0.1` أو `[::1]`. يجب أن يكون مسار مستوى التحكم هذا قادراً على الوصول إلى Gateways عبر loopback حتى عندما يحظر وكيل المشغّل وجهات loopback. لا تزال طلبات HTTP وWebSocket العادية وقت التشغيل تستخدم الوكيل المهيّأ.

داخلياً، يثبّت OpenClaw Proxyline كبيئة توجيه على مستوى العملية لهذه الميزة. يغطي Proxyline `fetch`، والعملاء المدعومين بـ undici، ومستدعي Node الأساسيين `node:http` / `node:https`، وعملاء WebSocket الشائعين، وأنفاق CONNECT المنشأة عبر المساعدات. يستبدل وضع الوكيل المُدار وكلاء Node HTTP المقدّمين من المستدعي حتى لا تتجاوز الوكلاء الصريحة وكيل المشغّل عن غير قصد.

تملك بعض Plugins وسائل نقل مخصصة تحتاج إلى توصيل صريح بالوكيل حتى عند وجود توجيه على مستوى العملية. على سبيل المثال، يستخدم نقل Bot API في Telegram مرسلاً خاصاً به لـ HTTP/1 عبر undici ولذلك يحترم بيئة وكيل العملية إضافة إلى بديل `OPENCLAW_PROXY_URL` المُدار في مسار النقل الخاص بذلك المالك.

يمكن أن يستخدم عنوان URL الخاص بالوكيل إما `http://` أو `https://`. تصف هذه المخططات الاتصال من OpenClaw إلى نقطة نهاية الوكيل:

* `http://proxy.example:3128`: يفتح OpenClaw اتصال TCP عادياً إلى وكيل التمرير ويرسل طلبات وكيل HTTP، بما في ذلك `CONNECT` لوجهات HTTPS.
* `https://proxy.example:8443`: يفتح OpenClaw اتصال TLS إلى نقطة نهاية الوكيل، ويتحقق من شهادة الوكيل، ثم يرسل طلبات وكيل HTTP داخل جلسة TLS تلك.

تختلف HTTPS الوجهة عن TLS نقطة نهاية الوكيل. بالنسبة إلى وجهة HTTPS، لا يزال OpenClaw يطلب من الوكيل نفق HTTP `CONNECT` ثم يبدأ TLS الوجهة عبر ذلك النفق.

أثناء نشاط الوكيل، يمسح OpenClaw القيمتين `no_proxy` و`NO_PROXY`. تعتمد قوائم التجاوز هذه على الوجهة، لذلك فإن ترك `localhost` أو `127.0.0.1` فيها سيسمح لأهداف SSRF عالية المخاطر بتخطي وكيل الترشيح.

عند الإيقاف، يستعيد OpenClaw بيئة الوكيل السابقة ويعيد ضبط حالة توجيه العملية المخزنة مؤقتاً.

## مصطلحات الوكيل ذات الصلة

* `proxy.enabled` / `proxy.proxyUrl`: توجيه وكيل التمرير الصادر لخروج OpenClaw وقت التشغيل. توثّق هذه الصفحة تلك الميزة.
* `gateway.auth.mode: "trusted-proxy"`: مصادقة وكيل عكسي وارد واعٍ بالهوية للوصول إلى Gateway. راجع [مصادقة الوكيل الموثوق](/ar/gateway/trusted-proxy-auth).
* `openclaw proxy`: وكيل تصحيح أخطاء محلي ومفتش التقاط للتطوير والدعم. راجع [openclaw proxy](/ar/cli/proxy).
* `tools.web.fetch.useTrustedEnvProxy`: اشتراك اختياري لـ `web_fetch` للسماح لوكيل بيئة HTTP(S) يتحكم به المشغّل بحل DNS مع إبقاء تثبيت DNS الصارم الافتراضي وسياسة اسم المضيف. راجع [جلب الويب](/ar/tools/web-fetch#trusted-env-proxy).
* إعدادات الوكيل الخاصة بالقناة أو المزوّد: تجاوزات خاصة بالمالك لنقل معين. فضّل وكيل الشبكة المُدار عندما يكون الهدف هو التحكم المركزي في الخروج عبر وقت التشغيل.

## التهيئة

```yaml theme={"theme":{"light":"min-light","dark":"min-dark"}}
proxy:
  enabled: true
  proxyUrl: http://127.0.0.1:3128
```

لنقطة نهاية وكيل HTTPS مع CA وكيل خاصة:

```yaml theme={"theme":{"light":"min-light","dark":"min-dark"}}
proxy:
  enabled: true
  proxyUrl: https://proxy.corp.example:8443
  tls:
    caFile: /etc/openclaw/proxy-ca.pem
```

يمكنك أيضاً توفير عنوان URL عبر البيئة، مع إبقاء `proxy.enabled=true` في التهيئة:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
OPENCLAW_PROXY_URL=http://127.0.0.1:3128 openclaw gateway run
```

تكون لـ `proxy.proxyUrl` أسبقية على `OPENCLAW_PROXY_URL`.

### وضع Gateway Loopback

عادةً ما يتصل عملاء مستوى التحكم المحليون في Gateway بـ WebSocket عبر loopback مثل `ws://127.0.0.1:18789`. استخدم `proxy.loopbackMode` لاختيار كيفية تصرف استثناءات الوكيل المُدار للـ loopback أثناء نشاط الوكيل المُدار:

```yaml theme={"theme":{"light":"min-light","dark":"min-dark"}}
proxy:
  enabled: true
  proxyUrl: http://127.0.0.1:3128
  loopbackMode: gateway-only # gateway-only, proxy, or block
```

* `gateway-only` (الافتراضي): يسجل OpenClaw سلطة loopback الخاصة بـ Gateway في سياسة التجاوز المُدارة لدى Proxyline حتى تتمكن حركة WebSocket المحلية الخاصة بـ Gateway من الاتصال مباشرة. تعمل منافذ Gateway المخصصة عبر loopback لأن مضيف ومنفذ عنوان URL النشط لـ Gateway مسجلان. يمكن للـ Plugin المتصفح المضمّن أيضاً تسجيل نقاط نهاية جاهزية CDP وWebSocket الخاصة بـ DevTools المحلية الدقيقة للمتصفحات المُدارة التي يشغّلها OpenClaw، ويمكن لمزوّد تضمينات الذاكرة Ollama المضمّن استخدام مساره المباشر المحروس الأضيق لأصل تضمين loopback المحلي للمضيف المهيّأ بدقة.
* `proxy`: لا يسجل OpenClaw تجاوزات loopback لـ Gateway أو Ollama، لذلك تُرسل حركة loopback تلك عبر الوكيل المُدار. إذا كان الوكيل بعيداً، فيجب أن يوفر توجيهاً خاصاً لخدمة loopback على مضيف OpenClaw، مثل ربطها باسم مضيف أو IP أو نفق يمكن للوكيل الوصول إليه. تحل الوكلاء البعيدة القياسية `127.0.0.1` و`localhost` من مضيف الوكيل، لا من مضيف OpenClaw.
* `block`: يرفض OpenClaw اتصالات مستوى التحكم عبر loopback الخاصة بـ Gateway واتصالات loopback المحروسة لتضمين Ollama المحلي للمضيف قبل فتح مقبس.

إذا كانت `enabled=true` لكن لم يُهيَّأ عنوان URL صالح للوكيل، تفشل الأوامر المحمية عند بدء التشغيل بدلاً من الرجوع إلى الوصول المباشر إلى الشبكة.

بالنسبة إلى خدمات Gateway المُدارة التي تبدأ باستخدام `openclaw gateway start`، فضّل تخزين عنوان URL في التهيئة:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw config set proxy.enabled true
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 تشغيل Gateway بتلك القيمة.

بالنسبة إلى أوامر `openclaw --container ...`، يمرّر OpenClaw `OPENCLAW_PROXY_URL` إلى CLI الابن المستهدف للحاوية عندما يكون مضبوطاً. يجب أن يكون عنوان URL قابلاً للوصول من داخل الحاوية؛ يشير `127.0.0.1` إلى الحاوية نفسها، وليس المضيف. يرفض OpenClaw عناوين URL الخاصة بالوكيل عبر loopback للأوامر المستهدفة للحاوية ما لم تتجاوز فحص السلامة هذا صراحةً.

## متطلبات الوكيل

سياسة الوكيل هي حد الأمان. لا يستطيع OpenClaw التحقق من أن الوكيل يحظر الأهداف الصحيحة.

هيّئ الوكيل لكي:

* يرتبط فقط بالـ loopback أو بواجهة خاصة موثوقة.
* يقيّد الوصول بحيث لا يمكن استخدامه إلا من عملية OpenClaw أو المضيف أو الحاوية أو حساب الخدمة.
* يحل الوجهات بنفسه ويحظر عناوين IP الوجهة بعد حل DNS.
* يطبق السياسة وقت الاتصال لكل من طلبات HTTP العادية وأنفاق HTTPS `CONNECT`.
* يرفض التجاوزات المعتمدة على الوجهة لنطاقات loopback أو الخاصة أو link-local أو metadata أو multicast أو reserved أو documentation.
* يتجنب قوائم سماح أسماء المضيفين ما لم تكن تثق بالكامل بمسار حل DNS.
* يسجل الوجهة والقرار والحالة والسبب من دون تسجيل أجسام الطلبات أو ترويسات التفويض أو ملفات تعريف الارتباط أو الأسرار الأخرى.
* يبقي سياسة الوكيل تحت التحكم في الإصدارات ويراجع التغييرات مثل التهيئة الحساسة أمنياً.

## الوجهات المحظورة الموصى بها

استخدم قائمة الرفض هذه كنقطة بداية لأي وكيل تمرير أو جدار حماية أو سياسة خروج.

يعيش منطق المصنّف على مستوى تطبيق OpenClaw في `src/infra/net/ssrf.ts` و`packages/net-policy/src/ip.ts`. خطافات التكافؤ ذات الصلة هي `BLOCKED_HOSTNAMES` و`BLOCKED_IPV4_SPECIAL_USE_RANGES` و`BLOCKED_IPV6_SPECIAL_USE_RANGES` و`RFC2544_BENCHMARK_PREFIX` ومعالجة حارس IPv4 المضمّنة لأشكال NAT64 و6to4 وTeredo وISATAP وIPv4-mapped. هذه الملفات مراجع مفيدة عند صيانة سياسة وكيل خارجية، لكن OpenClaw لا يصدّر هذه القواعد أو يفرضها تلقائياً في وكيلك.

| النطاق أو المضيف                                                                     | سبب الحظر                                                      |
| ------------------------------------------------------------------------------------ | -------------------------------------------------------------- |
| `127.0.0.0/8`, `localhost`, `localhost.localdomain`                                  | local loopback عبر IPv4                                        |
| `::1/128`                                                                            | local loopback عبر IPv6                                        |
| `0.0.0.0/8`, `::/128`                                                                | العناوين غير المحددة وعناوين هذه الشبكة                        |
| `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`                                      | شبكات RFC1918 الخاصة                                           |
| `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`                                                     | بادئات NAT64 مع IPv4 مضمن                                      |
| `2002::/16`, `2001::/32`                                                             | 6to4 وTeredo مع IPv4 مضمن                                      |
| `::/96`, `::ffff:0:0/96`                                                             | IPv6 المتوافق مع IPv4 وIPv6 المعيّن إلى IPv4                   |

إذا وثّق مزود السحابة أو منصة الشبكة لديك مضيفات بيانات تعريف إضافية أو نطاقات محجوزة، فأضفها أيضًا.

## التحقق

تحقق من الوكيل من المضيف أو الحاوية أو حساب الخدمة نفسه الذي يشغّل OpenClaw:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw proxy validate --proxy-url http://127.0.0.1:3128
```

لنقطة نهاية وكيل HTTPS موقعة بواسطة CA خاص:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw proxy validate --proxy-url https://proxy.corp.example:8443 --proxy-ca-file /etc/openclaw/proxy-ca.pem
```

افتراضيًا، عند عدم توفير وجهات مخصصة، يتحقق الأمر من نجاح `https://example.com/` ويبدأ عصفور loopback مؤقتًا يجب ألا يصل إليه الوكيل. ينجح فحص الرفض الافتراضي عندما يعيد الوكيل استجابة رفض غير 2xx أو يحظر العصفور بفشل نقل؛ ويفشل إذا وصلت استجابة ناجحة إلى العصفور. إذا لم يكن أي وكيل ممكّنًا ومكوّنًا، يبلغ التحقق عن مشكلة في الإعدادات؛ استخدم `--proxy-url` لإجراء فحص تمهيدي لمرة واحدة قبل تغيير الإعدادات. استخدم `--allowed-url` و`--denied-url` لاختبار التوقعات الخاصة بالنشر. أضف `--apns-reachable` للتحقق أيضًا من أن تسليم APNs HTTP/2 المباشر يمكنه فتح نفق CONNECT عبر الوكيل وتلقي استجابة APNs من sandbox؛ يستخدم الفحص رمز مزود غير صالح عمدًا، لذلك تكون `403 InvalidProviderToken` متوقعة وتُحتسب كقابلة للوصول. الوجهات المرفوضة المخصصة مغلقة عند الفشل: أي استجابة HTTP تعني أن الوجهة كانت قابلة للوصول عبر الوكيل، وأي خطأ نقل يُبلّغ عنه كغير حاسم لأن OpenClaw لا يستطيع إثبات أن الوكيل حظر أصلًا قابلًا للوصول. عند فشل التحقق، يخرج الأمر بالرمز 1.

استخدم `--json` للأتمتة. يحتوي خرج JSON على النتيجة الإجمالية، ومصدر إعدادات الوكيل الفعال، وأي أخطاء إعدادات، وكل فحص وجهة. تُنقّح بيانات اعتماد URL الوكيل في خرج النص وJSON:

```json theme={"theme":{"light":"min-light","dark":"min-dark"}}
{
  "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`:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
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/
```

يجب أن ينجح الطلب العام. يجب أن يحظر الوكيل طلبات loopback وبيانات التعريف. بالنسبة إلى `openclaw proxy validate`، يستطيع عصفور loopback المضمّن التمييز بين رفض الوكيل وأصل قابل للوصول. لا تحتوي فحوصات `--denied-url` المخصصة على ذلك العصفور، لذلك تعامل مع كل من استجابات HTTP وإخفاقات النقل الغامضة كإخفاقات تحقق ما لم يكشف الوكيل لديك عن إشارة رفض خاصة بالنشر يمكنك التحقق منها بشكل منفصل.

## ثقة CA للوكيل

استخدم `proxy.tls.caFile` المدار عندما تستخدم نقطة نهاية الوكيل نفسها شهادة موقعة من CA خاص:

```yaml theme={"theme":{"light":"min-light","dark":"min-dark"}}
proxy:
  enabled: true
  proxyUrl: https://proxy.corp.example:8443
  tls:
    caFile: /etc/openclaw/proxy-ca.pem
```

يُستخدم ذلك CA للتحقق من TLS لنقطة نهاية الوكيل. ولا يُعد إعداد ثقة MITM للوجهة، أو شهادة عميل، أو بديلًا لسياسة وجهات الوكيل.

استخدم `NODE_EXTRA_CA_CERTS` فقط عندما يجب أن تثق عملية Node كلها بـ CA إضافي منذ بدء العملية، مثلما يحدث عندما يعيد نظام فحص TLS مؤسسي توقيع شهادات الوجهات لكل عميل HTTPS في العملية. `NODE_EXTRA_CA_CERTS` عام على مستوى العملية ويجب أن يكون موجودًا قبل بدء Node. فضّل `proxy.tls.caFile` لثقة نقطة نهاية وكيل HTTPS لأنه محدود النطاق بتوجيه الوكيل المدار.

ثم فعّل توجيه وكيل OpenClaw:

```bash theme={"theme":{"light":"min-light","dark":"min-dark"}}
openclaw config set proxy.enabled true
openclaw config set proxy.proxyUrl https://proxy.corp.example:8443
openclaw config set proxy.tls.caFile /etc/openclaw/proxy-ca.pem
openclaw gateway run
```

أو اضبط:

```yaml theme={"theme":{"light":"min-light","dark":"min-dark"}}
proxy:
  enabled: true
  proxyUrl: https://proxy.corp.example:8443
  tls:
    caFile: /etc/openclaw/proxy-ca.pem
```

## الحدود

* يحسّن الوكيل التغطية لعملاء HTTP وWebSocket في JavaScript المحليين للعملية، لكنه ليس صندوق حماية شبكيًا على مستوى نظام التشغيل.
* تكون حركة مستوى تحكم local loopback الخاصة بـ Gateway مباشرة افتراضيًا عبر تجاوز محلي مباشر من خلال `proxy.loopbackMode: "gateway-only"`. ينفذ OpenClaw هذا التجاوز بتسجيل سلطة local loopback النشطة لـ Gateway في سياسة التجاوز المدارة في Proxyline. يمكن للمشغلين ضبط `proxy.loopbackMode: "proxy"` لإرسال حركة local loopback الخاصة بـ Gateway عبر الوكيل المدار، أو `proxy.loopbackMode: "block"` لرفض اتصالات Gateway عبر local loopback. راجع [وضع Gateway Loopback](#gateway-loopback-mode) لمعرفة التنبيه الخاص بالوكيل البعيد.
* قد تتجاوز مقابس `net` و`tls` و`http2` الخام، والإضافات الأصلية، وعمليات الأبناء غير التابعة لـ OpenClaw توجيه الوكيل على مستوى Node ما لم ترث متغيرات بيئة الوكيل وتحترمها. ترث واجهات CLI الفرعية المتشعبة من OpenClaw عنوان URL للوكيل المدار وحالة `proxy.loopbackMode`.
* IRC قناة TCP/TLS خام خارج توجيه وكيل التمرير الأمامي المدار بواسطة المشغل. في عمليات النشر التي تتطلب أن يمر كل الخروج عبر وكيل التمرير الأمامي ذلك، اضبط `channels.irc.enabled=false` ما لم تتم الموافقة صراحةً على خروج IRC المباشر.
* وكيل التصحيح المحلي أداة تشخيصية، ويكون تمريره المباشر إلى المنبع لطلبات الوكيل وأنفاق CONNECT معطلًا افتراضيًا أثناء نشاط وضع الوكيل المدار؛ فعّل التمرير المباشر فقط للتشخيصات المحلية المعتمدة.
* يجب إدراج واجهات WebUI المحلية للمستخدم وخوادم النماذج المحلية في قائمة السماح ضمن سياسة وكيل المشغل عند الحاجة؛ لا يعرّض OpenClaw تجاوزًا عامًا للشبكة المحلية لها. موفر تضمينات الذاكرة Ollama المضمّن أضيق نطاقًا: يمكنه استخدام مسار مباشر محروس فقط لأصل تضمين local loopback المضيفي الدقيق المشتق من `baseUrl` المكوّن حتى تظل تضمينات المضيف المحلي تعمل عندما لا يستطيع الوكيل المدار الوصول إلى loopback المضيف. ما زالت مضيفات تضمينات Ollama على LAN وtailnet والشبكات الخاصة والعامة تستخدم مسار الوكيل المدار. يرسل `proxy.loopbackMode: "proxy"` حركة Ollama عبر loopback هذه عبر الوكيل المدار، ويرفضها `proxy.loopbackMode: "block"` قبل فتح اتصال.
* يقتصر تجاوز وكيل مستوى تحكم Gateway عمدًا على `localhost` وعناوين URL ذات IP loopback الحرفية. استخدم `ws://127.0.0.1:18789` أو `ws://[::1]:18789` أو `ws://localhost:18789` لاتصالات مستوى تحكم Gateway المحلية المباشرة؛ تُوجّه أسماء المضيفين الأخرى مثل حركة المرور العادية القائمة على اسم المضيف.
* لا يفحص OpenClaw سياسة الوكيل لديك أو يختبرها أو يصادق عليها.
* تعامل مع تغييرات سياسة الوكيل كتغييرات تشغيلية حساسة أمنيًا.

| السطح                                                        | حالة الوكيل المدار                                                                           |
| ------------------------------------------------------------ | -------------------------------------------------------------------------------------------- |
| `fetch`, `node:http`, `node:https`, عملاء WebSocket الشائعون | تُوجّه عبر خطافات الوكيل المدار عند تكوينها.                                                 |
| APNs HTTP/2 المباشر                                          | يُوجّه عبر مساعد CONNECT المدار لـ APNs.                                                     |
| local loopback لمستوى تحكم Gateway                           | مباشر فقط لعنوان URL المحلي المكوّن لـ Gateway عبر loopback.                                 |
| تمرير المنبع لوكيل التصحيح                                   | معطل أثناء نشاط وضع الوكيل المدار ما لم يُفعّل صراحةً للتشخيصات المحلية.                     |
| IRC                                                          | TCP/TLS خام؛ لا يمر عبر وضع وكيل HTTP المدار. عطّله ما لم تتم الموافقة على خروج IRC المباشر. |
| نداءات العملاء الأخرى الخام عبر `net` أو `tls` أو `http2`    | يجب تصنيفها بواسطة حارس المقابس الخام قبل الدمج.                                             |
