พร็อกซีเครือข่าย

OpenClaw สามารถกำหนดเส้นทางทราฟฟิก HTTP และ WebSocket ขณะรันผ่าน forward proxy ที่ผู้ปฏิบัติงานจัดการได้ นี่เป็นการป้องกันเชิงลึกแบบเลือกใช้ได้สำหรับการปรับใช้ที่ต้องการควบคุม egress แบบรวมศูนย์ การป้องกัน SSRF ที่แข็งแรงขึ้น และการตรวจสอบเครือข่ายย้อนหลังได้ดีขึ้น

OpenClaw ไม่ได้จัดส่ง ดาวน์โหลด เริ่มต้น กำหนดค่า หรือรับรองพร็อกซี คุณเป็นผู้รันเทคโนโลยีพร็อกซีที่เหมาะกับสภาพแวดล้อมของคุณ และ OpenClaw จะกำหนดเส้นทางไคลเอนต์ HTTP และ WebSocket แบบ process-local ปกติผ่านพร็อกซีนั้น

เหตุผลที่ใช้พร็อกซี

พร็อกซีมอบจุดควบคุมเครือข่ายเดียวให้ผู้ปฏิบัติงานสำหรับทราฟฟิก HTTP และ WebSocket ขาออก ซึ่งอาจมีประโยชน์แม้นอกเหนือจากการเสริมความแข็งแรงต่อ SSRF:

• นโยบายแบบรวมศูนย์: ดูแลนโยบาย egress เพียงชุดเดียว แทนการพึ่งให้ทุกจุดเรียก HTTP ของแอปพลิเคชันตั้งกฎเครือข่ายให้ถูกต้อง
• การตรวจสอบขณะเชื่อมต่อ: ประเมินปลายทางหลังการ resolve DNS และทันทีก่อนที่พร็อกซีจะเปิดการเชื่อมต่อต้นทาง
• การป้องกัน DNS rebinding: ลดช่องว่างระหว่างการตรวจสอบ DNS ระดับแอปพลิเคชันกับการเชื่อมต่อขาออกจริง
• การครอบคลุม JavaScript ที่กว้างขึ้น: กำหนดเส้นทาง fetch, node:http, node:https, WebSocket, axios, got, node-fetch และไคลเอนต์ที่คล้ายกันผ่านเส้นทางเดียวกัน
• ความสามารถในการตรวจสอบย้อนหลัง: บันทึกปลายทางที่อนุญาตและปฏิเสธที่ขอบเขต egress
• การควบคุมเชิงปฏิบัติการ: บังคับใช้กฎปลายทาง การแบ่งส่วนเครือข่าย rate limit หรือ allowlist ขาออก โดยไม่ต้องสร้าง OpenClaw ใหม่

การกำหนดเส้นทางพร็อกซีเป็น guardrail ระดับโปรเซสสำหรับ egress HTTP และ WebSocket ปกติ โดยให้เส้นทาง fail-closed แก่ผู้ปฏิบัติงานสำหรับกำหนดเส้นทางไคลเอนต์ HTTP ของ JavaScript ที่รองรับผ่านพร็อกซีกรองของตนเอง แต่ไม่ใช่แซนด์บ็อกซ์เครือข่ายระดับ OS และไม่ได้ทำให้ OpenClaw รับรองนโยบายปลายทางของพร็อกซี

วิธีที่ OpenClaw กำหนดเส้นทางทราฟฟิก

เมื่อกำหนดค่า proxy.enabled=true และตั้งค่า URL พร็อกซีแล้ว โปรเซสรันไทม์ที่ได้รับการป้องกัน เช่น openclaw gateway run, openclaw node run และ openclaw agent --local จะกำหนดเส้นทาง egress HTTP และ WebSocket ปกติผ่านพร็อกซีที่กำหนดค่าไว้:

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 ฝั่ง control-plane ของ OpenClaw Gateway ใช้เส้นทางตรงแบบแคบสำหรับทราฟฟิก RPC ของ Gateway แบบ local loopback เมื่อ URL ของ Gateway ใช้ localhost หรือ IP loopback แบบ literal เช่น 127.0.0.1 หรือ [::1] เส้นทาง control-plane นั้นต้องสามารถเข้าถึง Gateway แบบ loopback ได้ แม้พร็อกซีของผู้ปฏิบัติงานจะบล็อกปลายทาง loopback คำขอ HTTP และ WebSocket ขณะรันตามปกติยังคงใช้พร็อกซีที่กำหนดค่าไว้

