---
read_when:
    - می‌خواهید در برابر حملات SSRF و بازپیوند DNS دفاع در عمق داشته باشید
    - پیکربندی یک پراکسی فوروارد خارجی برای ترافیک زمان اجرای OpenClaw
summary: نحوه مسیریابی ترافیک HTTP و WebSocket زمان اجرای OpenClaw از طریق یک پروکسی فیلترکننده مدیریت‌شده توسط اپراتور
title: پروکسی شبکه
x-i18n:
    generated_at: "2026-05-01T11:53:51Z"
    model: gpt-5.5
    provider: openai
    source_hash: 9207d349e4410e38631ae7665be19b536e4a4128a4e80dd095e802804dfd66a3
    source_path: security/network-proxy.md
    workflow: 16
---

# پراکسی شبکه

OpenClaw می‌تواند ترافیک HTTP و WebSocket زمان اجرا را از طریق یک پراکسی فوروارد مدیریت‌شده توسط اپراتور مسیریابی کند. این یک دفاع لایه‌ای اختیاری برای استقرارهایی است که کنترل مرکزی خروجی، محافظت قوی‌تر در برابر SSRF، و قابلیت ممیزی بهتر شبکه می‌خواهند.

OpenClaw پراکسی را ارائه، دانلود، شروع، پیکربندی یا تأیید نمی‌کند. شما فناوری پراکسی متناسب با محیط خود را اجرا می‌کنید، و OpenClaw کلاینت‌های عادی HTTP و WebSocket محلیِ پردازش را از طریق آن مسیریابی می‌کند.

## چرا از پراکسی استفاده کنیم؟

پراکسی به اپراتورها یک نقطه کنترل شبکه برای ترافیک خروجی HTTP و WebSocket می‌دهد. این می‌تواند حتی خارج از سخت‌سازی SSRF هم مفید باشد:

- سیاست مرکزی: به‌جای تکیه بر اینکه هر محل فراخوانی HTTP در برنامه قوانین شبکه را درست اعمال کند، یک سیاست خروجی واحد نگه دارید.
- بررسی‌های زمان اتصال: مقصد را پس از تفکیک DNS و درست پیش از اینکه پراکسی اتصال بالادستی را باز کند ارزیابی کنید.
- دفاع در برابر DNS rebinding: فاصله بین بررسی DNS در سطح برنامه و اتصال خروجی واقعی را کاهش دهید.
- پوشش گسترده‌تر JavaScript: کلاینت‌های عادی `fetch`، `node:http`، `node:https`، WebSocket، axios، got، node-fetch، و کلاینت‌های مشابه را از همان مسیر عبور دهید.
- قابلیت ممیزی: مقصدهای مجاز و ردشده را در مرز خروجی ثبت کنید.
- کنترل عملیاتی: بدون بازسازی OpenClaw، قوانین مقصد، بخش‌بندی شبکه، محدودیت‌های نرخ، یا فهرست‌های مجاز خروجی را اعمال کنید.

مسیریابی پراکسی یک حفاظ در سطح پردازش برای خروجی عادی HTTP و WebSocket است. این به اپراتورها مسیری fail-closed برای مسیریابی کلاینت‌های HTTP پشتیبانی‌شده JavaScript از طریق پراکسی فیلترکننده خودشان می‌دهد، اما سندباکس شبکه در سطح سیستم‌عامل نیست و باعث نمی‌شود OpenClaw سیاست مقصد پراکسی را تأیید کند.

## OpenClaw چگونه ترافیک را مسیریابی می‌کند

وقتی `proxy.enabled=true` باشد و URL پراکسی پیکربندی شده باشد، پردازش‌های محافظت‌شده زمان اجرا مانند `openclaw gateway run`، `openclaw node run`، و `openclaw agent --local` خروجی عادی HTTP و WebSocket را از طریق پراکسی پیکربندی‌شده مسیریابی می‌کنند:

