วิเคราะห์ล็อกเว็บไซต์อิสระ: อ่านค่า bot, error และทราฟฟิกจากล็อก Nginx/Apache
1. ทำไมดูแค่ “ยอดเข้าชมรวม” ไม่ได้
เว็บมาสเตอร์หลายคนเปิดล็อกแล้วถามทันทีว่า “วันนี้มีคำขอกี่รายการ” แล้วตัดสินว่าธุรกิจดีหรือไม่ นี่คือกับดักแรก: ใน access.log เริ่มต้นของ Nginx หนึ่งบรรทัดคือหนึ่ง HTTP request คนจริงเปิดหน้าแรกครั้งเดียวอาจสร้าง 8 ถึง 15 คำขอ (HTML, CSS, JS, รูปภาพ นับแยกกันคนละรายการ) แต่ bot ที่เป็นอันตรายตัวเดียวสามารถยิงได้เป็นพันรายการในหนึ่งนาที ยอดรวมแทบไม่มีประโยชน์ต่อการตัดสินใจ
ข้อสรุปที่ขัดกับสัญชาตญาณอยู่ตรงนี้:ยอดเข้าชมที่ “พุ่งพรวด” ของคุณ แปดในสิบคือ bot ตัวใดตัวหนึ่งเริ่มดูดเว็บคุณหนักๆ ไม่ใช่มีลูกค้าเข้ามา เกณฑ์ตัดสินง่ายมาก — แยกข้อมูลในล็อกตาม User-Agent แล้วดูว่า 20 อันดับแรกของแหล่งคำขอคือใคร ถ้ามากกว่าครึ่งมาจาก UA ประเภท bot การพุ่งครั้งนี้ไม่เกี่ยวข้องกับธุรกิจของคุณเลย สอดคล้องกับแนวคิดของ การวิเคราะห์ log ของ AI crawler ที่ว่า แยกให้ออกก่อนว่า “ใครกำลังอ่านคุณ” แล้วค่อยพูดถึง “อ่านไปเท่าไหร่”
| ฟิลด์ในล็อก (Nginx combined) | ความหมาย | ใช้วิเคราะห์ |
|---|---|---|
| $remote_addr | IP ต้นทาง | ระบุ IP ของดาต้าเซ็นเตอร์, การสแกนที่เป็นอันตราย, เจ้าของ bot |
| $request | เมธอดคำขอ + พาธ + โปรโตคอล | ดูว่าเข้าถึง URL ใดจริง และไฟล์ใดถูกยิงถี่ |
| $status | HTTP status code | 200 ปกติ, 301 เปลี่ยนเส้นทาง, 404 ลิงก์เสีย, 5xx ขัดข้อง |
| $body_bytes_sent | จำนวนไบต์ที่ส่งกลับ | ระบุการตอบกลับว่างเปล่า, การดาวน์โหลดผิดปกติที่ถูกบล็อก |
| $http_referer | หน้าต้นทาง | คนจริงคลิกเข้ามาจากลิงก์ใด |
| $http_user_agent | ตัวระบุไคลเอนต์ | แยกเบราว์เซอร์, bot ของเสิร์ชเอนจิน, bot ของ AI |
2. วิธีอ่าน: สัญญาณ 3 ประเภท bot, error และทราฟฟิกคนจริง
ลำดับการวิเคราะห์ที่แนะนำคือ “error → bot → คนจริง” ตายตัว อย่ากลับกัน เหตุผลคือ error ส่งผลต่อประสบการณ์ของคนจริงโดยตรง จึงมีความสำคัญสูงสุด ปริมาณ bot กำหนดงบประมาณการเก็บข้อมูลและต้นทุนแบนด์วิดท์ ทราฟฟิกคนจริงเป็นส่วนสุดท้ายที่ควรเจาะลึก นี่ก็เป็นเหตุผลที่การมอนิเตอร์และแจ้งเตือนเว็บไซต์ จัดความพร้อมใช้งานและอัตรา error ไว้ในระดับแรก
爬虫识别不要只看 UA，因为恶意爬虫会伪造 UA 冒充 Googlebot。标准做法是双向验证：对自称 Googlebot 的 IP 做反向 DNS，确认它真的来自 googlebot.com 网段，再正向解析回去比对。伪造的爬虫过不了这一步。
| ประเภทสัญญาณ | ช่วงสุขภาพดี | เกณฑ์ที่ต้องเข้าไปจัดการ | การดำเนินการ |
|---|---|---|---|
| อัตราข้อผิดพลาด 5xx | ต่ำกว่า 0.5% | เกิน 1% ติดต่อกัน 10 นาที | ตรวจ PHP-FPM กับ log ฝั่ง backend ทันที |
| สัดส่วน 404 | ต่ำกว่า 3% | URL เดียว 404 เกิน 100 ครั้ง/วัน | เพิ่ม 301 หรือแก้ลิงก์ภายใน |
| สัดส่วนคำขอจากบอทน่าสงสัย | 20% ถึง 40% | เกิน 60% และ bandwidth ตึง | จำกัดด้วย robots หรือ WAF |
| จำนวนเซสชันคนจริง | ทรงตัวเมื่อเทียบสัปดาห์ก่อน | ลดลงเกิน 20% ติดต่อกัน 2 สัปดาห์ | ตรวจการ index กับโฆษณา ไม่ใช่ปัญหาที่เซิร์ฟเวอร์ |
| สัดส่วนการอ่านของบอท AI | 5% ถึง 15% ถือว่าปกติ | พุ่งขึ้นเกิน 3 เท่า | ดูว่าถูกดึงไปเทรนแบบเป็นชุดหรือไม่ |
สาม วิธีทำจริง: จากคำสั่งเดียวถึงรายงานรายสัปดาห์
ทีมคนเดียวไม่จำเป็นต้องใช้แพลตฟอร์มวิเคราะห์ log ราคาแพง เครื่องมือขั้นต่ำมีสามอย่าง: GoAccess ทำรายงานรายสัปดาห์แบบเห็นภาพ, awk นับสถิติรายชั่วโมง, และตรวจสอบทั้งหมดด้วยคนเดือนละครั้ง ด้านล่างคือสองสถานการณ์ที่ใช้ได้เลย
สถานการณ์ที่หนึ่ง: หา URL ที่ error มากที่สุดของวันนี้ รันในโฟลเดอร์ log ของ Nginx: awk ‘$9 ~ /^5/ {print $7}’ access.log | sort | uniq -c | sort -rn | head -20 คำสั่งนี้ดึง path ของทุกคำขอ 5xx ออกมา เรียงตามจำนวนครั้งที่เกิด 20 อันดับแรกคือหน้าที่คุณควรแก้ที่สุดของวันนี้
สถานการณ์ที่สอง: ดูว่าวันนี้ Google กับบอท AI เข้ามากี่ครั้ง awk ‘BEGIN{IGNORECASE=1} /Googlebot|GPTBot|ClaudeBot|bingbot/ {print $http_user_agent}’ access.log | sort | uniq -c | sort -rn แยกผลลัพธ์ตาม UA ก็จะเห็นสัดส่วนระหว่างบอทเก็บข้อมูลปกติของ Google กับบอทอ่านข้อมูลของ AI แต่ละเจ้า เว็บที่มี CDN ต้องดึง log ต้นทางไม่ใช่ log ที่ edge เรื่องนี้ดูใน CDN เร่งความเร็วทั่วโลก หัวข้อความต่างระหว่างการดึงต้นทางกับแคช
สถานการณ์ที่สาม: ทำรายงานรายสัปดาห์ให้เจ้าของเว็บเอง เมื่อรัน GoAccess แล้วให้สร้างรายงาน HTML รายสัปดาห์ ดูตัวเลขสี่กลุ่มเป็นหลัก: การกระจาย status code ว่า 4xx กับ 5xx อย่างละเท่าไร, สิบ URL ที่ถูกเรียกมากที่สุด, กราฟทราฟฟิกรายชั่วโมง, และสัดส่วนบอทแยกตาม UA ตั้งเวลาดูรายงานนี้ทุกเช้าวันจันทร์จะได้ผลกว่าการเปิด log ดูแบบครั้งคราวมาก นิสัยที่ควรสร้างคือจดความผิดปกติที่เจอแต่ละครั้งลงตารางเล็กๆ พอผ่านไปสามเดือนย้อนดูจะเห็นรูปแบบ
| ความถี่ | การดำเนินการ | ผลลัพธ์ | เวลา |
|---|---|---|---|
| ทุกวัน | กวาดตาดูแดชบอร์ดอัตราข้อผิดพลาด 5xx | ตัดสินว่ามีปัญหาหรือไม่ | 2 นาที |
| ทุกสัปดาห์ | GoAccess ออกรายงานสัปดาห์ที่แล้ว | path ยอดนิยม, บอทยอดนิยม, การกระจาย status code | 10 นาที |
| ทุกเดือน | ตรวจ 404 กับ UA ผิดปกติทั้งหมด | รายการลิงก์เสีย, รายการ IP ที่ต้องบล็อก | 1 ชั่วโมง |
| ทุกไตรมาส | ปรับนโยบายการเก็บและตัด log | ยืนยันว่าดิสก์ไม่เต็มและย้อนดูข้อมูลเก่าได้ | 30 นาที |
สี่ ข้อควรระวัง: สามความเข้าใจผิดที่พบบ่อยที่สุด
第一个坑是把 200 全等于正常。有些插件被恶意扫描器打，返回的是 200 加一段伪装页面，状态码正常但内容被换。这种要结合”返回字节数异常小”或”URL 出现了不该出现的参数”来判断，严重时按 หลังเว็บไซต์ถูกแฮก ขั้นตอนนี้
ข้อผิดพลาดที่สองคือดูแค่เรียลไทม์ ไม่เก็บประวัติ ถ้าไม่จัดการ log ตามนโยบายการตัดและเก็บรักษา ดิสก์อาจเต็มหรือสามเดือนต่อมาอยากเช็กว่า “เหตุขัดข้องเมื่อเดือนมีนาคมเริ่มตอนไหนกันแน่” ก็หาข้อมูลไม่เจอ แนะนำให้ตัดรายวัน เก็บข้อมูลร้อน 90 วัน เกินนั้นบีบอัดเก็บถาวร
ข้อผิดพลาดที่สามคือเอาการเข้าถึงของบอทมาเป็นผลงาน SEO Googlebot เข้ามาหมื่นครั้งไม่ได้แปลว่าอันดับดี แค่บอกว่ามันกำลังเก็บซ้ำ ๆ สิ่งที่เกี่ยวกับ SEO จริง ๆ คือ “หน้าสำคัญถูกเก็บปกติหรือไม่” ต้องดูเทียบกับข้อมูลการจัดทำดัชนี ไม่ใช่ชมปริมาณบอทอย่างเดียว ความสัมพันธ์ระหว่างประสิทธิภาพและการเก็บ ดูที่Core Web Vitals ผลต่อความสมบูรณ์ของการเก็บของสไปเดอร์
| ตีความผิด | อาการที่เห็น | สาเหตุที่แท้จริง | วิธีตรวจสอบที่ถูกต้อง |
|---|---|---|---|
| ทราฟฟิกพุ่งคือเรื่องดี | จำนวนคำขอเพิ่มสามเท่า | บอทตัวหนึ่งเริ่มเก็บหนัก | ดูสัดส่วนคนจริงโดยแยกตาม UA |
| เป็น 200 หมดก็สุขภาพดี | รหัสสถานะปกติทั้งหมด | ถูกฝังมัลแวร์แล้วตอบหน้าเว็บปลอม | สุ่มตรวจการตอบกลับที่เล็กผิดปกติและพารามิเตอร์น่าสงสัย |
| Google เก็บเยอะ=อันดับดี | คำขอ Googlebot สูง | กำลังเก็บหน้าคุณภาพต่ำซ้ำ ๆ | เทียบปริมาณการจัดทำดัชนีกับอันดับจริง |
| 404 ปล่อยไว้ได้ | สัดส่วนดูไม่สูง | ลิงก์เก่าค่อย ๆ เสียน้ำหนัก | TOP 404 ใส่ 301 ไปหน้าใหม่ที่ตรงกัน |
FAQ คำถามที่พบบ่อย
รูปแบบ log ของ Nginx กับ Apache ต่างกันอย่างไร วิธีวิเคราะห์ใช้ร่วมกันได้ไหม?
แยก Googlebot ตัวจริงกับบอทปลอมอย่างไร?
ควรเก็บ log นานแค่ไหนจึงจะพอ?
404 error ต้องจัดการทั้งหมดหรือไม่
หลังใช้ CDN แล้ว log ของเซิร์ฟเวอร์ยังแม่นอยู่ไหม
เห็น GPTBot กับ ClaudeBot กำลัง crawl ใน log เป็นเรื่องดีหรือเรื่องร้าย
ทิ้งท้าย
คุณค่าของการวิเคราะห์ log ไม่ได้อยู่ที่ “ดูทราฟฟิก” แต่อยู่ที่ “หาสาเหตุและแยกแยะคน” สำหรับเว็บไซต์อิสระที่ทำคนเดียว การรันรายงานสัปดาห์ละสิบนาที และตรวจสอบแบบเต็มรูปแบบเดือนละหนึ่งชั่วโมง ก็เพียงพอครอบคลุมปัญหาที่พบบ่อย 90% แล้ว ตรงไหน error ตรงไหนมี dead link bot ตัวไหนกำลังกัดแบนด์วิดท์ของคุณ และคนจริงมาจากไหนกันแน่
ลงมือทำสามขั้น ขั้นแรก รวมรูปแบบ log ให้เป็น combined ตัดไฟล์รายวันและเก็บไว้ 90 วัน ขั้นที่สอง เฝ้าดูอัตรา error 5xx ถ้าเกิน 1% ให้แจ้งเตือนก่อน แล้วค่อยจัดการ TOP 404 ขั้นที่สาม แยกสถิติ bot กับคนจริงออกจากกัน เลิกใช้ยอดเข้าชมรวมหลอกตัวเอง สำหรับจังหวะการดูแลเว็บไซต์ที่เกี่ยวข้อง เทียบกับ ช่วงดูแลเว็บไซต์ รายการหกเรื่องต่อเดือนในนั้นแล้วจัดตารางไปพร้อมกัน
ประโยคที่จำได้ติดปาก: log ของเซิร์ฟเวอร์ไม่ใช่แดชบอร์ดทราฟฟิก แต่เป็นวิดีโอเหตุการณ์ ณ ที่เกิดเหตุ ก่อนอื่นหาว่ารถชนตรงไหน แล้วค่อยนับว่ามีรถวิ่งบนถนนกี่คัน