ภายใน OpenClaw ติดตั้ง Proxyline เป็นรันไทม์กำหนดเส้นทางระดับโปรเซสสำหรับฟีเจอร์นี้ Proxyline ครอบคลุม fetch, ไคลเอนต์ที่รองรับโดย undici, ผู้เรียก Node core node:http / node:https, ไคลเอนต์ WebSocket ทั่วไป และอุโมงค์ CONNECT ที่สร้างโดยตัวช่วย โหมดพร็อกซีที่จัดการจะแทนที่ Node HTTP agent ที่ผู้เรียกจัดเตรียมไว้ เพื่อไม่ให้ agent ที่ระบุอย่างชัดเจนข้ามพร็อกซีของผู้ปฏิบัติงานโดยไม่ตั้งใจ

Plugin บางตัวเป็นเจ้าของ transport แบบกำหนดเองที่ต้องต่อสายพร็อกซีอย่างชัดเจน แม้จะมีการกำหนดเส้นทางระดับโปรเซสอยู่แล้ว ตัวอย่างเช่น transport ของ Bot API ของ Telegram ใช้ HTTP/1 undici dispatcher ของตัวเอง จึงเคารพ env พร็อกซีของโปรเซส รวมถึง fallback OPENCLAW_PROXY_URL ที่จัดการแล้วในเส้นทาง transport เฉพาะเจ้าของนั้น

URL ของพร็อกซีเองสามารถใช้ได้ทั้ง http:// หรือ https:// scheme เหล่านี้อธิบายการเชื่อมต่อจาก OpenClaw ไปยังปลายทางพร็อกซี:

• http://proxy.example:3128: OpenClaw เปิดการเชื่อมต่อ TCP แบบไม่เข้ารหัสไปยัง forward proxy และส่งคำขอพร็อกซี HTTP รวมถึง CONNECT สำหรับปลายทาง HTTPS
• https://proxy.example:8443: OpenClaw เปิด TLS ไปยังปลายทางพร็อกซี ตรวจสอบใบรับรองพร็อกซี แล้วส่งคำขอพร็อกซี HTTP ภายในเซสชัน TLS นั้น

HTTPS ของปลายทางแยกจาก TLS ของปลายทางพร็อกซี สำหรับปลายทาง HTTPS OpenClaw ยังคงขออุโมงค์ HTTP CONNECT จากพร็อกซี แล้วเริ่ม TLS ของปลายทางผ่านอุโมงค์นั้น

ขณะที่พร็อกซีทำงาน OpenClaw จะล้าง no_proxy และ NO_PROXY รายการ bypass เหล่านั้นอิงตามปลายทาง ดังนั้นหากปล่อย localhost หรือ 127.0.0.1 ไว้ในนั้น เป้าหมาย SSRF ความเสี่ยงสูงจะสามารถข้ามพร็อกซีกรองได้

เมื่อปิดการทำงาน OpenClaw จะกู้คืนสภาพแวดล้อมพร็อกซีก่อนหน้าและรีเซ็ตสถานะการกำหนดเส้นทางโปรเซสที่แคชไว้

คำที่เกี่ยวข้องกับพร็อกซี

• proxy.enabled / proxy.proxyUrl: การกำหนดเส้นทาง forward-proxy ขาออกสำหรับ egress ของรันไทม์ OpenClaw หน้านี้อธิบายฟีเจอร์นั้น
• gateway.auth.mode: "trusted-proxy": การตรวจสอบสิทธิ์ reverse-proxy ขาเข้าที่รับรู้ตัวตนสำหรับการเข้าถึง Gateway ดู การตรวจสอบสิทธิ์พร็อกซีที่เชื่อถือได้
• openclaw proxy: พร็อกซีดีบักภายในเครื่องและตัวตรวจสอบการจับข้อมูลสำหรับการพัฒนาและการสนับสนุน ดู openclaw proxy
• tools.web.fetch.useTrustedEnvProxy: การเลือกใช้สำหรับ web_fetch เพื่อให้พร็อกซี env HTTP(S) ที่ผู้ปฏิบัติงานควบคุม resolve DNS ได้ ขณะยังคงการ pin DNS และนโยบายชื่อโฮสต์ที่เข้มงวดตามค่าเริ่มต้น ดู การดึงข้อมูลเว็บ
• การตั้งค่าพร็อกซีเฉพาะ channel หรือ provider: override เฉพาะเจ้าของสำหรับ transport หนึ่งรายการ ควรใช้พร็อกซีเครือข่ายที่จัดการแล้วเมื่อเป้าหมายคือการควบคุม egress แบบรวมศูนย์ทั่วทั้งรันไทม์

