ไม่ต้อง KYC — ไม่ต้องใช้บัตรประชาชน ไม่ต้องถ่ายเซลฟี่ ไม่ต้องเอกสาร จ่ายด้วยคริปโต: BTC, USDT, USDC, ETH, SOL, LTC
ภาษา: ไทย
เริ่มต้นเลย

ข้อมูลอ้างอิงข้อผิดพลาดพร็อกซี · รหัสสถานะ HTTP

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

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

อัปเดตล่าสุด: · 3 เวลาที่ใช้ในการอ่าน (นาที)

คำตอบด่วน

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, โหมดละเอียด)
# 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:[email protected]: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
import random
import time

import requests

PROXY = "http://USERNAME:[email protected]: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 และเนื้อหาของเป้าหมายด้วย ขีดจำกัดเป็นของไซต์ และการจัดคิวต่อโฮสต์เป็นหน้าที่ของคุณ ใช้เซสชันคงที่เมื่อไซต์นับคำขอต่อเซสชัน เพื่อให้อัตราของคุณวัดได้ และดู คำแนะนำความขนาน สำหรับตัวเลขเริ่มต้น

เกตเวย์: 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 · 503 Service Unavailable · คำแนะนำความขนาน.

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

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

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

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

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

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

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

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

รหัสสถานะ HTTP

ข้อผิดพลาดของเบราว์เซอร์และไคลเอนต์

ข้อผิดพลาดการเชื่อมต่อและ TLS

พร็อกซีเรซิเดนเชียลที่มีเอกสารอธิบายกรณีล้มเหลว

พร็อกซีเรซิเดนเชียล CrawlRelay จาก US$0.50/GB, ปริมาณข้อมูลที่ไม่หมดอายุ

ดูราคาเริ่มต้นอย่างรวดเร็ว

จาก US$0.50/GB · ไม่ต้อง KYC

เริ่มต้นเลย