การตั้งค่า proxy สำหรับ Crawl4AI และ Firecrawl: ingestion สำหรับ RAG ที่ไม่โดนบล็อก (2026)

Crawl4AI และ Firecrawl กลายเป็นวิธีมาตรฐานในการป้อนข้อมูลเว็บเข้าสู่ไปป์ไลน์ LLM — มันคลาน เรนเดอร์ แล้วส่ง Markdown ที่สะอาดและพร้อมใช้กลับมาให้โมเดลของคุณใช้งานได้จริง จากนั้นพอคุณเล็งมันไปที่เป้าหมายจริง คุณก็จะค้นพบสิ่งที่ทุก scraper เรียนรู้ในที่สุด นั่นคือ ชั้นการดึงข้อมูลไม่เคยเป็นส่วนที่ยากเลย ส่วนที่ยากคือ crawler ของคุณทำงานจาก IP ดาต้าเซ็นเตอร์เพียงตัวเดียว และเว็บก็มองเห็นมัน

คู่มือนี้แสดงการตั้งค่า proxy ที่ใช้งานได้จริงสำหรับทั้งสองเครื่องมือ — Crawl4AI แบบ self-hosted และ Firecrawl ทั้งสองโหมด — พร้อมกลยุทธ์เซสชันที่หยุดไม่ให้งาน ingestion สำหรับ RAG ตายตั้งแต่หน้าที่ 50 มันต่อยอดจากคู่มือ proxy สำหรับ AI agentและคู่มือ browser-useของเราไปยังเฟรมเวิร์กการคลานเว็บ

ทำไม LLM Crawler ถึงถูกบล็อกเร็วกว่า Scraper ทั่วไป

• มันดึงข้อมูลแบบกว้าง ไม่ใช่แบบเจาะจง งาน ingestion สำหรับ RAG ดึงข้อมูลหลายร้อยหน้าทั่วทั้งโดเมนภายในไม่กี่นาที — ซึ่งเป็นรูปแบบความเร็วที่ระบบชื่อเสียง IP ให้คะแนนเข้มงวดที่สุด (ดูการตรวจจับ ASN อธิบายไว้)
• มันรัน headless Chromium ตามค่าเริ่มต้น Crawl4AI ใช้ Playwright อยู่เบื้องหลัง หากไม่ใส่ flag มันจะแสดงร่องรอย headless มาตรฐาน
• มันลองใหม่อย่างโง่เขลา การ retry-on-failure ตามค่าเริ่มต้นเมื่อชนกำแพง anti-bot ก็แค่เผาชื่อเสียงของ IP ให้ลึกลงไปอีก

Crawl4AI: การตั้งค่า Proxy

Crawl4AI (โอเพนซอร์ส, self-hosted) รับ proxy ที่ระดับ BrowserConfig — หนึ่ง proxy ต่อหนึ่ง crawler instance:

from crawl4ai import AsyncWebCrawler, BrowserConfig, CrawlerRunConfig

browser_cfg = BrowserConfig(
    headless=True,
    proxy_config={
        "server": "us.jibaoproxy.com:913",
        "username": "USERNAME",
        "password": "PASSWORD",
    },
)

async with AsyncWebCrawler(config=browser_cfg) as crawler:
    result = await crawler.arun(
        url="https://example.com/docs",
        config=CrawlerRunConfig(),
    )
    print(result.markdown[:500])

สำหรับการคลานเชิงลึก ให้หมุนเปลี่ยนตัวตนต่อ crawler instance ไม่ใช่ต่อหน้า — หน้าต่าง ๆ ภายในการเข้าชมไซต์เดียวควรใช้ exit IP เดียวร่วมกัน (คนจริงไม่เปลี่ยนเมืองระหว่างหน้า 3 กับหน้า 4):

def crawler_for(site_id: str) -> BrowserConfig:
    # Sticky session per site: cookies + IP move together
    return BrowserConfig(
        headless=True,
        proxy_config={
            "server": "us.jibaoproxy.com:913",
            "username": f"USERNAME-session-{site_id}",
            "password": "PASSWORD",
        },
    )

# site A crawled through exit A, site B through exit B, in parallel

Firecrawl: สองโหมด สองคำตอบ

Cloud API: การใช้ proxy เป็นพารามิเตอร์ของคำขอ — Firecrawl กำหนดเส้นทางผ่านพูลของตัวเอง คุณควบคุมระดับคุณภาพได้ แต่ไม่ใช่ตัว IP:

from firecrawl import FirecrawlApp

app = FirecrawlApp(api_key="fc-YOUR-KEY")
result = app.scrape_url(
    "https://example.com/pricing",
    params={"proxy": "stealth"},   # basic | stealth | auto
)