การกำหนดค่า

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

สำหรับปลายทางพร็อกซี HTTPS ที่มี CA พร็อกซีส่วนตัว:

proxy:  enabled: true  proxyUrl: https://proxy.corp.example:8443  tls:    caFile: /etc/openclaw/proxy-ca.pem

คุณยังสามารถระบุ URL ผ่านสภาพแวดล้อมได้ ขณะคง proxy.enabled=true ไว้ใน config:

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

proxy.proxyUrl มีลำดับความสำคัญเหนือ OPENCLAW_PROXY_URL

โหมด Loopback ของ Gateway

ไคลเอนต์ control-plane ของ Gateway ภายในเครื่องมักเชื่อมต่อไปยัง WebSocket แบบ loopback เช่น ws://127.0.0.1:18789 ใช้ proxy.loopbackMode เพื่อเลือกวิธีที่ข้อยกเว้น managed-proxy สำหรับ loopback ทำงานขณะที่พร็อกซีที่จัดการอยู่ทำงาน:

proxy:  enabled: true  proxyUrl: http://127.0.0.1:3128  loopbackMode: gateway-only # gateway-only, proxy, or block

• gateway-only (ค่าเริ่มต้น): OpenClaw ลงทะเบียน authority แบบ loopback ของ Gateway ในนโยบาย bypass ที่จัดการของ Proxyline เพื่อให้ทราฟฟิก WebSocket ของ Gateway ภายในเครื่องเชื่อมต่อโดยตรงได้ พอร์ต Gateway แบบ loopback ที่กำหนดเองทำงานได้ เพราะมีการลงทะเบียน host และ port ของ URL Gateway ที่ใช้งานอยู่ Plugin เบราว์เซอร์ที่ bundled มายังสามารถลงทะเบียนปลายทางความพร้อม CDP ภายในเครื่องและ WebSocket ของ DevTools ที่แน่นอนสำหรับเบราว์เซอร์ที่ OpenClaw เปิดแบบจัดการ และ provider สำหรับ memory embedding ของ Ollama ที่ bundled มาสามารถใช้เส้นทางตรงที่มี guard แคบกว่าของตัวเองสำหรับ origin embedding แบบ host-local loopback ที่กำหนดค่าไว้แน่นอน
• proxy: OpenClaw ไม่ลงทะเบียน bypass loopback ของ Gateway หรือ Ollama ดังนั้นทราฟฟิก loopback นั้นจะถูกส่งผ่านพร็อกซีที่จัดการ หากพร็อกซีอยู่ระยะไกล พร็อกซีต้องมีการกำหนดเส้นทางพิเศษไปยังบริการ loopback ของโฮสต์ OpenClaw เช่น การแมปไปยังชื่อโฮสต์ IP หรืออุโมงค์ที่พร็อกซีเข้าถึงได้ พร็อกซีระยะไกลมาตรฐานจะ resolve 127.0.0.1 และ localhost จากโฮสต์พร็อกซี ไม่ใช่จากโฮสต์ OpenClaw
• block: OpenClaw ปฏิเสธการเชื่อมต่อ control-plane แบบ loopback ของ Gateway และการเชื่อมต่อ embedding แบบ host-local loopback ของ Ollama ที่มี guard ก่อนเปิด socket

หาก enabled=true แต่ไม่มี URL พร็อกซีที่ถูกต้องกำหนดไว้ คำสั่งที่ได้รับการป้องกันจะเริ่มต้นล้มเหลว แทนที่จะ fallback ไปใช้การเข้าถึงเครือข่ายโดยตรง

สำหรับบริการ Gateway ที่จัดการและเริ่มด้วย openclaw gateway start ควรเก็บ URL ไว้ใน config:

openclaw config set proxy.enabled trueopenclaw config set proxy.proxyUrl http://127.0.0.1:3128openclaw gateway install --forceopenclaw gateway start

