# 429 Too Many Requests เมื่อสแครป: ความหมายและวิธีแก้ปัญหา

> ความหมายของ HTTP 429 Too Many Requests สำหรับตัวสแครป, วิธีอ่าน Retry-After และโค้ด Python สำหรับ backoff พร้อม jitter ชะลอความเร็ว; อย่าหลีกเลี่ยง

- URL: https://crawlrelay.com/th/docs/errors/429-too-many-requests/
- อัปเดตล่าสุด: 2026-10-13
- Publisher: CrawlRelay (https://crawlrelay.com)

รหัสสถานะ HTTP (4xx, ข้อผิดพลาดของไคลเอนต์): ข้อความผิดพลาดที่แม่นยำในแต่ละเครื่องมือ สาเหตุที่เป็นไปได้ตามลำดับ และวิธีแก้ไขที่ใช้งานได้

**คำตอบด่วน — 429 Too Many Requests หมายความว่าอย่างไรกับพร็อกซี?**

**429 Too Many Requests** หมายความว่าเว็บไซต์กำลังจำกัดอัตราการส่งคำขอ: คุณส่งคำขอเกินที่ยอมรับในช่วงเวลาหนึ่ง การแก้ไขคือส่งคำขอน้อยลง ไม่ใช่ซ่อนมากขึ้น ด้วยพร็อกซี residential ของ CrawlRelay ให้เคารพ header `Retry-After` จำกัดความขนานต่อโฮสต์ และหน่วงเวลาลงแบบ exponential พร้อม jitter แบบสุ่ม การหมุน IP เพื่อเกินขีดจำกัดที่ไซต์ประกาศถือว่าเป็นการละเมิดข้อกำหนดการใช้งานส่วนใหญ่

## 429 Too Many Requests แบบสั้นๆ

| คุณลักษณะ | ค่า |
| --- | --- |
| ข้อผิดพลาด | 429 Too Many Requests |
| ประเภท | รหัสสถานะ HTTP (4xx, ข้อผิดพลาดของไคลเอนต์) |
| ส่งโดย | เว็บไซต์เป้าหมายหรือเกตเวย์ API ของมัน |
| กำหนดไว้ใน | RFC 6585, section 4 (Retry-After: RFC 9110, section 10.2.3) |
| ลองใหม่อีกครั้งไหม? | ใช่ หลังจากดีเลย์ Retry-After หรือการหน่วงแบบ exponential backoff |
| ตรวจสอบก่อน | อ่าน header Retry-After และอัตราคำขอต่อวินาทีต่อโฮสต์ของคุณ |

## 429 Too Many Requests หมายความว่าอย่างไร?

RFC 6585 แนะนำ 429 สำหรับการจำกัดอัตรา เซิร์ฟเวอร์อาจเพิ่ม header `Retry-After` ซึ่งเป็นจำนวนวินาทีหรือวันที่ HTTP เพื่อบอกเวลาที่ควรกลับมา APIs มักมี header ของตัวเอง เช่น `X-RateLimit-Remaining`

429 เป็นคำตอบที่สุภาพที่สุดที่ไซต์ตอบกลับตัวสแครป มันบอกว่าคอนเทนต์พร้อมใช้งาน เพียงแต่ไม่ใช่ที่ความเร็วปัจจุบัน ไซต์ที่เห็น 429 ถูกเพิกเฉยมักจะยกระดับไปเป็น 403, CAPTCHA หรือบล็อกถาวร

## a 429 เป็นอย่างไรใน Python, curl, Node.js และเบราว์เซอร์?

ข้อผิดพลาดเดียวกันนี้แสดงผลแตกต่างกันในแต่ละเครื่องมือ นี่คือข้อความที่ต้องค้นหาในบันทึกของคุณ:

- **Python requests / httpx:** `status_code == 429`, มักมี `Retry-After: 30` 
- **Scrapy:** ถูกจัดการโดย `RetryMiddleware` เนื่องจาก 429 อยู่ใน `RETRY_HTTP_CODES` เริ่มต้น
- **curl:** `HTTP/2 429` ตามด้วย `retry-after:` ใน header ตอบกลับ
- **APIs:** ตัว JSON เช่น `{"error": "rate_limited"}`

## อะไรเป็นสาเหตุของ a 429?

โอกาสสูงสุดอันดับแรก:

- **คำขอพร้อมกันเกินไปต่อโฮสต์** งานพร้อมกัน 50 งานต่อโดเมนดูเหมือนการโจมตีสำหรับเว็บไซต์ส่วนใหญ่
- **ไม่มีดีเลย์ระหว่างคำขอ** หรือดีเลย์คงที่ที่ทำให้หลายงานทำงานพร้อมกันทันที
- **การลองซ้ำโดยไม่มีการหน่วง** พายุการลองซ้ำหลังได้รับ 429 ครั้งแรกเพิ่มโหลดขึ้น
- **ขีดจำกัดที่ใช้ร่วมกัน** บางเว็บไซต์นับคำขอต่อบัญชี, ต่อคีย์ API หรือคุกกี้เซสชัน ไม่ใช่ต่อ IP
- **ปลายทางที่หนัก** URL การค้นหาและกรองมักมีข้อจำกัดเข้มงวดกว่าหน้าแบบคงที่

## ฉันวินิจฉัย a 429 ทีละขั้นตอนอย่างไร?

1. บันทึกค่า `Retry-After` และ header จำกัดอัตราทุกตัวเมื่อได้รับ 429 ครั้งแรก
2. วัดอัตราคำขอจริงต่อโฮสต์ ไม่ใช่อัตรารวม
3. ตรวจสอบว่าขีดจำกัดถูกตาม IP, คุกกี้ หรือคีย์ API: เปลี่ยนทีละอย่าง
4. อ่านเอกสาร API หรือ robots.txt ของไซต์; บรรทัด `Crawl-delay` บอกอัตราที่ร้องขอ

*ทดสอบ URL ที่ล้มเหลวด้วย curl (พอร์ต HTTP, โหมดละเอียด)*

```bash
# Use the URL that fails; with https://api.ipify.org instead, you test the gateway alone.
# "HTTP/1.1 200 Connection established" first, then the site's own status: the site answered.
curl -v -x http://USERNAME:PASSWORD@gw.crawlrelay.com:7777 https://TARGET_URL

# Same test through the SOCKS5 port, with DNS resolved at the exit
curl -v --socks5-hostname gw.crawlrelay.com:7778 --proxy-user USERNAME:PASSWORD https://TARGET_URL
```

## ฉันจะแก้ไข a 429 อย่างไร?

- **เคารพ Retry-After** รออย่างน้อยเท่าที่เซิร์ฟเวอร์ขอ
- **กำหนดขีดจำกัดความขนานต่อโฮสต์** ไม่ใช่แค่ทั่วโลก Scrapy มี `CONCURRENT_REQUESTS_PER_DOMAIN` และ `AUTOTHROTTLE_ENABLED`
- **หน่วงแบบ exponential พร้อม jitter**: 1 วิ, 2 วิ, 4 วิ และต่อไป เพิ่มส่วนสุ่ม จำกัดสูงสุด
- **ดึงข้อมูลน้อยลง** แคชการตอบกลับ ส่ง `If-Modified-Since` หรือ `If-None-Match` และข้ามหน้าที่ไม่เปลี่ยนแปลง
- **ใช้ API อย่างเป็นทางการ** เมื่อเว็บไซต์มี; ขีดจำกัดมักถูกระบุไว้

*Python: ลองใหม่ด้วย Retry-After, การหน่วงเพิ่มขึ้นแบบเอ็กซ์โพเนนเชียล และ jitter*

```python
import random
import time

import requests

PROXY = "http://USERNAME:PASSWORD@gw.crawlrelay.com:7777"
PROXIES = {"http": PROXY, "https": PROXY}
RETRY_STATUSES = {429, 502, 503, 504}


def fetch(url, attempts=5, timeout=(10, 30)):
    for attempt in range(attempts):
        try:
            r = requests.get(url, proxies=PROXIES, timeout=timeout)
        except (requests.exceptions.ConnectionError, requests.exceptions.Timeout):
            r = None  # dropped exit, reset or timeout: a new connection gets a new exit
        if r is not None and r.status_code not in RETRY_STATUSES:
            return r
        retry_after = r.headers.get("Retry-After", "") if r is not None else ""
        if retry_after.isdigit():
            wait = int(retry_after)
        else:
            wait = min(60, 2 ** attempt) + random.uniform(0, 1)
        time.sleep(wait)
    raise RuntimeError("giving up on %s after %d attempts" % (url, attempts))
```

## ฉันควรลองใหม่หลังจาก a 429 ไหม?

ใช่ 429 ตั้งใจให้ลองใหม่ภายหลัง รอเวลาตามดีเลย์ `Retry-After` หากเซิร์ฟเวอร์ส่งมา; หากไม่มี ให้ใช้หน่วงแบบ exponential พร้อม jitter และจำกัดสูงสุด นับ 429 ติดต่อกันต่อโฮสต์แล้วลดความขนานของโฮสต์นั้นเมื่อจำนวนเพิ่ม Python ฟังก์ชันด้านล่างทำส่วนพื้นฐานนี้

## 429 Too Many Requests มีผลอย่างไรกับ CrawlRelay?

429 ที่ถูกส่งผ่าน CrawlRelay จะมี header และเนื้อหาของเป้าหมายด้วย ขีดจำกัดเป็นของไซต์ และการจัดคิวต่อโฮสต์เป็นหน้าที่ของคุณ ใช้เซสชันคงที่เมื่อไซต์นับคำขอต่อเซสชัน เพื่อให้อัตราของคุณวัดได้ และดู [คำแนะนำความขนาน](https://crawlrelay.com/th/docs/concurrency/) สำหรับตัวเลขเริ่มต้น

เกตเวย์: `gw.crawlrelay.com`, พอร์ต 7777 (HTTP, HTTPS ผ่าน CONNECT) และพอร์ต 7778 (SOCKS5). รูปแบบชื่อผู้ใช้: `USERNAME-country-{cc}-state-{state}-city-{city}-zip-{zip}-asn-{asn}-session-{id}-ttl-{minutes}`. ที่เกี่ยวข้อง: [403 Forbidden](https://crawlrelay.com/th/docs/errors/403-forbidden/) · [503 Service Unavailable](https://crawlrelay.com/th/docs/errors/503-service-unavailable/) · [คำแนะนำความขนาน](https://crawlrelay.com/th/docs/concurrency/).

## 429 Too Many Requests: คำถามที่นักพัฒนาถาม

### ควรหมุน IP เพื่อหลีกเลี่ยงข้อผิดพลาด 429 หรือไม่?

ไม่ 429 คือคำขอของเว็บไซต์ให้ชะลอ การกระจายอัตราคำขอเดียวกันไปยัง IP หลายตัวเพื่อไม่เกินขีดจำกัดต่อ IP เป็นการหลีกเลี่ยงและขัดต่อข้อกำหนดการใช้งานส่วนใหญ่ การหมุน IP ใช้สำหรับกระจายโหลดและตำแหน่ง ไม่ใช่เพื่อเกินลิมิตที่ประกาศ ลดอัตราคำขอและแคชที่ทำได้

### ควรรอเท่าไหร่หลังจากได้รับ 429?

รอจำนวนวินาทีใน header `Retry-After` หรือจนถึงวันที่ระบุ หากไม่มี header ให้เริ่มที่ 1 หรือ 2 วินาทีและเพิ่มเวลาดับเบิลหลังได้รับ 429 แต่ละครั้ง เพิ่มส่วนสุ่มและจำกัดสูงสุดประมาณหนึ่งนาที กลับทำงานที่อัตราต่ำกว่า ไม่ใช่ที่อัตราที่ทำให้เกิด 429

### ทำไมได้รับ 429 แม้มีคำขอเพียงไม่กี่คำขอต่อนาที?

ขีดจำกัดอาจเป็นต่อบัญชี, คุกกี้ หรือคีย์ API แทนที่จะเป็นต่อ IP หรือปลายทางอาจมีราคาแพง เช่น หน้าใช้ค้นหา บางเว็บไซต์ตั้งขีดจำกัดต่ำสำหรับลูกค้าที่จำแนกเป็นบอท ตรวจสอบ header การตอบกลับและเอกสาร API ของไซต์ แล้วขอสิทธิ์เข้าถึงหากจำเป็น

## ข้อผิดพลาดพร็อกซีอื่นๆ ในเอกสารอ้างอิงนี้

- [401 Unauthorized vs 407](https://crawlrelay.com/th/docs/errors/401-unauthorized/)
- [403 Forbidden](https://crawlrelay.com/th/docs/errors/403-forbidden/)
- [407 Proxy Authentication Required](https://crawlrelay.com/th/docs/errors/407-proxy-authentication-required/)
- [429 Too Many Requests](https://crawlrelay.com/th/docs/errors/429-too-many-requests/)
- [502 Bad Gateway](https://crawlrelay.com/th/docs/errors/502-bad-gateway/)
- [503 Service Unavailable](https://crawlrelay.com/th/docs/errors/503-service-unavailable/)
- [504 Gateway Timeout](https://crawlrelay.com/th/docs/errors/504-gateway-timeout/)
- [Cannot connect to proxy (ProxyError)](https://crawlrelay.com/th/docs/errors/cannot-connect-to-proxy/)
- [Connection reset by peer (ECONNRESET)](https://crawlrelay.com/th/docs/errors/connection-reset/)
- [ERR_PROXY_CONNECTION_FAILED](https://crawlrelay.com/th/docs/errors/err-proxy-connection-failed/)
- [ERR_TUNNEL_CONNECTION_FAILED](https://crawlrelay.com/th/docs/errors/err-tunnel-connection-failed/)
- [Read timed out (ReadTimeout)](https://crawlrelay.com/th/docs/errors/read-timeout/)
- [SOCKS5 proxy errors](https://crawlrelay.com/th/docs/errors/socks5-proxy-errors/)
- [SSL: CERTIFICATE_VERIFY_FAILED](https://crawlrelay.com/th/docs/errors/ssl-certificate-verify-failed/)
- [SSL: WRONG_VERSION_NUMBER](https://crawlrelay.com/th/docs/errors/ssl-wrong-version-number/)

**พร็อกซีเรซิเดนเชียลที่มีเอกสารอธิบายกรณีล้มเหลว** พร็อกซีเรซิเดนเชียล CrawlRelay จาก US$0.50/GB, ปริมาณข้อมูลที่ไม่หมดอายุ [ดูราคา](https://crawlrelay.com/th/pricing/) · [เริ่มต้นอย่างรวดเร็ว](https://crawlrelay.com/th/docs/)

---

CrawlRelay: CrawlRelay คือพร็อกซีเรซิเดนเชียลหมุนเวียนพร้อมพร็อกซีมือถือ 4G/5G สำหรับนักพัฒนา เหมาะกับสแครปเปอร์และระบบจัดการข้อมูล AI: เติมเงินจ่ายตามการใช้งานจาก US$0.50/GB จ่ายด้วยคริปโต ไม่ต้องอัปโหลดบัตรประชาชน ไม่ต้อง KYC — ไม่ต้องใช้บัตรประชาชน ไม่ต้องถ่ายเซลฟี่ ไม่ต้องใช้เอกสาร จ่ายด้วยคริปโต