เซิร์ฟเวอร์ Git ของฉันไม่เสถียรเพราะ Amazon AI crawler

 (xeiaso.net)
1 คะแนน โดย GN⁺ 2025-01-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เซิร์ฟเวอร์ Gitea สาธารณะ git.xeserv.us ไม่เสถียรจาก คำขอของ AmazonBot ทำให้ผู้ดูแลร้องขอให้ทีม AmazonBot เพิ่มโดเมนดังกล่าวเข้าไปในรายการบล็อก
  • แม้จะตั้งค่า robots.txt ให้ Disallow: / สำหรับบอตทั้งหมดแล้ว แต่คำขอก็ยังคงเข้ามา ทำให้สถานการณ์อาจไปถึงขั้นต้องเลิก เปิดให้บริการเซิร์ฟเวอร์ Git สาธารณะ
  • AI crawler ทำให้การบล็อกทำได้ยาก โดยใช้วิธีเปลี่ยน user agent หรือใช้ พร็อกซี IP ที่อยู่อาศัย
  • ได้บล็อกใน nginx ingress ให้คืนค่า 418 กับ user agent ที่มี Amazon แต่คำขอยังคงมาจาก IP อื่นต่อเนื่อง และประมาณ 10% ก็ไม่มี user agent amazonbot ด้วย
  • สุดท้ายเซิร์ฟเวอร์ Gitea ถูกย้ายกลับไปไว้หลัง VPN อีกครั้ง และมีการสร้าง reverse proxy ชื่อ Anubis ที่ตรวจสอบ proof of work ก่อนอนุญาตคำขอ

คำขอจาก AmazonBot และข้อจำกัดของ robots.txt

  • ผู้ดูแลได้ร้องขอไปยังผู้ดูแล AmazonBot ให้เพิ่ม git.xeserv.us เข้าไปใน รายการโดเมนที่บล็อก
  • ระบุว่าหากต้องการ crawl เซิร์ฟเวอร์ Git ก็ขอให้ติดต่อมาเพื่อจ่าย ค่าอัปเกรดฮาร์ดแวร์ ที่จำเป็นต่อการรองรับการใช้ทรัพยากรในระดับนั้น
  • แม้จะตั้งค่า robots.txt เพื่อบล็อกบอตทั้งหมดไว้แล้ว แต่ก็ยังไม่เพียงพอในการบล็อกคำขอจริง
User-agent: *
Disallow: /
  • มีการสรุปเหตุผลด้วยว่าทำไมการบล็อกบอต AI crawler จึงทำได้ยาก
    • บอตโกหก
    • เปลี่ยน user agent
    • ใช้ที่อยู่ IP แบบที่อยู่อาศัยเป็นพร็อกซี
    • ใช้วิธีอื่นอีกด้วย

การบล็อกใน nginx ingress และการเปิดตัว Anubis

  • เมื่อ 2025-01-17 17:50 UTC ได้เพิ่มการบล็อก user agent ผ่านการตั้งค่า nginx ingress