fallback ผ่านสภาพแวดล้อมเหมาะที่สุดสำหรับการรันแบบ foreground หากคุณใช้กับบริการที่ติดตั้งแล้ว ให้ใส่ 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 สำหรับคำสั่งที่กำหนดเป้าหมายคอนเทนเนอร์ เว้นแต่คุณจะ override การตรวจสอบความปลอดภัยนั้นอย่างชัดเจน

ข้อกำหนดของพร็อกซี

นโยบายพร็อกซีคือขอบเขตความปลอดภัย OpenClaw ไม่สามารถตรวจสอบได้ว่าพร็อกซีบล็อกเป้าหมายที่ถูกต้องหรือไม่

กำหนดค่าพร็อกซีให้:

• bind เฉพาะกับ loopback หรืออินเทอร์เฟซส่วนตัวที่เชื่อถือได้
• จำกัดการเข้าถึงเพื่อให้เฉพาะโปรเซส โฮสต์ คอนเทนเนอร์ หรือ service account ของ OpenClaw ใช้งานได้
• resolve ปลายทางด้วยตัวเองและบล็อก IP ปลายทางหลังการ resolve DNS
• ใช้นโยบายขณะเชื่อมต่อสำหรับทั้งคำขอ HTTP แบบไม่เข้ารหัสและอุโมงค์ HTTPS CONNECT
• ปฏิเสธ bypass ที่อิงตามปลายทางสำหรับ loopback, private, link-local, metadata, multicast, reserved หรือช่วง documentation
• หลีกเลี่ยง allowlist ชื่อโฮสต์ เว้นแต่คุณเชื่อถือเส้นทางการ resolve DNS อย่างเต็มที่
• บันทึกปลายทาง การตัดสินใจ สถานะ และเหตุผล โดยไม่บันทึก body ของคำขอ header การอนุญาต cookie หรือความลับอื่น
• เก็บนโยบายพร็อกซีไว้ภายใต้ version control และ review การเปลี่ยนแปลงเหมือน config ที่อ่อนไหวด้านความปลอดภัย

ปลายทางที่แนะนำให้บล็อก

ใช้ denylist นี้เป็นจุดเริ่มต้นสำหรับ forward proxy, firewall หรือนโยบาย egress ใดๆ

ตรรกะ classifier ระดับแอปพลิเคชันของ OpenClaw อยู่ใน src/infra/net/ssrf.ts และ packages/net-policy/src/ip.ts ฮุก parity ที่เกี่ยวข้องคือ BLOCKED_HOSTNAMES, BLOCKED_IPV4_SPECIAL_USE_RANGES, BLOCKED_IPV6_SPECIAL_USE_RANGES, RFC2544_BENCHMARK_PREFIX และการจัดการ IPv4 sentinel แบบฝังสำหรับรูปแบบ NAT64, 6to4, Teredo, ISATAP และ IPv4-mapped ไฟล์เหล่านั้นเป็นอ้างอิงที่มีประโยชน์เมื่อต้องดูแลนโยบายพร็อกซีภายนอก แต่ OpenClaw ไม่ได้ export หรือบังคับใช้กฎเหล่านั้นในพร็อกซีของคุณโดยอัตโนมัติ

หากผู้ให้บริการคลาวด์หรือแพลตฟอร์มเครือข่ายของคุณมีเอกสารระบุโฮสต์ข้อมูลเมตาหรือช่วงที่สงวนไว้เพิ่มเติม ให้เพิ่มรายการเหล่านั้นด้วย

การตรวจสอบความถูกต้อง

ตรวจสอบพร็อกซีจากโฮสต์ คอนเทนเนอร์ หรือบัญชีบริการเดียวกับที่รัน OpenClaw:

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

สำหรับปลายทางพร็อกซี HTTPS ที่ลงนามโดย CA ส่วนตัว:

openclaw proxy validate --proxy-url https://proxy.corp.example:8443 --proxy-ca-file /etc/openclaw/proxy-ca.pem

