การจำกัดอัตรา

Gateway บังคับใช้ขีดจำกัดอัตราหลายรายการที่แยกจากกัน โดยแต่ละรายการปกป้อง ขอบเขตที่ต่างกัน ใช้อัตลักษณ์ที่ต่างกันเป็นคีย์ และล้มเหลวด้วยรูปแบบข้อผิดพลาดที่ต่างกัน หน้านี้เป็นข้อมูลอ้างอิงสำหรับขีดจำกัดทั้งหมด

ภาพรวม:

ความพยายามยืนยันตัวตน (ก่อนยืนยันตัวตน)

ความพยายามยืนยันตัวตนที่ล้มเหลวจะถูกจำกัดอัตราตาม IP ของไคลเอนต์ ก่อนเริ่ม การจัดการคำขอใดๆ นี่คือกลไกป้องกันการโจมตีแบบ brute force สำหรับ Gateway ที่เปิดเผยต่อภายนอก

• นับเฉพาะข้อมูลประจำตัวที่ ไม่ถูกต้อง ข้อมูลประจำตัวที่ขาดหายไป (ไคลเอนต์ที่ไม่เคย ส่งโทเค็น) และการยืนยันตัวตนที่สำเร็จจะไม่ใช้โควตา โดยการยืนยันตัวตน ที่สำเร็จจะรีเซ็ตตัวนับสำหรับ IP นั้น
• ค่าเริ่มต้น: ล้มเหลว 10 ครั้งต่อ 60 วินาที จากนั้นล็อก IP นั้นเป็นเวลา 5 นาที
• Loopback (127.0.0.1 / ::1) ได้รับการยกเว้นโดยค่าเริ่มต้น เพื่อไม่ให้เซสชัน CLI ภายใน ถูกล็อก
• ตัวนับถูกกำหนดขอบเขตแยกตามคลาสข้อมูลประจำตัว ดังนั้นการระดมคำขอใส่พื้นผิวหนึ่ง จะไม่เบียดเบียนอีกพื้นผิวหนึ่ง ขอบเขตประกอบด้วยโทเค็น/รหัสผ่านที่ใช้ร่วมกันของ Gateway, โทเค็นอุปกรณ์, การจับคู่ Node, การอนุมัติ Node ที่จับคู่แล้วอีกครั้ง, โทเค็นบูตสแตรปอุปกรณ์ และการออกคำท้าสำหรับ watchOS

ขณะถูกล็อก ความพยายามเชื่อมต่อจะล้มเหลวด้วย:

{  "code": "INVALID_REQUEST",  "message": "unauthorized: too many failed authentication attempts (retry later)",  "retryable": true,  "retryAfterMs": 297000,  "details": {    "code": "AUTH_RATE_LIMITED",    "authReason": "rate_limited",    "recommendedNextStep": "wait_then_retry"  }}

ความพยายามจาก IP อื่น (รวมถึง loopback) จะไม่ได้รับผลกระทบระหว่างการล็อก

ปรับแต่งได้ภายใต้ gateway.auth.rateLimit ใน openclaw.json:

{  "gateway": {    "auth": {      "rateLimit": {        "maxAttempts": 10,        "windowMs": 60000,        "lockoutMs": 300000,        "exemptLoopback": true      }    }  }}

รายการ AUTH_RATE_LIMITED ที่เกิดซ้ำในบันทึก Gateway หมายความว่ามีผู้กำลัง เดาข้อมูลประจำตัว โปรดดูคู่มือปฏิบัติการรับมือการเปิดเผย

การเชื่อมต่อจากต้นทางเบราว์เซอร์

