ถ้ามีปัญหา ก็ไปบล็อกกันที่ระดับ IP
(boston.conman.org)- ระหว่างการวิเคราะห์ทราฟฟิกเว็บล่าสุด พบว่าเว็บบอตชื่อ Thinkbot สร้างทราฟฟิกมากที่สุด
- บอตตัวนี้ไม่สนใจ
robots.txtและแม้แต่ข้อความแนะนำตัวก็เขียนอย่างไม่รับผิดชอบประมาณว่า “ถ้ามีปัญหาก็ไปบล็อก IP เอาเอง” - ตลอดหนึ่งเดือน มันใช้ IP ที่แตกต่างกัน 74 รายการ และกระจายอยู่ใน 41 network block
- จากการตรวจสอบพบว่า network block ทั้งหมดนี้เป็น ของ Tencent และทำให้เกิดข้อสงสัยว่านี่เกี่ยวข้องกับความเป็นไปได้ในการ ผลักภาระต้นทุนของ Great Firewall หรือไม่
- สุดท้ายจึงต้องเพิ่มกฎบล็อกขนาดใหญ่ที่ครอบคลุม IP มากกว่า 470,000 รายการ
การปรากฏตัวของ Thinkbot
- ระหว่างการวิเคราะห์ทราฟฟิกเว็บ พบว่าเว็บบอตชื่อ Thinkbot มีสัดส่วนติดอันดับต้น ๆ
- สตริง User-Agent มีลักษณะไม่จริงจังดังนี้
“Mozilla/5.0 (compatible; Thinkbot/0.5.8; +In_the_test_phase,_if_the_Thinkbot_brings_you_trouble,_please_block_its_IP_address._Thank_you.)”.
- นอกจากข้อความว่า “ถ้าอยู่ในช่วงทดสอบแล้วสร้างปัญหา โปรดบล็อก IP” แล้ว ยัง ไม่มีแม้แต่ URL อ้างอิง
- มันครอว์ลโดยไม่เคารพไฟล์
robots.txtเลย - แม้ผู้ดูแลเว็บไซต์จะพยายามบล็อก ก็ทำได้ยากเพราะมันไม่ได้ใช้ IP เดียว แต่ใช้ IP address 74 รายการ
- เมื่อตรวจสอบย้อนกลับและค้นหา ASN พบว่าทราฟฟิกมาจาก 41 network block
- นั่นหมายความว่าไม่สามารถป้องกันได้ด้วยการบล็อกแค่ IP เดียว
ความเชื่อมโยงกับ Tencent
- network block ทั้ง 41 รายการนี้เป็น ของ Tencent ทั้งหมด
- ผู้เขียนสงสัยว่ารัฐบาลจีนอาจเพิกเฉยหรือถึงขั้นสนับสนุนเรื่องนี้ และอาจตีความได้ว่าเป็นความพยายาม ผลักภาระต้นทุนของ Great Firewall ไปให้โลกภายนอก
- ภายในจีนยังสามารถเก็บข้อมูลคอนเทนต์ได้ และต่อให้ถูกบล็อกจากภายนอก ในมุมของ CCP ก็ไม่ได้เป็นปัญหา แต่สำหรับประเทศหรือเว็บไซต์อื่นที่พยายามบล็อกกลับต้องเป็นฝ่ายรับภาระ
มาตรการบล็อกด้วยไฟร์วอลล์
- ผู้เขียนได้เพิ่ม Tencent network block เข้าไปใน กฎไฟร์วอลล์ badbots ด้วยตนเอง
- ตัวอย่าง:
43.130.0.0/18,101.32.0.0/20,150.109.96.0/19เป็นต้น - มีการเพิ่ม network block มากกว่า 40 รายการ ซึ่งแม้จะยังไม่ครอบคลุม IP ทั้งหมดที่ Tencent ถือครอง แต่ก็รวม IP ที่ไม่ซ้ำกันมากกว่า 476,590 รายการ
บทสรุปและอุปมา
- ผู้เขียนอธิบายสถานการณ์นี้ว่าเป็นความจริงแบบ “บนอินเทอร์เน็ต เราไม่อาจมีสิ่งดี ๆ ได้อีกต่อไป”
- นี่ไม่ใช่แค่กรณีบล็อกทราฟฟิกบอตธรรมดา แต่เป็นตัวอย่างที่สะท้อนถึง ความเชื่อถือที่ลดลงของระบบนิเวศอินเทอร์เน็ตโดยรวม และการตอบโต้เชิงป้องกันที่หลีกเลี่ยงไม่ได้
6 ความคิดเห็น
อันที่จริงทฤษฎีภัยคุกคามจากจีนได้กลายเป็นความจริงในด้านอื่น ๆ มานานแล้ว แต่ตอนนี้ดูเหมือนว่าจีนกำลังเริ่มคุกคามแม้กระทั่งการดำรงอยู่โดยรวมของระบบนิเวศอินเทอร์เน็ตเองแล้ว
สิ่งนี้ไม่ใช่คำพูดที่เกิดจากอารมณ์ชิงชังหรืออคติทางการเมืองอย่างผิวเผิน แต่ดูเหมือนว่าหลายคนน่าจะต้องตระหนักว่านี่กำลังกลายเป็นความจริงขึ้นมาจริง ๆ
ถ้ามีปัญหาก็บล็อกกันที่ระดับ IP ไปเลย
ทำไมพอขุดดูแล้วเหตุการณ์แบบนี้ทุกครั้งถึงเป็น CCP..
ว้าว.. สุดยอดจริงๆ..
สุดยอด..
จีนอีกแล้วสินะ
ความเห็นจาก Hacker News
ระหว่างพัฒนาเว็บครอว์เลอร์ ผมพยายามทำให้มันเป็นมิตรให้มากที่สุด ตรวจ
robots.txtอย่างเข้มงวด ครอลช้าๆ ระบุตัวตนให้ชัดเจนใน User Agent string และใช้เพียง IP เดียว แต่กลับเจอกลเม็ดป้องกันบอตต่างๆ ที่นำมาใช้แม้กระทั่งกับไฟล์robots.txtเอง ช่วงหลังถึงขั้นเจอrobots.txtดาวน์โหลดช้ามากเหมือนการโจมตีแบบ slow loris จนเผลอถือว่าเป็น 404 แล้วครอลต่อไปโดยไม่ตั้งใจ หลังจากนั้นเลยเปลี่ยนโค้ดให้มองกรณี timeout เป็นDisallow /แทน น่าเสียดายที่ต่อให้ตั้งใจทำตามกติกา ก็ยังลงเอยด้วยการต้องเขียนโค้ดตรวจจับเครื่องมือ anti-bot อยู่ดีรู้สึกเหมือนซ่อนกริ่งหน้าประตูเพื่อกันขโมย
เหมือนฝั่งเซิร์ฟเวอร์แอปพลิเคชัน ฝั่งไคลเอนต์ก็แค่ตัดการเชื่อมต่อ TCP แบบเงียบๆ เมื่ออีกฝ่ายมีพฤติกรรมไม่ดีหรือเป็นอันตราย ปล่อยให้อีกฝ่ายเปลืองทรัพยากรอยู่พักหนึ่งแล้วค่อยรู้ตัวเอง
คิดว่าปรากฏการณ์นี้อาจไม่ได้เกิดขึ้นโดยตั้งใจ เพราะบอตอันตรายที่ไม่สนใจกฎ
robots.txtตั้งแต่แรก ก็มักจะไม่ดาวน์โหลดไฟล์นี้อยู่แล้ว ดังนั้นจึงอาจเป็นความผิดพลาดหรือความไร้ความสามารถ มากกว่าความมุ่งร้ายมาตรการลงโทษที่เล่นงานเฉพาะคนที่พยายามทำตามกฎ น่าจะยิ่งให้ผลตรงข้าม
ชื่นชมความพยายามที่จะทำตามกฎอย่างจริงจัง การจำกัด
robots.txtอาจเป็นความผิดพลาดก็ได้ แต่บางครอว์เลอร์ใช้robots.txtเพื่อหาหน้าที่น่าสนใจกว่า ดังนั้นการทำให้มันช้าลงอาจช่วยเลี่ยงปัญหาได้เร็ว สุดท้ายวิธีแบบนี้ทั้งปิดบังข้อมูลจากบอตและทำให้มันช้าลง ซึ่งจากมุมมองผู้ดูแลเว็บที่โดนบอตอันตรายทำร้ายอยู่ตลอด ก็คงหลีกเลี่ยงไม่ได้ที่จะไม่ใส่ใจมากนักว่าจะแยกระหว่างบอตซื่อสัตย์กับบอตไม่ซื่อสัตย์ได้ดีแค่ไหนสงสัยว่าเว็บไซต์ที่ได้รับความเสียหายหนักจากบอตมีลักษณะร่วมกันอย่างไร ผมเปิดเว็บเซิร์ฟเวอร์เองที่บ้านภายใต้
.comมาหลายปี อันดับ Google สำหรับคีย์เวิร์ดที่เกี่ยวข้องก็ค่อนข้างดี และไม่เคยตั้งค่าบล็อกบอตพิเศษบนเราเตอร์หรือเซิร์ฟเวอร์ เคยนับเฉพาะคำขอจากบอตด้วยความอยากรู้อยากเห็น แต่ส่วนใหญ่ก็มีแค่สแกนพอร์ตหรือดึงหน้า index ไปดู และแทบไม่ตามลิงก์ที่โหลดแบบไดนามิกเลย ไม่ว่าจะสมัย Apache 2 หรือปัจจุบันที่รันหลายไซต์ด้วย Axum ก็ไม่เห็นผลกระทบจากบอตอย่างชัดเจน เลยสงสัยว่าเป็นเพราะ directory listing หรือเปล่า ถ้ามีคำอธิบายก็อยากฟังรู้สึกว่ามีคนฉลาดจำนวนมากหมกมุ่นกับประเด็นเว็บสแครปปิงเกินไป ถ้ากิจกรรมของบอตไม่ได้สร้างภาระหรือปัญหาใหญ่ให้ไซต์จริงๆ มากนัก—ซึ่งแน่นอนว่ามีข้อยกเว้น—ส่วนใหญ่ก็ดูเหมือนเป็นเกม ‘แย่งธง’ ที่ไร้สาระ ความต่างคือสุดท้ายคุณหาธงของอีกฝ่ายไม่เจอ มีแต่เสียเวลา วิธีรับมือที่ดีที่สุดน่าจะเป็นการสร้างเว็บโปรดักต์ที่เร็วและออกแบบมาดี แม้จะมีผู้เล่นที่กระจายตัวและระบุตัวตนยากสร้างภาระอยู่ก็ตาม ในทางปฏิบัติ วิธีนี้ยังช่วยยกระดับความพึงพอใจของผู้ใช้จริงได้มากด้วย
จากประสบการณ์ ผมคิดว่าคุณอาจยังไม่เห็นความร้ายแรงของปัญหานี้ ที่ทำงานเก่าผมดูแลประสิทธิภาพของเว็บแอป ผู้ใช้บางส่วนเร็วมาก แต่ส่วนใหญ่ช้า พอวิเคราะห์ performance log ก็พบว่า 60% ของคำขอทั้งหมดมาจากบอตที่รู้จักกันอยู่แล้ว (ยังไม่รวมบอตแปลกๆ) แถมบางบริษัทถึงขั้นทำ DoS ใส่บริการจนเว็บล่ม ปัญหาคือบอตดึงแต่คำตอบที่ cache ได้ ทำให้บทสนทนาของผู้ใช้จริงถูกไล่ออกจาก LRU cache ตลอด บางบอตกลับมาสแครปทุกหน้าที่เคยเยี่ยมชมใหม่ทุกๆ ไม่กี่นาที บางตัวเร่ง throughput ไปเรื่อยๆ จนบริการเริ่มช้า บางครั้งยังพยายามรัน JavaScript และ submit ฟอร์มด้วย มีแค่ Googlebot ที่ทำตัวสุภาพจริงๆ ทราฟฟิกจริง 40% ดันไปรวมอยู่ที่ URL เดียวด้วยซ้ำ ดังนั้นแทบไม่ได้ประโยชน์อะไรจากบอตเลย กว่าจะมารู้ทีก็พบว่าบอตจำนวนมากเป็นตัวเก็บข้อมูลให้บริษัท AI ยุคแรกๆ
เพื่อนผมดูแลอินสแตนซ์ gitea ขนาดเล็กที่เปิดสาธารณะและใช้กันแค่ในกลุ่มเพื่อน แต่ก็ยังเจอคำขอจากบอตหลายพันครั้งต่อชั่วโมง ถึงจะไม่กระทบบริการโดยตรง อย่างน้อยก็ให้ความรู้สึกเหมือนถูกรังควาน
ผมยอมจ่ายเงินเพื่อให้ได้ข้อมูลไว้สร้างเว็บโปรดักต์ที่เร็ว เพราะงั้นการบล็อกเอนทิตีแบบนี้ไม่ใช่การเสียเวลา แต่ช่วยประหยัดแบนด์วิดท์และค่าเซิร์ฟเวอร์ได้จริง ลูกค้าตัวจริงก็ยังได้ประโยชน์เหมือนเดิมโดยไม่ต้องให้คอนเทนต์ถูกสแครป ผมเลยไม่เข้าใจตรรกะที่บอกว่ากำลังถูกใครสักคนเอาเปรียบ
ผมว่ามันใกล้กับเกมตีตัวตุ่นมากกว่า ‘capture the flag’ จากประสบการณ์ส่วนตัว ในฟอรัมที่พยายามระบุและบล็อก 'บอตไม่ดี' จะมีบอตใหม่โผล่มาเรื่อยๆ ไม่มีวันจบ
พวกเราหลายคนก็ฉลาดจริง แต่ก็มักมีแนวโน้มหมกมุ่นกับปัญหาเชิงเทคนิคมากเกินไป ถ้าไม่ทำอะไรเลยมันก็ยังติดอยู่ในหัว แต่ถ้าได้บล็อกบ้างก็หงุดหงิดน้อยลง
ผมแปลกใจเสมอที่มีคนบน Hacker News จำนวนไม่น้อยที่มอง
robots.txtอย่างจริงจัง น่าประทับใจที่มีคนเจตนาดีอยู่มาก แต่robots.txtไม่ใช่วิธีแก้ปัญหาที่ใช้ได้จริงนัก ผู้คนต้องรู้ก่อนว่าrobots.txtคืออะไร และต้องเพิ่มโค้ดตรวจสอบrobots.txtในครอว์เลอร์ ทำให้เกิดความซับซ้อน เลยสงสัยว่ามีวิธีแก้ที่ใช้งานได้จริงกว่านี้ไหม พวก ‘micropayments’ หรือ ‘Merkle tree ขนาดใหญ่เพื่อยืนยันตัวตนจริง’ ก็ถูกพูดถึงมานานแล้ว แต่ไม่เคยถูกนำไปใช้จริงคิดว่าแทบไม่มีนักพัฒนาบอตคนไหนไม่รู้จัก
robots.txtมีแต่คนที่เข้าใจผิดว่าโปรเจกต์ของตัวเองเป็นกรณีพิเศษที่มีสิทธิ์เมินกฎของทุกคนrobots.txtไม่มีผลบังคับทางกฎหมายใน log ของเราก็เห็นรูปแบบบอตแบบนั้นเหมือนกัน น่ารำคาญพอควร แต่ถึงอย่างนั้นมันก็ยังประกาศตัวว่าเป็นบอตและทราฟฟิกจริงก็ไม่ได้มาก ส่วนทราฟฟิกส่วนใหญ่คือบอตที่แกล้งเป็นเบราว์เซอร์จริง หรือมาจากหลาย IP ในบราซิลและเอเชีย ช่วงสัปดาห์ที่ผ่านมา ผมลองสารพัดวิธีเพื่อบล็อกบอต เลยอยากแชร์ประสบการณ์ที่อาจมีประโยชน์
มีคำขอจากหลายร้อย IP วันละไม่กี่ครั้งต่อ IP แต่ทั้งหมดปลอมตัวเป็น UA จริง
แทบไม่ส่ง referrer URL มาเลย แต่บอตของ Huawei Cloud บางตัวส่ง referrer มาด้วย (แต่ทราฟฟิกไม่มาก)
ความพยายามหลักคือจำกัดแบนด์วิดท์ของ URL ที่มี
id=ให้เหลือ 1Kb/s หวังว่าถ้าช้าลงแล้วบอตจะยอมแพ้ แต่บอตไม่สนใจและยังขอเข้ามาต่อมันยังปรับตัวเข้ากับการเชื่อมต่อ keep-alive ได้ เลยปิด keep-alive ไปเลยใน
/cgit/แต่สุดท้ายมันก็ยึดการเชื่อมต่อทั้งหมดอยู่ดีวิธีที่ใช้อยู่ตอนนี้คือ อนุญาต URL ที่มี
id=เฉพาะเมื่อมี query stringnotbotเท่านั้น ถ้าไม่มี referrer ก็จะตอบ 403 พร้อมข้อความบอกว่าถ้าเป็นผู้ใช้จริงให้เพิ่มพารามิเตอร์notbotวิธีนี้ช่วยลดโหลดและทำให้การเชื่อมต่อของผู้ใช้จริงดีขึ้น แต่บอตก็ยังยิงคำขอมาและรับ 403 ต่อไปสรุปแล้วดูเหมือนจะมีแค่สองทาง คือใช้วิธี ad hoc ที่ออกแบบเฉพาะสำหรับแต่ละไซต์ หรือไม่ก็โยนให้บริการอย่าง Cloudflare ที่มีทรัพยากรเพียงพอจัดการ เพราะโซลูชันมาตรฐานสำหรับบล็อกบอตมีข้อจำกัด เนื่องจากฝั่งที่มีทรัพยากรมากสามารถหลบเลี่ยงหรือแบกรับต้นทุนได้อยู่ดี
อีกวิธีคือบล็อก 403 ล่วงหน้าสำหรับ UA substring ที่แทบไม่มีใครใช้แล้ว เช่น
MSIE 3.0หรือHP-UXจากนั้นก็เก็บ log ของ 403 มาวิเคราะห์และบล็อก ASN ที่มีปัญหาเพิ่มเติม วนเล่นเกมตีตัวตุ่นต่อไปผมใช้ซอฟต์แวร์ตระกูล Bernstein publicfile ของ djbwares และเพิ่มเครื่องมือ static GEMINI UCSPI-SSL เข้าไปด้วย อีกทั้งยืมไอเดียจากสเปก GEMINI มาห้ามทั้ง fragment และ query parameter ใน URL คำขอทั้งหมด เหตุผลก็คือตรรกะเดียวกับที่ GEMINI ห้ามไว้ สามารถนำมาใช้กับบริการ static HTTP ได้เหมือนกัน ถ้าจะรองรับ query parameter ให้ถูกต้องในคอนฟิกเซิร์ฟเวอร์ ต้องสร้างชื่อไฟล์พิเศษหลายแบบแยกกัน ซึ่งในทางปฏิบัติทำได้ยาก ไอเดียนี้ช่วยให้ความพยายามโจมตี CGI หรือช่องโหว่ PHP ไม่ได้แตะ filesystem ตั้งแต่แรก เพราะถูกกรองทิ้งตั้งแต่ขั้นแยกวิเคราะห์คำขอ ผมแนะนำให้ผู้ดูแล static site พิจารณาบล็อก query parameter แบบ GEMINI ด้วย แน่นอนว่าถ้าคุณอยู่ในหมวด static site ที่อยากใช้ query parameter จริงๆ ก็เป็นข้อยกเว้น
เคยสงสัยอยู่พักหนึ่งว่าการใช้ช่วง IP แบบ whitelist จะใช้ได้จริงหรือไม่ และก็นึกภาพแนวทางที่ชุมชนช่วยกันดูแลเหมือนรายการ adblock เหมือนกัน
น่าเสียดายที่ยิ่งเป็นบอตที่ทำตัวดี มักจะยิ่งใช้ IP ที่คงที่ ส่วนผู้ไม่หวังดีก็ใช้ residential proxy ได้ตลอด ถ้าคุณแบน IP ของ residential proxy ก็จะกระทบผู้ใช้จริง ขณะที่ฝั่งไม่หวังดีก็ย้ายไปที่อื่นทันที จากประสบการณ์ที่ต้องรับมือกับหลายพัน IP ข้อมูลระดับ IP อย่างเดียวตัดสินอะไรได้ยาก และต้องมีข้อมูลเพิ่มเติม
บริษัท Pokémon Go ก็เคยลองวิธีนี้เพื่อหยุดการสแครปหลังเปิดตัวไม่นาน โดยแบ่ง IP เป็นสามกลุ่ม: blacklist (
Google Cloud, AWS ฯลฯ), IP ที่ไม่เชื่อถือได้ (ที่อยู่อาศัย), และ whitelist (เช่น IPv4 ปกติที่ดูปกติ) ช่วงแรกจับสแครปเปอร์หลักๆ ได้ แต่สแครปเปอร์รายใหญ่ที่สุดกลับใช้ฟาร์มโมเด็มหลบเลี่ยงได้ ผลคือผู้ใช้ทั่วไปเลิกเล่นเพราะไม่มีแผนที่ ส่วนผู้เล่นฮาร์ดคอร์กลับจ่ายเงินเพื่อใช้สแครปเปอร์มากขึ้น สุดท้ายภาระบนเซิร์ฟเวอร์ยิ่งหนักกว่าเดิม มองว่าเป็นหนึ่งในการตัดสินใจผิดหลายอย่างที่ Pokémon Go เคยทำบริษัทอเมริกันจำนวนมากทำแบบนี้กันอยู่แล้ว แต่ถ้าคุณอยู่ต่างประเทศแล้วพวกเขายังเก็บเงินต่อโดยไม่เปิดทางให้ยกเลิกบริการ แบบนั้นก็ไม่สมเหตุสมผล
whitelist กับ blacklist ไม่จำเป็นต้องเป็นทางเลือกแบบขาวดำเสมอไป ทราฟฟิกส่วนใหญ่อยู่ในพื้นที่สีเทา ถ้าคุณใส่ IP บางตัวไว้ใน whitelist แล้วต่อมาพบสัญญาณผิดปกติ คุณต้องเอามันออกจาก whitelist แจ้งเตือน รับแจ้งกลับ และประสานกันจนเคลียร์ว่าแก้ปัญหาแล้ว ซึ่งในทางปฏิบัติซับซ้อนมาก whitelist จึงได้ผลเฉพาะระหว่างพาร์ตเนอร์ที่มีความสัมพันธ์เชื่อใจกัน ส่วน blacklist มีประโยชน์กับการบล็อกที่อยู่มีปัญหา หรือบล็อก CIA รัสเซีย จีน หรือผู้ให้บริการคลาวด์ แนวทางที่ใช้ได้จริงคือทำ whitelist ให้เฉพาะโฮสต์ภายในองค์กรหรือฝั่งที่มีระบบป้องกันการละเมิดที่แข็งแรงเท่านั้น
ผมกำลังทำ positive bot whitelist ผ่านโอเพนซอร์สโปรเจกต์ GoodBots ยินดีรับ PR มาก
ผมใช้วิธีใส่ custom header ให้กับทุกคำขอ และบล็อกทุกคำขอที่ไม่มี header นี้
ภายนอกใช้ Cloudflare proxy ส่วนภายในวาง Crowdsec กับ Modsecurity CRS ไว้หน้า Traefik หลังจากปรับแต่งเพื่อลด false positive แล้ว ระบบเสถียรมาก ผมส่ง IP ที่ถูกแบนชั่วคราวและ IP ที่ถูกรายงานเข้า Crowdsec แล้วโพสต์ log ลงช่อง Discord เฉลี่ยแล้วบล็อก IP ต่างกันวันละหลายสิบตัว จากความรู้สึกส่วนตัว ความพยายามเข้าถึงทรัพยากรที่ไม่เปิดเผยหรือยิงหา CVE มาจาก IP อเมริกันมากกว่าจีนเสียอีก ผมไม่สนใจการครอลคอนเทนต์สาธารณะ ส่วนอย่างอื่นทั้งหมดเข้าถึงได้ผ่าน SSO หรืออินทราเน็ตเท่านั้น การบล็อกตัวพยายาม exploit หรือ flooding โดยตรง มีประสิทธิภาพกว่าการบล็อกเป็นรายประเทศ
วิธีแบบ Crowdsec ดูน่าสนใจ แต่ผมคิดว่าการส่งทราฟฟิกทั้งหมดของเซิร์ฟเวอร์ไปให้บริษัทแสวงหากำไร เป็นความเสี่ยงใหญ่
ถ้าเป็นความพยายามโจมตีร้ายแรง สุดท้ายก็คงถูกหยุดโดยอะไรอย่าง Cloudflare WAF อยู่แล้ว
อาคารอพาร์ตเมนต์จำนวนมากออกสู่อินเทอร์เน็ตภายนอกได้ผ่าน IP เพียงไม่กี่ตัวเท่านั้น (ดู Carrier-grade NAT)
มากกว่าครึ่งของทราฟฟิกผมมาจากบอตของ Bing, Claude และ Facebook พวกมันไม่ใช่ตัวสร้างทราฟฟิกหลัก แต่กินทรัพยากรเซิร์ฟเวอร์และเป็นสาเหตุหลักเวลาที่เว็บช้าลง (AI, Microsoft และ Facebook มักเมินแม้แต่ common sense) ทราฟฟิกอันตรายจากจีนและที่อื่นๆ เป็นแค่ส่วนหนึ่งของปัญหา ตัวปัญหาจริงคือบริษัทอเมริกันที่ไม่สน
robots.txtหรือ DNS rate limit