ตามค่าเริ่มต้น เมื่อไม่ได้ระบุปลายทางแบบกำหนดเอง คำสั่งจะตรวจสอบว่า https://example.com/ สำเร็จ และเริ่ม canary แบบ loopback ชั่วคราวที่พร็อกซีต้องเข้าถึงไม่ได้ การตรวจสอบการปฏิเสธตามค่าเริ่มต้นจะผ่านเมื่อพร็อกซีส่งคืนการตอบกลับปฏิเสธที่ไม่ใช่ 2xx หรือบล็อก canary ด้วยความล้มเหลวของทรานสปอร์ต และจะล้มเหลวหากการตอบกลับที่สำเร็จไปถึง canary หากไม่ได้เปิดใช้และกำหนดค่าพร็อกซี การตรวจสอบจะรายงานปัญหาการกำหนดค่า ใช้ --proxy-url สำหรับการตรวจสอบล่วงหน้าแบบครั้งเดียวก่อนเปลี่ยนการกำหนดค่า ใช้ --allowed-url และ --denied-url เพื่อทดสอบความคาดหวังเฉพาะการปรับใช้ เพิ่ม --apns-reachable เพื่อยืนยันเพิ่มเติมว่าการส่ง APNs HTTP/2 โดยตรงสามารถเปิดอุโมงค์ CONNECT ผ่านพร็อกซีและรับการตอบกลับ sandbox APNs ได้ โพรบใช้โทเค็นผู้ให้บริการที่ไม่ถูกต้องโดยเจตนา ดังนั้น 403 InvalidProviderToken จึงเป็นสิ่งที่คาดไว้และนับว่าเข้าถึงได้ ปลายทางที่ถูกปฏิเสธแบบกำหนดเองเป็นแบบ fail-closed: การตอบกลับ HTTP ใดๆ หมายความว่าปลายทางเข้าถึงได้ผ่านพร็อกซี และข้อผิดพลาดทรานสปอร์ตใดๆ จะถูกรายงานว่าไม่สามารถสรุปได้ เพราะ OpenClaw ไม่สามารถพิสูจน์ได้ว่าพร็อกซีบล็อก origin ที่เข้าถึงได้ เมื่อการตรวจสอบล้มเหลว คำสั่งจะออกด้วยรหัส 1

ใช้ --json สำหรับระบบอัตโนมัติ เอาต์พุต JSON ประกอบด้วยผลลัพธ์โดยรวม แหล่งที่มาของการกำหนดค่าพร็อกซีที่มีผล ข้อผิดพลาดการกำหนดค่าใดๆ และการตรวจสอบปลายทางแต่ละรายการ ข้อมูลประจำตัวใน 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 -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 canary แบบ loopback ในตัวสามารถแยกแยะการปฏิเสธจากพร็อกซีกับ origin ที่เข้าถึงได้ การตรวจสอบ --denied-url แบบกำหนดเองไม่มี canary นั้น ดังนั้นให้ถือทั้งการตอบกลับ HTTP และความล้มเหลวของทรานสปอร์ตที่คลุมเครือเป็นความล้มเหลวในการตรวจสอบ เว้นแต่พร็อกซีของคุณจะเปิดเผยสัญญาณการปฏิเสธเฉพาะการปรับใช้ที่คุณสามารถยืนยันแยกต่างหากได้

ความเชื่อถือ CA ของพร็อกซี

ใช้ proxy.tls.caFile ที่จัดการแล้วเมื่อปลายทางพร็อกซีเองใช้ใบรับรองที่ลงนามโดย CA ส่วนตัว:

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:

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  proxyUrl: https://proxy.corp.example:8443  tls:    caFile: /etc/openclaw/proxy-ca.pem

ข้อจำกัด