```text
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 literal حلقه بازگشت مانند `127.0.0.1` یا `[::1]` استفاده می‌کند، از یک مسیر مستقیم محدود استفاده می‌کنند. آن مسیر صفحه کنترل باید بتواند به Gatewayهای loopback برسد حتی وقتی پراکسی اپراتور مقصدهای loopback را مسدود می‌کند. درخواست‌های عادی HTTP و WebSocket زمان اجرا همچنان از پراکسی پیکربندی‌شده استفاده می‌کنند.

در داخل، OpenClaw برای این ویژگی از دو هوک مسیریابی در سطح پردازش استفاده می‌کند:

- مسیریابی dispatcher در Undici، `fetch`، کلاینت‌های مبتنی بر undici، و transportهایی را پوشش می‌دهد که dispatcher اختصاصی undici خود را ارائه می‌کنند.
- مسیریابی `global-agent` فراخواننده‌های هسته Node یعنی `node:http` و `node:https` را پوشش می‌دهد، از جمله بسیاری از کتابخانه‌هایی که روی `http.request`، `https.request`، `http.get`، و `https.get` لایه‌گذاری شده‌اند. حالت پراکسی مدیریت‌شده آن agent سراسری را اجباری می‌کند تا agentهای صریح HTTP در Node به‌طور تصادفی پراکسی اپراتور را دور نزنند.

برخی Pluginها transportهای سفارشی خود را دارند که حتی با وجود مسیریابی در سطح پردازش، به سیم‌کشی صریح پراکسی نیاز دارند. برای مثال، transport مربوط به Bot API در Telegram از dispatcher اختصاصی HTTP/1 undici خودش استفاده می‌کند و بنابراین env پراکسی پردازش به‌همراه fallback مدیریت‌شده `OPENCLAW_PROXY_URL` را در آن مسیر transport مالک‌محور رعایت می‌کند.

خود URL پراکسی باید از `http://` استفاده کند. مقصدهای HTTPS همچنان از طریق پراکسی با HTTP `CONNECT` پشتیبانی می‌شوند؛ این فقط یعنی OpenClaw انتظار یک شنونده ساده پراکسی فوروارد HTTP مانند `http://127.0.0.1:3128` را دارد.

تا زمانی که پراکسی فعال است، OpenClaw مقدارهای `no_proxy`، `NO_PROXY`، و `GLOBAL_AGENT_NO_PROXY` را پاک می‌کند. این فهرست‌های دور زدن مبتنی بر مقصد هستند، بنابراین باقی ماندن `localhost` یا `127.0.0.1` در آن‌ها به هدف‌های پرخطر SSRF اجازه می‌دهد پراکسی فیلترکننده را دور بزنند.

هنگام خاموش شدن، OpenClaw محیط قبلی پراکسی را بازیابی می‌کند و وضعیت مسیریابی پردازشِ کش‌شده را بازنشانی می‌کند.

## اصطلاحات مرتبط پراکسی

- `proxy.enabled` / `proxy.proxyUrl`: مسیریابی پراکسی فوروارد خروجی برای egress زمان اجرای OpenClaw. این صفحه همان ویژگی را مستند می‌کند.
- `gateway.auth.mode: "trusted-proxy"`: احراز هویت ورودی reverse-proxy آگاه از هویت برای دسترسی به Gateway. [احراز هویت trusted proxy](/fa/gateway/trusted-proxy-auth) را ببینید.
- `openclaw proxy`: پراکسی اشکال‌زدایی محلی و بازرس capture برای توسعه و پشتیبانی. [openclaw proxy](/fa/cli/proxy) را ببینید.
- تنظیمات پراکسی مخصوص کانال یا provider: overrideهای مالک‌محور برای یک transport خاص. وقتی هدف، کنترل مرکزی egress در سراسر زمان اجرا است، پراکسی شبکه مدیریت‌شده را ترجیح دهید.

## پیکربندی

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

همچنین می‌توانید URL را از طریق محیط ارائه کنید، در حالی که `proxy.enabled=true` را در پیکربندی نگه می‌دارید:

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

`proxy.proxyUrl` نسبت به `OPENCLAW_PROXY_URL` اولویت دارد.

اگر `enabled=true` باشد اما URL پراکسی معتبر پیکربندی نشده باشد، فرمان‌های محافظت‌شده به‌جای fallback به دسترسی مستقیم شبکه، در راه‌اندازی ناموفق می‌شوند.

برای سرویس‌های Gateway مدیریت‌شده که با `openclaw gateway start` شروع می‌شوند، بهتر است URL را در پیکربندی ذخیره کنید:

```bash
openclaw config set proxy.enabled true
openclaw config set proxy.proxyUrl http://127.0.0.1:3128
openclaw gateway install --force
openclaw gateway start
```

fallback محیط برای اجراهای foreground مناسب‌تر است. اگر از آن با یک سرویس نصب‌شده استفاده می‌کنید، `OPENCLAW_PROXY_URL` را در محیط پایدار سرویس، مانند `$OPENCLAW_STATE_DIR/.env` یا `~/.openclaw/.env` قرار دهید، سپس سرویس را دوباره نصب کنید تا launchd، systemd، یا Scheduled Tasks مقدار را هنگام شروع Gateway داشته باشند.