การเชื่อมต่อ WebSocket ที่มีส่วนหัว Origin ของเบราว์เซอร์จะใช้ ขีดจำกัดเดียวกัน แต่การยกเว้น loopback จะ ปิดอยู่เสมอ — หน้าเว็บประสงค์ร้ายใน เบราว์เซอร์ภายในยังคงเป็นไคลเอนต์ที่ไม่น่าเชื่อถือ ดังนั้น localhost จึงไม่ได้รับการยกเว้น บนเส้นทางนี้ เมื่อการเชื่อมต่อดังกล่าวมาถึง จาก ที่อยู่ loopback การล้มเหลวจะใช้ ต้นทางหน้าเว็บที่ปรับให้อยู่ในรูปแบบมาตรฐาน (ตัวอย่างเช่น browser-origin:https://evil.example) เป็นคีย์ แทน IP loopback ที่ใช้ร่วมกัน เพื่อให้แต่ละต้นทางมีบักเก็ตของตนเอง ส่วนการเชื่อมต่อจากที่อยู่ที่ไม่ใช่ loopback จะยังคงใช้ IP ของไคลเอนต์เป็นคีย์ ไม่สามารถกำหนดค่านี้ได้

Webhook

ทางเข้า HTTP /hooks มีตัวจำกัดการล้มเหลวของตนเอง: การยืนยันตัวตน ล้มเหลว 20 ครั้งต่อ 60 วินาทีต่อ IP ของไคลเอนต์ จากนั้นล็อก 60 วินาที Loopback ไม่ได้รับการยกเว้น การยืนยันตัวตนของ hook ที่สำเร็จจะรีเซ็ตตัวนับ คำขอ ที่ถูกจำกัดอัตราจะได้รับ HTTP 429 Too Many Requests แบบข้อความล้วน พร้อมส่วนหัว Retry-After (วินาที) ขีดจำกัดเป็นค่าคงที่ หากการเชื่อมต่อระบบที่ถูกต้อง ชนขีดจำกัดนี้ ให้แก้ไขข้อมูลประจำตัวแทนที่จะพยายามซ้ำถี่ขึ้น

การเขียนของระนาบควบคุม (กลไกสำรองหลังยืนยันตัวตน)

RPC ฝั่งเขียนสำหรับผู้ดูแล (config.apply, config.patch, plugins.install, plugins.setEnabled, plugins.uninstall, update.run, worktrees.*, gateway.restart.request, ...) จะถูกจำกัดอัตราเพิ่มเติม หลังจาก การอนุญาต: 30 คำขอต่อ 60 วินาที ต่อเมธอด ต่อ deviceId+clientIp

นี่ไม่ใช่ขอบเขตความปลอดภัย — ผู้เรียกมี operator.admin อยู่แล้ว — แต่เป็น กลไกสำรองที่จำกัดลูปของไคลเอนต์หรือเอเจนต์ที่ทำงานผิดปกติและระดมเรียก การดำเนินการที่มีต้นทุนสูง การใช้งานแบบโต้ตอบจะไม่ชนขีดจำกัดนี้ แต่ละเมธอดมี บักเก็ตของตนเอง ดังนั้นการสลับเปิดปิด Plugin จะไม่ใช้โควตาของการเขียนการกำหนดค่า

เมื่อเกินขีดจำกัด คำขอจะล้มเหลวด้วยข้อผิดพลาดที่ลองใหม่ได้:

{  "code": "UNAVAILABLE",  "message": "rate limit exceeded for config.patch; retry after 35s",  "retryable": true,  "retryAfterMs": 34539,  "details": { "method": "config.patch", "limit": "30 per 60s" }}

ไคลเอนต์ควรปฏิบัติตาม retryAfterMs ขีดจำกัดเป็นค่าคงที่ (กำหนดค่าไม่ได้) บักเก็ตจะหมดอายุเองและถูกล้างโดยงานบำรุงรักษาของ Gateway

การสร้างเซสชัน ACP

ตัวแปล ACP จำกัดการสร้างเซสชันไว้ที่ 120 เซสชันใหม่ต่อกรอบเวลา 10 วินาที ต่ออินสแตนซ์ตัวแปล เมื่อเกินขีดจำกัด คำขอจะล้มเหลวด้วยข้อผิดพลาด ที่ข้อความระบุเวลารอ (เส้นทางนี้ไม่มีฟิลด์ retryAfterMs แบบมีโครงสร้าง):

เกินขีดจำกัดอัตราการสร้างเซสชัน ACP สำหรับ <method>; ลองอีกครั้งหลังจาก <n> วินาที

ขีดจำกัดนี้ควบคุมไคลเอนต์ที่ทำงานผิดปกติและสร้างเซสชันวนซ้ำ การใช้งาน IDE และ เอเจนต์ตามปกติจะต่ำกว่าขีดจำกัดนี้มาก

คูลดาวน์การรีสตาร์ต

คำขอรีสตาร์ต Gateway จะถูกรวมเข้าด้วยกัน จากนั้นบังคับใช้คูลดาวน์ 30 วินาที ระหว่างรอบการรีสตาร์ต คำขอรีสตาร์ตที่เกิดขึ้นระหว่างคูลดาวน์จะถูกกำหนดเวลา ให้ทำงานหลังคูลดาวน์สิ้นสุดแทนที่จะถูกปฏิเสธ กลไกนี้แยกจากตัวจำกัดระนาบควบคุม ข้างต้น: gateway.restart.request ใช้ช่องโควตาของระนาบควบคุม และ การรีสตาร์ตที่เกิดขึ้นต้องปฏิบัติตามคูลดาวน์

หมายเหตุด้านการปฏิบัติการ

• ตัวจำกัดทั้งหมดอยู่ในหน่วยความจำและแยกตามโปรเซส และ Gateway หลายตัวจะไม่ ใช้สถานะร่วมกัน การแทนที่โปรเซส Gateway จะล้างตัวนับที่ Gateway เป็นเจ้าของ (การล็อกการยืนยันตัวตน, การจำกัด Webhook, บักเก็ตระนาบควบคุม) คูลดาวน์ การรีสตาร์ตตั้งใจให้คงอยู่ตลอดรอบการรีสตาร์ตภายในโปรเซส — เพราะนั่นคือ สิ่งที่กลไกนี้จำกัด — และจะรีเซ็ตเมื่อเปลี่ยนโปรเซสเท่านั้น ขีดจำกัดเซสชัน ACP เป็นของอินสแตนซ์ตัวแปลและจะรีเซ็ตเมื่อสร้างอินสแตนซ์นั้นใหม่ ไม่ใช่เมื่อรีสตาร์ต Gateway
• แมปบักเก็ตมีขอบเขตจำกัด (มีทั้งขีดจำกัดจำนวนรายการแบบตายตัวและการล้างเป็นระยะ) ดังนั้นการระดมคีย์ที่ไม่ซ้ำกันจึงไม่สามารถทำให้หน่วยความจำเติบโตอย่างไร้ขอบเขต
• เมื่อไคลเอนต์อยู่หลัง reverse proxy ค่า IP ที่มีผลคือ IP ของไคลเอนต์ที่ผ่าน การจำแนกแล้ว โปรดดูการยืนยันตัวตนผ่านพร็อกซีที่เชื่อถือ เพื่อดูว่า ส่วนหัวของพร็อกซีได้รับการตรวจสอบอย่างไรก่อนที่จะมีผลต่อค่านี้
• การส่งสัญญาณให้ลองใหม่แตกต่างกันตามพื้นผิว: ตัวจำกัด RPC ของ Gateway ส่งคืน retryable: true พร้อม retryAfterMs, ทางเข้า Webhook ใช้ HTTP 429 พร้อมส่วนหัว Retry-After และ ACP ฝังเวลารอไว้ในข้อความข้อผิดพลาด ในทุกกรณี ให้รอตามระยะเวลาที่ระบุแทนที่จะลองใหม่ทันที