• พร็อกซีช่วยเพิ่มความครอบคลุมสำหรับไคลเอ็นต์ HTTP และ WebSocket ของ JavaScript ภายในกระบวนการ แต่ไม่ใช่ sandbox เครือข่ายระดับ OS
• ทราฟฟิก control-plane ของ Gateway แบบ loopback จะใช้ค่าเริ่มต้นเป็นการเลี่ยงผ่านภายในเครื่องโดยตรงผ่าน proxy.loopbackMode: "gateway-only" OpenClaw ใช้การเลี่ยงผ่านนั้นโดยลงทะเบียน authority ของ Gateway loopback ที่ใช้งานอยู่ในนโยบายการเลี่ยงผ่านที่จัดการโดย Proxyline ผู้ปฏิบัติงานสามารถตั้งค่า proxy.loopbackMode: "proxy" เพื่อส่งทราฟฟิก Gateway loopback ผ่านพร็อกซีที่จัดการแล้ว หรือ proxy.loopbackMode: "block" เพื่อปฏิเสธการเชื่อมต่อ Gateway แบบ loopback ดู โหมด Gateway Loopback สำหรับข้อควรระวังของพร็อกซีระยะไกล
• ซ็อกเก็ต net, tls และ http2 แบบดิบ ส่วนเสริม native และกระบวนการลูกที่ไม่ใช่ OpenClaw อาจเลี่ยงการกำหนดเส้นทางพร็อกซีระดับ Node ได้ เว้นแต่จะสืบทอดและเคารพตัวแปรสภาพแวดล้อมพร็อกซี CLI ลูกของ OpenClaw ที่ fork จะสืบทอด URL พร็อกซีที่จัดการแล้วและสถานะ proxy.loopbackMode
• IRC เป็นช่องทาง TCP/TLS แบบดิบที่อยู่นอกการกำหนดเส้นทางพร็อกซีส่งต่อที่ผู้ปฏิบัติงานจัดการ ในการปรับใช้ที่กำหนดให้ egress ทั้งหมดต้องผ่านพร็อกซีส่งต่อนั้น ให้ตั้งค่า channels.irc.enabled=false เว้นแต่ egress ของ IRC โดยตรงจะได้รับการอนุมัติอย่างชัดเจน
• พร็อกซีดีบักภายในเครื่องเป็นเครื่องมือวินิจฉัย และการส่งต่อ upstream โดยตรงสำหรับคำขอพร็อกซีและอุโมงค์ CONNECT จะถูกปิดตามค่าเริ่มต้นขณะที่โหมดพร็อกซีที่จัดการแล้วทำงานอยู่ เปิดใช้การส่งต่อโดยตรงเฉพาะสำหรับการวินิจฉัยภายในเครื่องที่ได้รับอนุมัติเท่านั้น
• WebUI ภายในเครื่องของผู้ใช้และเซิร์ฟเวอร์โมเดลภายในเครื่องควรถูกใส่ใน allowlist ในนโยบายพร็อกซีของผู้ปฏิบัติงานเมื่อจำเป็น OpenClaw ไม่เปิดเผยการเลี่ยงผ่านเครือข่ายภายในเครื่องแบบทั่วไปสำหรับสิ่งเหล่านั้น ผู้ให้บริการ embedding หน่วยความจำ Ollama ที่บันเดิลมามีขอบเขตแคบกว่า: สามารถใช้เส้นทางโดยตรงที่มีการป้องกันเฉพาะสำหรับ origin ของ embedding แบบ loopback บนโฮสต์ที่ได้จาก baseUrl ที่กำหนดค่าไว้เท่านั้น เพื่อให้ embedding บนโฮสต์ภายในยังทำงานได้เมื่อพร็อกซีที่จัดการแล้วเข้าถึง host loopback ไม่ได้ โฮสต์ embedding Ollama บน LAN, tailnet, เครือข่ายส่วนตัว และสาธารณะยังคงใช้เส้นทางพร็อกซีที่จัดการแล้ว proxy.loopbackMode: "proxy" จะส่งทราฟฟิก Ollama loopback นี้ผ่านพร็อกซีที่จัดการแล้ว และ proxy.loopbackMode: "block" จะปฏิเสธก่อนเปิดการเชื่อมต่อ
• การเลี่ยงผ่านพร็อกซี control-plane ของ Gateway ถูกจำกัดโดยเจตนาไว้ที่ localhost และ URL ที่เป็น IP loopback แบบ literal ใช้ ws://127.0.0.1:18789, ws://[::1]:18789 หรือ ws://localhost:18789 สำหรับการเชื่อมต่อ control-plane ของ Gateway ภายในเครื่องโดยตรง ชื่อโฮสต์อื่นๆ จะถูกกำหนดเส้นทางเหมือนทราฟฟิกแบบใช้ชื่อโฮสต์ทั่วไป
• OpenClaw ไม่ตรวจสอบ ทดสอบ หรือรับรองนโยบายพร็อกซีของคุณ
• ให้ถือการเปลี่ยนแปลงนโยบายพร็อกซีเป็นการเปลี่ยนแปลงการปฏิบัติงานที่อ่อนไหวด้านความปลอดภัย