برای فرمان‌های `openclaw --container ...`، وقتی `OPENCLAW_PROXY_URL` تنظیم شده باشد، OpenClaw آن را به CLI فرزند هدف‌گرفته‌شده برای کانتینر forward می‌کند. URL باید از داخل کانتینر قابل دسترسی باشد؛ `127.0.0.1` به خود کانتینر اشاره می‌کند، نه میزبان. OpenClaw URLهای پراکسی loopback را برای فرمان‌های هدف‌گرفته‌شده برای کانتینر رد می‌کند مگر اینکه صراحتاً آن بررسی ایمنی را override کنید.

## الزامات پراکسی

سیاست پراکسی مرز امنیتی است. OpenClaw نمی‌تواند تأیید کند که پراکسی هدف‌های درست را مسدود می‌کند.

پراکسی را طوری پیکربندی کنید که:

- فقط به loopback یا یک interface خصوصی مورد اعتماد bind شود.
- دسترسی را محدود کند تا فقط پردازش، میزبان، کانتینر، یا حساب سرویس OpenClaw بتواند از آن استفاده کند.
- مقصدها را خودش تفکیک کند و IPهای مقصد را پس از تفکیک DNS مسدود کند.
- سیاست را در زمان اتصال، هم برای درخواست‌های ساده HTTP و هم برای تونل‌های HTTPS `CONNECT` اعمال کند.
- bypassهای مبتنی بر مقصد را برای loopback، private، link-local، metadata، multicast، reserved، یا بازه‌های documentation رد کند.
- از فهرست‌های مجاز hostname پرهیز کنید مگر اینکه به مسیر تفکیک DNS کاملاً اعتماد داشته باشید.
- مقصد، تصمیم، وضعیت، و دلیل را بدون ثبت body درخواست‌ها، headerهای authorization، cookieها، یا secrets دیگر ثبت کند.
- سیاست پراکسی را تحت کنترل نسخه نگه دارد و تغییرات را مانند پیکربندی حساس از نظر امنیتی بازبینی کند.

## مقصدهای مسدودشده پیشنهادی

از این denylist به‌عنوان نقطه شروع برای هر پراکسی فوروارد، firewall، یا سیاست egress استفاده کنید.

منطق classifier سطح برنامه OpenClaw در `src/infra/net/ssrf.ts` و `src/shared/net/ip.ts` قرار دارد. هوک‌های parity مرتبط عبارت‌اند از `BLOCKED_HOSTNAMES`، `BLOCKED_IPV4_SPECIAL_USE_RANGES`، `BLOCKED_IPV6_SPECIAL_USE_RANGES`، `RFC2544_BENCHMARK_PREFIX`، و handling sentinel تعبیه‌شده IPv4 برای NAT64، 6to4، Teredo، ISATAP، و فرم‌های IPv4-mapped. این فایل‌ها هنگام نگهداری یک سیاست پراکسی خارجی مرجع‌های مفیدی هستند، اما OpenClaw آن قوانین را به‌طور خودکار در پراکسی شما export یا enforce نمی‌کند.

| بازه یا میزبان                                                                       | دلیل مسدود کردن                                      |
| ------------------------------------------------------------------------------------ | ---------------------------------------------------- |
| `127.0.0.0/8`, `localhost`, `localhost.localdomain`                                  | loopback در IPv4                                     |
| `::1/128`                                                                            | loopback در IPv6                                     |
| `0.0.0.0/8`, `::/128`                                                                | آدرس‌های نامشخص و this-network                       |
| `10.0.0.0/8`, `172.16.0.0/12`, `192.168.0.0/16`                                      | شبکه‌های خصوصی RFC1918                              |
| `169.254.0.0/16`, `fe80::/10`                                                        | آدرس‌های link-local و مسیرهای رایج metadata ابری     |
| `169.254.169.254`, `metadata.google.internal`                                        | سرویس‌های metadata ابری                              |
| `100.64.0.0/10`                                                                      | فضای آدرس مشترک carrier-grade NAT                   |
| `198.18.0.0/15`, `2001:2::/48`                                                       | بازه‌های benchmark                                  |
| `192.0.0.0/24`, `192.0.2.0/24`, `198.51.100.0/24`, `203.0.113.0/24`, `2001:db8::/32` | بازه‌های special-use و documentation                 |
| `224.0.0.0/4`, `ff00::/8`                                                            | multicast                                            |
| `240.0.0.0/4`                                                                        | IPv4 رزروشده                                        |
| `fc00::/7`, `fec0::/10`                                                              | بازه‌های محلی/خصوصی IPv6                            |
| `100::/64`, `2001:20::/28`                                                           | بازه‌های discard در 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 و IPv4-mapped                   |