nginx.ingress.kubernetes.io/configuration-snippet: |
  if ($http_user_agent ~* "(Amazon)" ){
    return 418;
  }
  • หลังการตั้งค่านี้ บอตก็ยังคงส่งคำขอเข้ามาจาก IP ที่เปลี่ยนไปทุกครั้ง และประมาณ 10% ของคำขอ ไม่มี user agent amazonbot
  • เมื่อ 2025-01-18 19:00 UTC ได้ย้ายเซิร์ฟเวอร์ Gitea กลับไปไว้ หลัง VPN อีกครั้ง
  • หลังจากนั้นได้เริ่มสร้าง reverse proxy ที่ตรวจสอบ proof of work ก่อนอนุญาตคำขอที่หน้าเซิร์ฟเวอร์ Gitea
  • เมื่อ 2025-01-18 23:50 UTC พร็อกซีดังกล่าวสามารถเข้าดูได้ที่ https://git.xeserv.us/ ภายใต้ชื่อ Anubis
  • ณ วันที่ 2025-03-26 14:27 UTC Anubis ได้กลายเป็นโปรเจกต์อิสระที่มีเว็บไซต์เอกสาร

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-01-19
ความคิดเห็นจาก Hacker News

  • ถึงเวลาส่ง หนังสือจากทนายความ แล้ว แนวทางการดำเนินคดีตาม Computer Fraud and Abuse Act ระบุว่า โดยทั่วไปกระทรวงยุติธรรมสหรัฐจะไม่มองการเข้าถึงเซิร์ฟเวอร์สาธารณะว่าเป็น “การเข้าถึงโดยไม่ได้รับอนุญาต” หากไม่ใช่การโจมตีที่ชัดเจน แต่ถ้าภายหลังผู้มีสิทธิ์ส่งคำขอให้หยุดอย่างชัดแจ้งเป็นลายลักษณ์อักษร และจำเลยได้รับและเข้าใจคำขอนั้น ตั้งแต่นั้นไปจะถือว่าเป็นการเข้าถึงโดยไม่ได้รับอนุญาต
    ดังนั้นให้ทนายเขียนหนังสือ “cease and desist” แบบชัดเจน แล้วส่งถึง Amazon ทางไปรษณีย์ลงทะเบียนหรือผ่านผู้ส่งหมายตามวิธีที่ทนายแนะนำ น่าจะต้องทำทั้งสองอย่างและส่งอีเมลด้วย
    จากนั้นก็ดูว่า Amazon จะหยุดไหม ถ้าไม่หยุดก็สามารถแจ้งความคดีอาญาได้ แบบนั้น Amazon ก็น่าจะต้องใส่ใจ
    https://www.justice.gov/jm/jm-9-48000-computer-fraud

    • การบอกว่า “ดูว่า Amazon จะหยุดไหม” จะใช้ได้ก็ต่อเมื่อคำขอนั้นมาจาก Amazon จริง ๆ จากรายละเอียดในโพสต์ เช่น user agent ที่หมุนเวียนเปลี่ยนไปเรื่อย ๆ, IP ที่อยู่อาศัย, และพฤติกรรมที่ดูเหมือนไม่ตีความ robots.txt ก็ดูไม่น่าเป็นไปได้เท่าไร
      bot ของ Amazon ควรมาจากช่วง IP ของ Amazon ที่รู้จักได้ และควรทำตาม robots.txt ด้วย วิศวกรของ Amazon ก็ยืนยันไว้ในคอมเมนต์อื่น: https://news.ycombinator.com/item?id=42751729
      ถ้าสิ่งที่ตรงกับ Amazon มีแค่สตริง user agent ว่า “AmazonBot” แต่ช่วง IP หรือพฤติกรรมไม่ตรง การส่งหนังสือจากทนายไปหา Amazon ก็แทบไม่ต่างจากการเผาเงิน
    • พูดตามตรง แค่เรื่องนี้ขึ้นหน้าแรกของ Hacker News ก็น่าอับอายพอแล้ว น่าจะมีใครสักคนใน แผนกสามัญสำนึก มาอ่านและตอบอีเมลสุภาพที่ผมส่งไปว่า “ช่วยอย่ามาคลานบน git server ของผม” ถ้ายังไม่มีคำตอบภายในวันอังคารหน้า ผมจะให้ทนายเขียนหนังสือขอให้หยุดอย่างเป็นทางการ
    • หรือว่าเราจำเป็นต้องมีกฎหมายที่บอกว่า “หุ่นยนต์ต้องทำตาม robots.txt” แล้ว?
    • สงสัยว่าคำว่า ผู้ส่งหมาย (process server) ในที่นี้หมายถึงอะไรแน่

  • ชอบวิธีแก้ในคอมเมนต์นี้: https://news.ycombinator.com/item?id=42727510
    คือใส่ลิงก์ไว้สักที่บนเว็บในจุดที่มนุษย์ไม่มีทางกดเข้าไป แล้วห้ามไว้ใน robots.txt จากนั้นถ้า IP ไหนเข้าไปที่ลิงก์นั้นก็แบน 24 ชั่วโมง ว่ากันว่า crawler ของ OpenAI โดยเฉพาะชอบไม่สน wildcard ก็เลยเอาไปวางไว้ใต้ wildcard แบบนั้น

    • ผมเคยรับมือกับกิจกรรมของบอตที่ใช้ช่วงที่อยู่กว้าง ๆ และก็เคยลองวิธีคล้ายกัน คือถ้ายืนยันได้ว่าเป็นบอตตามเงื่อนไขก็ แบน IP 24 ชั่วโมง
      แต่มี IP ที่เกี่ยวข้องเยอะเกินไป จนแทบไม่กระทบทราฟฟิกเลย
      แนะนำให้ดู header ที่ได้รับอย่างละเอียดมาก varnishlog ค่อนข้างเหมาะกับงานแบบนี้ และถ้าดูนานพอ คุณมักจะหาลักษณะร่วมกันของทุกคำขอได้ เช่น การจับคู่แปลก ๆ ระหว่างภาษาที่รายงานกับตำแหน่งทางภูมิศาสตร์ หรือการใช้เบราว์เซอร์เวอร์ชันเก่าแบบเดียวกัน
    • web crawler นี่น่ารำคาญจริง ๆ เมื่อราว 8 ปีก่อนที่ทำงานเก่า เซิร์ฟเวอร์ภาพรถเคยล่ม crawler ตัวปัญหาเข้าถึงลิงก์ภาพรถที่เรามีตามลักษณะงาน และดันมาเจอสถานการณ์เลวร้ายสมบูรณ์แบบที่ภาพนั้นไม่มีอยู่จริง ทำให้ image server สำหรับรายงานสถานะแทบโดน DoS ที่แย่กว่านั้นคือมีบั๊กในตัวจัดการข้อผิดพลาด ทำให้เมื่อเกิดเงื่อนไขนี้ process ของเซิร์ฟเวอร์ถูกรีสตาร์ต และระหว่างนั้นก็ทำให้ cache implementation ที่ “ถือว่าดีทีเดียวตามมาตรฐาน .NET 2.0” ใช้การไม่ได้ไปด้วย
      เลยจำได้ว่าเราเริ่มใส่ canary technique เป็นตัวกันไว้ simple canary ไม่กี่ตัวก็ยังถูกกว่าการเพิ่ม web server อีกเครื่อง แน่นอนว่าเราแก้ปัญหา cache ด้วย และเพิ่มวิธีให้บริการนั้น “ส่งเสียงกรีดร้อง” เมื่อมีคำขอแย่ ๆ เข้ามามากเกินไป
    • ตอนที่ผมสร้าง crawler สำหรับ search engine ของตัวเอง ผมพบว่าแทบไม่มี ไลบรารี crawler ที่เข้ากับโลกจริงได้ดีพอ สุดท้ายเลยต้องลงแรงพอสมควรทำ implementation เองให้รองรับไฟล์ robots แบบซ้อนและซับซ้อนของ Amazon กับ Google รวมถึงช่วงพักการร้องขอที่ระบุไว้ด้วย
      แต่ที่น่าขำคือ crawler ของบริษัทพวกนั้นกลับ parse manifest ที่ตัวเองสร้างไว้ไม่ได้

  • เราก็เห็นพฤติกรรมแบบเดียวกันจาก บอต AI และ SEO ทุกตัว เลย เลยขอแนะนำแบบนี้ พวกมันทำตาม robots.txt แบบแทบจะพอผ่าน และบล็อกก็ยากมาก เวลา crawl จะถาโถมเข้ามาเหมือนสแปม เพิ่มโหลดหนักจนทำให้เซิร์ฟเวอร์ของลูกค้าหลายรายล่ม
    ถ้า AI crawler อยากเข้าถึง ก็ต้องทำตัวดี ๆ หรือไม่ก็จ่ายเงิน ไม่อย่างนั้นผลลัพธ์ก็คงเป็นการบล็อกเกือบทั้งหมดแบบทั่วกระดาน

    • ทางแก้คือ tarpit แบบทั้งระบบ ซึ่งก็สมเหตุสมผลแม้จะไม่นับเฉพาะ AI crawler เมื่อก่อนตอนต้องทำ ผม parse access log แบบกึ่ง manual แล้วใช้ iptables ใส่ -j TARPIT ให้กับ IP ที่ยิง /api เกินค่าเฉลี่ย X ครั้งต่อวินาที
      แต่บนคลาวด์จะทำยังไงผมก็ไม่ค่อยแน่ใจ ยังไม่เคยจำเป็นต้องใช้ตรงนั้น
      https://gist.github.com/flaviovs/103a0dbf62c67ff371ff75fc62f...
    • ผมไม่เข้าใจว่า “การบล็อกเกือบทั้งหมด” ทำกันยังไง นั่นไม่ใช่ประเด็นว่ามันยากหรอกหรือ? ถ้าทำได้ก็คงทำกันไปแล้ว
    • สงสัยว่าคำว่า robots.txt แบบ “แทบจะพอผ่าน” หมายถึงอะไร นี่ไม่ใช่เรื่องแบบสองค่าเหรอ? หมายถึงทำตามบาง directive แต่เมินบาง directive ใช่ไหม?
    • ไม่มีทางที่เว็บไซต์จะขายข้อมูลนั้นให้บอต AI เป็น ไฟล์ zip ขนาดใหญ่ไฟล์เดียว ได้เหรอ? น่าจะดีกว่าปล่อยให้โดน DDoS อยู่เรื่อย ๆ
      หรืออย่างน้อยก็อยากให้มันมาคลานตอนกลางคืนหรือช่วงที่ไม่ค่อยมีคนใช้ เพื่อมารยาทหน่อย
    • จะบล็อกไปทำไม? พอถึงตอนนั้นมันก็คัดลอกเนื้อหาทั้งหมดไปหมดแล้ว

  • ฉันยังไม่คิดว่าจะเป็น Amazon จริง ๆ ผู้เขียนกำลังเห็นคำขอที่ สลับใช้ IP ที่อยู่อาศัยและเปลี่ยนสตริง user-agent
    การแกล้งทำเป็นครอว์เลอร์ของบริษัทยักษ์ใหญ่เป็นเทคนิคที่คนซึ่งไม่อยากให้ตัวเองสะดุดตามักใช้กัน ข้อเท็จจริงที่ว่าคำขอมาจาก IP ที่อยู่อาศัยเป็นสัญญาณเตือนใหญ่ ๆ ว่ากำลังมีอย่างอื่นเกิดขึ้น

    • ฉันทำงานที่ Amazon แต่ไม่ได้ดูแลงานเว็บครอว์ลิงโดยตรง
      จากข้อมูลที่ฉันตรวจสอบได้ภายใน โอกาสที่นี่จะเป็น Amazon จริงนั้นต่ำมาก Amazonbot ต้องปฏิบัติตาม robots.txt และต้องมาจาก IP ที่ Amazon เป็นเจ้าของเสมอ ขั้นตอนการตรวจสอบอยู่ที่นี่: https://developer.amazon.com/en/amazonbot
      ฉันได้ส่งเรื่องเข้าไปภายในเพื่อเช็กว่ามีทีมประหลาดที่ฉันไม่รู้กำลังทำแบบนี้อยู่หรือไม่ แต่ผู้เขียนควรมองทราฟฟิกนี้ว่าเป็นอันตรายและจัดการในฐานะ user-agent ปลอม
    • เรื่องแบบนี้มีขายเป็นบริการเชิงพาณิชย์[1] เพราะไลบรารีที่ถูกรวมอยู่ที่ไหนสักแห่ง เครือข่ายนับร้อยล้านจึงถูกใช้เหมือนแบ็กดอร์ กลายเป็นครอว์เลอร์และสแครปเปอร์ และยังทำให้การใช้ผู้ใช้เป็นแนวหน้าของกิจกรรมก้ำกึ่งระหว่างถูกกฎหมายกับผิดกฎหมายดูเหมือนถูกกฎหมายได้ด้วยถ้อยคำครอบจักรวาลที่ซ่อนอยู่ในข้อกำหนดการใช้งาน
      [1] https://brightdata.com/proxy-types/residential-proxies
    • ทุกวันนี้ ถ้าเป็นบริษัทที่ครอว์ลิงอย่างดุดัน ก็คงยากจะรับประกันได้ว่าไม่ได้ใช้ เครือข่ายพร็อกซี

  • ช่วงหลังฉันก็เจอปัญหาเดียวกัน Forgejo อินสแตนซ์ของฉันเริ่มใช้ CPU ของโฮมเซิร์ฟเวอร์ 100% เพราะเพื่อน AI ของ Claude, Meta และ Google กำลังกระหน่ำลิงก์ที่แทบจะไม่สิ้นสุดด้วยความเร็วสูง
    ฉันลดมันลงได้บ้างด้วย robots.txt และรายการบล็อกตาม user-agent ของ Caddy แต่ไม่รู้ว่าวิธีนี้จะใช้ได้อีกนานแค่ไหน
    มารยาทของการสแครปหายไปไหนหมด?

    • เพราะเงิน บริษัท AI มีแรงจูงใจทางการเงินให้ดึงข้อมูลให้ได้มากที่สุด ให้เร็วที่สุด จากทุกที่ที่หาได้ ตอนนี้พวกเขายังมีเงินสดให้เผาเยอะมากจนแทบไม่จำเป็นต้องทำอย่างมีประสิทธิภาพด้วยซ้ำ
    • เมื่อหลายบริษัทอย่างน้อยก็ได้รับสัญญาณอยู่พักหนึ่งว่า หน้าต่างโอเวอร์ตัน เกี่ยวกับสิ่งที่ AI จะกินได้กว้างมาก พวกเขาก็จะพยายามกอบให้ได้มากที่สุดก่อนที่กฎระเบียบจะเริ่มเข้มงวด
      ความเสี่ยงที่ใหญ่กว่าคือบริษัทพวกนี้สักแห่ง รวมถึงบริษัทที่ชอบเรียกตัวเองว่า “Open” จะโตจนกลายเป็นองค์กรที่ “ปล่อยให้ล้มไม่ได้” ในมุมมองด้านเศรษฐกิจหรือความมั่นคงของชาติ
    • มันก็เหมือนกับเรื่องมารยาทในทุกบริบทอื่น ๆ มารยาทมีอยู่ก็เฉพาะในบริบทที่การเพิกเฉยมันไม่ทำเงิน พอสมมติฐานนั้นหายไป มันก็ถูกทิ้งทันที
    • มีใครช่วยแชร์รายการ robots.txt หรือ user-agent ที่พอใช้บล็อก AI crawler ได้ดีบ้างไหม?
    • คนสุดท้ายบน Hacker News จะใช้เวลาอีกนานแค่ไหนกว่าจะตระหนักว่า Meta, OpenAI และบิ๊กเทคทั้งหลายสุดท้ายจะทำร้ายพวกเราทุกคนเพื่อเงินก้อนเร็ว ๆ?
      Facebook เคยขึ้นชื่อเรื่องทำให้การดึงรายชื่อเพื่อนจาก MySpace ทำได้ง่าย และพอพวกเขาใหญ่แล้วก็ห้ามพฤติกรรมแบบเดียวกันนี้บนเว็บไซต์ของตัวเอง
      ขอเถอะ ตื่นกันได้แล้ว

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

    • น่าจะต้องไปดูเว็บไซต์อย่าง grass dot io ฉันจะไม่ใส่ลิงก์ตรงเพื่อไม่อยากส่งทราฟฟิกให้
      บริการแบบนี้จ่ายเงินให้ผู้ใช้สำหรับแบนด์วิดท์ของพวกเขา แล้วนำไปขายต่อให้บุคคลที่สาม ทำให้บอตทราฟฟิกจำนวนมากดูเหมือนมาจาก IP ที่อยู่อาศัย

  • เว็บไซต์ของฉัน Pinboard ก็โดนสิ่งที่น่าจะเป็น AI crawler ถล่มอยู่เหมือนกัน ช่วงฤดูร้อนนี้เริ่มจาก IP ในจีนและสิงคโปร์ แต่ตอนนี้ถึงขั้นบล็อกตามช่วง IP ไม่ได้แล้ว ต้องพึ่ง CAPTCHA
    ระดับทราฟฟิกสูงพอจะฆ่าเว็บไซต์ได้ทันที ทั้งที่ฉันก็ไม่มีข้อความน่าสนใจอะไรให้เอาไปฝึก มีแต่ลิงก์
    ฉันสงสัยว่าผู้เขียนต้นฉบับรู้ได้อย่างไรว่า Amazon crawler เป็นสาเหตุ ฉันเองก็อยากมีใครสักคนให้โทษ

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

    • แนวคิดเรื่องการป้อน “เนื้อหาที่เป็นอันตราย” เป็นการเข้าใจขอบเขตของพฤติกรรมแย่ ๆ ของบริษัท AI ผิดไปทั้งหมด
      สแครปเปอร์พวกนี้กินแม้แต่ CSAM และสิ่งเลวร้ายระดับใกล้เคียงกันอย่างไม่ลังเลอยู่แล้ว ผู้รับเหมาช่วงด้านติดป้ายข้อมูลในเคนยาของ OpenAI บางส่วนลาออกเพราะเรื่องนี้ นี่คือบทความของ Time ปี 2023
      ตอนนี้บริษัท AI ไม่ได้สนใจคุณภาพข้อมูล สนใจแค่ ปริมาณ เท่านั้น วิธีเดียวที่จะทำร้ายพวกเขาได้คือให้ข้อมูล 0 ไบต์
      แค่หนึ่งในสิบของสิ่งที่ Sam Altman อนุมัติ คนทั่วไปก็คงเข้าคุกไปแล้วทันที
    • เคยเห็นมีคนแนะนำ tarpit นี้สำหรับจุดประสงค์แบบนี้ มันจะสร้างการซ้อนกันของไดเรกทอรีไม่รู้จบและเนื้อหาขยะไม่รู้จบเมื่อเว็บไซต์ถูกครอว์ล ทำให้บอตติดอยู่ได้นานหลายชั่วโมง
      https://zadzmo.org/code/nepenthes/
    • ถ้าหมายถึงเนื้อหาที่เป็นอันตรายในความหมายว่าเป็นเนื้อหาที่ไม่ถูกต้อง ก็มีคนในคอมเมนต์อื่นของเธรดนี้ทำแบบนั้นจริง ๆ: https://marcusb.org/hacks/quixotic.html
    • ในเมื่อบริษัทมูลค่าหลายพันล้านยังทำผิดกฎหมายต่อไปโดยไม่ถูกลงโทษ ทำไมฉันต้องเป็นคนรับผิดชอบกับการทำอะไรที่แทบไม่มีประโยชน์ด้วย?

  • คงจะดีถ้าในฐานะการแสดงความหวังดี Amazon และบอตอื่น ๆ ช่วยให้ AWS credit มาสักหน่อยเพื่อชดเชย ทราฟฟิกขาออกส่วนเกิน ที่พวกมันสร้างขึ้น แต่ก็คงน่าจะชดเชยได้ด้วยรายได้โฆษณาจากโพสต์นี้อยู่แล้ว ถ้าปลด ad blocker ก็คงคุ้มทุน

  • ก่อนบล็อกด้วย Nginx นั้น Bytespider คิดเป็น 59% และ Amazonbot คิดเป็น 21% โดยเมื่อรวมกันแล้วทั้งสองตัวกินทราฟฟิกทั้งหมดของเซิร์ฟเวอร์ Git ของเราไป 80%
    ClaudeBot ส่งทราฟฟิกไปยัง Redmine ในช่วงหนึ่งเดือน มากกว่าทราฟฟิกตลอด 5 ปีก่อนหน้าเมื่อรวมกันก่อนมี ClaudeBot เสียอีก