ข้อเสีย: คำขอระดับ stealth คิดเครดิตเป็นหลายเท่าของระดับ basic และคุณไม่สามารถปักหมุดประเทศได้แม่นยำหรือคงเซสชัน sticky ข้ามคอลได้ เหมาะกับหน้าที่ดึงเป็นครั้งคราว แต่แพงและไม่แม่นยำเมื่อทำที่ระดับปริมาณ ingestion

Firecrawl แบบ self-hosted: คุณจัดหา proxy ของคุณเองผ่าน environment variable พร้อมการควบคุมเต็มที่:

# .env for self-hosted Firecrawl
PROXY_SERVER=http://us.jibaoproxy.com:1000
PROXY_USERNAME=USERNAME
PROXY_PASSWORD=PASSWORD

การตั้งค่าแบบ self-hosted + เกตเวย์ residential ของคุณเองคือการตั้งค่าที่คุ้มค่าทางต้นทุนเมื่อคุณทำ ingestion ในระดับใหญ่: คุณจ่ายต่อ GB สำหรับแบนด์วิดท์แทนที่จะจ่ายเครดิตต่อหน้าพร้อมตัวคูณ stealth

กลยุทธ์เซสชันสำหรับงาน Ingestion ของ RAG

• หนึ่งไซต์ = หนึ่งตัวตน sticky Cookie แคช และ exit IP คงที่ตลอดการคลานทั้งไซต์ แล้วหมุนเปลี่ยนระหว่างไซต์ (พื้นหลัง: sticky vs rotating)
• เคารพจังหวะต่อไซต์ ตัวเลือก semaphore_count / delay ของ Crawl4AI มีไว้เพื่อสิ่งนี้ — 2–4 หน้าพร้อมกันต่อไซต์ก็มากพอแล้ว ให้กระจายการทำงานขนานข้ามไซต์แทน
• ให้หน้าล้มเหลว ไม่ใช่งานทั้งงาน เมื่อเจอ 403/challenge ให้ทำเครื่องหมาย URL หมุนเปลี่ยนตัวตน แล้วทำต่อ — การ retry มั่ว ๆ ผ่าน exit เดิมเป็นการวางยาคะแนนของมัน
• ตรวจสอบ Markdown หน้า interstitial ของ anti-bot ก็แปลงเป็น Markdown ได้สบาย ๆ — "Verifying you are human" ที่ฝังอยู่ใน vector DB ของคุณคือโหมดความล้มเหลวจริง ๆ ให้ grep ผลลัพธ์ ingestion หาเครื่องหมายของหน้า challenge ก่อนทำดัชนี
• แคชอย่างจริงจัง การคลานหน้าที่ไม่เปลี่ยนแปลงซ้ำเป็นการเผาแบนด์วิดท์และชื่อเสียงโดยเปล่าประโยชน์ — เคารพ ETag/Last-Modified เมื่อเฟรมเวิร์กอนุญาต

เช็กความจริงเรื่องต้นทุน

การตั้งค่า	คุณจ่ายค่าอะไร	เหมาะสุดเมื่อ
Firecrawl cloud, stealth proxy	เครดิตต่อหน้า × ตัวคูณ stealth	ปริมาณน้อย ไม่มีงาน ops
Firecrawl self-hosted + residential GB	แบนด์วิดท์เท่านั้น (~$10/GB)	ปริมาณ ingestion สม่ำเสมอ
Crawl4AI + residential GB	แบนด์วิดท์เท่านั้น ควบคุมเต็มที่	ไปป์ไลน์กำหนดเอง การคลานเชิงลึก

หน้าที่มีข้อความเยอะ ๆ ทั่วไปจะกินราว 100–300 KB ผ่าน proxy — ประมาณ 3,000–10,000 หน้าต่อ GB ลูปแบบบล็อกแล้วลองใหม่นี่แหละที่ทำให้งบบาน ซึ่งเป็นอีกเหตุผลที่ควรแก้ปัญหาการตรวจจับก่อนขยายปริมาณ

สรุป

• LLM crawler ถูกบล็อก = การตรวจจับ IP + headless ไม่ใช่ตัวเฟรมเวิร์ก ให้แก้ชั้นเครือข่ายก่อน
• Crawl4AI: proxy_config ใน BrowserConfig ตัวตน sticky ต่อไซต์ หมุนเปลี่ยนระหว่างไซต์
• Firecrawl cloud: พารามิเตอร์ proxy: "stealth" แพงเมื่อปริมาณมาก; self-hosted: เกตเวย์ของคุณเองผ่าน env vars
• ตรวจสอบเอาต์พุต Markdown หาข้อความหน้า challenge ก่อนที่มันจะไปถึง vector DB ของคุณ
• Residential แบบจ่ายต่อ GB เอาชนะเครดิต stealth ต่อหน้าเมื่อ ingestion สม่ำเสมอแล้ว