---
read_when:
    - ไคลเอนต์พบ `rate limit exceeded for <method>`, `AUTH_RATE_LIMITED` หรือข้อผิดพลาดจากการถูกล็อกไม่ให้เข้าใช้งาน
    - คุณต้องการปรับแต่ง `gateway.auth.rateLimit`
    - คุณกำลังพิจารณาเกี่ยวกับการป้องกันการโจมตีแบบ brute-force บน Gateway ที่เปิดให้เข้าถึงจากภายนอก
    - คุณจำเป็นต้องทราบว่าพื้นที่ส่วนใดของ Gateway ถูกจำกัดอัตราการใช้งาน และจำกัดไว้ที่เท่าใด
summary: 'ข้อมูลอ้างอิงสำหรับขีดจำกัดอัตราของ Gateway ทั้งหมด: การล็อกก่อนการยืนยันตัวตน การจำกัดอัตราสำหรับเบราว์เซอร์และ Webhook มาตรการสำรองสำหรับการเขียนในระนาบควบคุม ขีดจำกัดเซสชัน ACP และช่วงรอก่อนเริ่มระบบใหม่'
title: การจำกัดอัตรา
x-i18n:
    generated_at: "2026-07-19T07:20:55Z"
    model: gpt-5.6
    postprocess_version: locale-links-v1
    prompt_version: 32
    provider: openai
    source_hash: 7aa37b65347610bedfb1db8f661e7ba75ef3cdfed0ba73c4ce53d80acace1e48
    source_path: gateway/security/rate-limiting.md
    workflow: 16
---

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

ภาพรวม:

| พื้นผิว                             | ขีดจำกัด (ค่าเริ่มต้น)                  | ใช้เป็นคีย์โดย                         | กำหนดค่าได้             |
| ----------------------------------- | -------------------------------- | -------------------------------- | ------------------------ |
| การยืนยันตัวตนล้มเหลว (โทเค็น/รหัสผ่าน/อุปกรณ์) | ล้มเหลว 10 ครั้ง / 60 วินาที, ล็อก 5 นาที | IP + ขอบเขตข้อมูลประจำตัว            | `gateway.auth.rateLimit` |
| การยืนยันตัวตน WS จากต้นทางเบราว์เซอร์ล้มเหลว     | เหมือนกัน, loopback **ไม่ได้รับการยกเว้น**    | IP หรือต้นทางหน้าเว็บจาก loopback | `gateway.auth.rateLimit` |
| การยืนยันตัวตน Webhook (`/hooks`) ล้มเหลว    | ล้มเหลว 20 ครั้ง / 60 วินาที, ล็อก 60 วินาที   | IP                               | ไม่                       |
| RPC เขียนของระนาบควบคุม            | 30 คำขอ / 60 วินาทีต่อเมธอด     | เมธอด + อุปกรณ์ + IP             | ไม่                       |
| การสร้างเซสชัน ACP                | 120 เซสชัน / 10 วินาที               | อินสแตนซ์ตัวแปล              | ภายใน                 |
| รอบการรีสตาร์ต Gateway              | คูลดาวน์ 30 วินาทีระหว่างการรีสตาร์ต    | โปรเซส                          | ไม่                       |

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

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

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

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

```json
{
  "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`:

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

รายการ `AUTH_RATE_LIMITED` ที่เกิดซ้ำในบันทึก Gateway หมายความว่ามีผู้กำลัง
เดาข้อมูลประจำตัว โปรดดู[คู่มือปฏิบัติการรับมือการเปิดเผย](/th/gateway/security/exposure-runbook)

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

การเชื่อมต่อ 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 จะไม่ใช้โควตาของการเขียนการกำหนดค่า

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

```json
{
  "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 ของไคลเอนต์ที่ผ่าน
  การจำแนกแล้ว โปรดดู[การยืนยันตัวตนผ่านพร็อกซีที่เชื่อถือ](/th/gateway/trusted-proxy-auth) เพื่อดูว่า
  ส่วนหัวของพร็อกซีได้รับการตรวจสอบอย่างไรก่อนที่จะมีผลต่อค่านี้
- การส่งสัญญาณให้ลองใหม่แตกต่างกันตามพื้นผิว: ตัวจำกัด RPC ของ Gateway ส่งคืน
  `retryable: true` พร้อม `retryAfterMs`, ทางเข้า Webhook ใช้ HTTP 429
  พร้อมส่วนหัว `Retry-After` และ ACP ฝังเวลารอไว้ในข้อความข้อผิดพลาด
  ในทุกกรณี ให้รอตามระยะเวลาที่ระบุแทนที่จะลองใหม่ทันที