اگر provider ابری یا پلتفرم شبکه شما میزبان‌های metadata یا بازه‌های رزروشده بیشتری را مستند کرده است، آن‌ها را هم اضافه کنید.

## اعتبارسنجی

پراکسی را از همان میزبان، کانتینر، یا حساب سرویسی که OpenClaw را اجرا می‌کند اعتبارسنجی کنید:

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

به‌طور پیش‌فرض، وقتی مقصدهای سفارشی ارائه نشده باشند، فرمان بررسی می‌کند که `https://example.com/` موفق شود و یک canary موقت loopback را شروع می‌کند که پراکسی نباید به آن برسد. بررسی denied پیش‌فرض وقتی موفق است که پراکسی یک پاسخ denial غیر 2xx برگرداند یا canary را با شکست transport مسدود کند؛ اگر پاسخی موفق به canary برسد ناموفق می‌شود. اگر هیچ پراکسی فعال و پیکربندی نشده باشد، اعتبارسنجی یک مشکل پیکربندی گزارش می‌کند؛ برای یک preflight یک‌باره پیش از تغییر پیکربندی از `--proxy-url` استفاده کنید. برای آزمودن انتظارهای مخصوص استقرار از `--allowed-url` و `--denied-url` استفاده کنید. مقصدهای denied سفارشی fail-closed هستند: هر پاسخ HTTP یعنی مقصد از طریق پراکسی قابل دسترسی بوده است، و هر خطای transport به‌صورت inconclusive گزارش می‌شود چون OpenClaw نمی‌تواند ثابت کند که پراکسی یک origin قابل دسترسی را مسدود کرده است. در صورت شکست اعتبارسنجی، فرمان با کد 1 خارج می‌شود.

برای automation از `--json` استفاده کنید. خروجی JSON شامل نتیجه کلی، منبع پیکربندی مؤثر پراکسی، هر خطای پیکربندی، و هر بررسی مقصد است. credentialهای URL پراکسی در خروجی متن و JSON redacted می‌شوند:

```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
    }
  ]
}
```

می‌توانید به‌صورت دستی نیز با `curl` اعتبارسنجی کنید:

```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 proxy validate`، قناری لوپ‌بک داخلی می‌تواند رد شدن توسط پراکسی را از یک مبدا قابل دسترسی تشخیص دهد. بررسی‌های سفارشی `--denied-url` آن قناری را ندارند، بنابراین هم پاسخ‌های HTTP و هم خطاهای انتقال مبهم را شکست اعتبارسنجی در نظر بگیرید، مگر اینکه پراکسی شما سیگنال رد مختص استقرار را ارائه کند که بتوانید آن را جداگانه تأیید کنید.

سپس مسیریابی پراکسی OpenClaw را فعال کنید:

```bash
openclaw config set proxy.enabled true
openclaw config set proxy.proxyUrl http://127.0.0.1:3128
openclaw gateway run
```

یا تنظیم کنید:

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

## محدودیت‌ها

- پراکسی پوشش را برای کلاینت‌های HTTP و WebSocket جاوااسکریپت محلیِ فرایند بهبود می‌دهد، اما یک سندباکس شبکه در سطح سیستم‌عامل نیست.
- سوکت‌های خام `net`، `tls`، و `http2`، افزونه‌های بومی، و فرایندهای فرزند ممکن است مسیریابی پراکسی در سطح Node را دور بزنند، مگر اینکه متغیرهای محیطی پراکسی را به ارث ببرند و رعایت کنند.
- WebUIهای محلی کاربر و سرورهای مدل محلی، در صورت نیاز، باید در سیاست پراکسی اپراتور در فهرست مجاز قرار گیرند؛ OpenClaw یک مسیر عبور عمومی برای شبکه محلی در اختیار آن‌ها نمی‌گذارد.
- مسیر عبور پراکسی صفحه کنترل Gateway عمداً به `localhost` و URLهای IP لوپ‌بک صریح محدود شده است. برای اتصال‌های مستقیم محلی صفحه کنترل Gateway از `ws://127.0.0.1:18789`، `ws://[::1]:18789`، یا `ws://localhost:18789` استفاده کنید؛ نام‌های میزبان دیگر مانند ترافیک عادی مبتنی بر نام میزبان مسیریابی می‌شوند.
- OpenClaw سیاست پراکسی شما را بازرسی، آزمایش، یا تأیید نمی‌کند.
- تغییرات سیاست پراکسی را به‌عنوان تغییرات عملیاتی حساس از نظر امنیتی در نظر بگیرید.
