ไล่หาปัญหาเครือข่ายด้วย ping, traceroute และ mtr

เมื่อผู้ใช้แจ้งว่า "เข้าเว็บช้า" หรือ "บางครั้งเข้าไม่ได้" คำถามที่ต้องตอบให้ได้ก่อนคือปัญหาอยู่ที่ไหน ที่เครื่องปลายทาง ที่เส้นทางระหว่างกลาง หรือที่ฝั่งผู้ใช้เอง การเดาโดยไม่วัดมักทำให้แก้ผิดจุดและเสียเวลาเป็นวัน

คู่มือนี้ใช้เครื่องมือสามตัวที่มีอยู่แล้วในทุกเครื่อง ไล่จากง่ายไปละเอียด พร้อมอธิบายจุดที่คนอ่านผลผิดบ่อยที่สุด โดยเฉพาะเรื่อง Packet Loss ที่เห็นในกลางทางแต่ไม่ได้แปลว่ามีปัญหาจริง

สิ่งที่ต้องเตรียม

• สิทธิ์ SSH เข้าเซิร์ฟเวอร์ หรือ Terminal บนเครื่องที่ใช้งาน
• ชื่อโดเมนหรือ IP ปลายทางที่มีปัญหา

# Ubuntu / Debian
sudo apt install -y iputils-ping traceroute mtr-tiny dnsutils

# AlmaLinux / Rocky Linux
sudo dnf install -y iputils traceroute mtr bind-utils

ขั้นตอนที่ 1: แยก DNS ออกจากปัญหาก่อน

ปัญหาจำนวนมากที่ดูเหมือนเครือข่ายช้า จริง ๆ แล้วคือ DNS ที่ตอบช้าหรือตอบผิด ทดสอบแยกก่อนเสมอ

dig +short example.com
dig example.com | grep 'Query time'
dig @8.8.8.8 example.com +short

ถ้า Query time สูงกว่า 100 ms เป็นประจำ หรือผลจาก DNS ของเครื่องต่างจากผลของ 8.8.8.8 ให้แก้ที่ DNS ก่อน ตรวจว่าเครื่องใช้ Resolver ตัวไหนอยู่

resolvectl status | head -20
cat /etc/resolv.conf

ขั้นตอนที่ 2: ping เพื่อดูว่าถึงกันหรือไม่และหน่วงเท่าไร

ping -c 20 example.com

ดูสามค่าท้ายผลลัพธ์

• packet loss ควรเป็น 0% การสูญหายแม้เพียง 1-2% ก็ทำให้ TCP ต้องส่งซ้ำและเว็บช้าอย่างรู้สึกได้
• rtt avg เวลาไปกลับเฉลี่ย ในประเทศไทยควรต่ำกว่า 30 ms ไปสิงคโปร์ราว 30-50 ms ไปยุโรปหรืออเมริกา 150-250 ms
• rtt mdev ความแกว่งของเวลา ถ้าค่านี้สูงใกล้เคียงกับ avg แปลว่าเส้นทางไม่นิ่ง ซึ่งกระทบงานที่ต้องการความต่อเนื่อง เช่น SSH หรือ VoIP มากกว่าค่าเฉลี่ยที่สูงแต่นิ่ง

ถ้า ping ไม่ตอบเลย อย่าเพิ่งสรุปว่าเครื่องดับ เซิร์ฟเวอร์จำนวนมากปิดการตอบ ICMP ไว้ ให้ทดสอบที่พอร์ตจริงแทน

nc -vz example.com 443
curl -I https://example.com

ขั้นตอนที่ 3: traceroute เพื่อดูเส้นทาง

traceroute example.com
traceroute -T -p 443 example.com

แบบที่สองใช้ TCP ไปที่พอร์ต 443 ซึ่งมักผ่าน Firewall ได้ดีกว่าแบบปกติ จึงเห็นเส้นทางครบกว่า

สิ่งที่ต้องดูคือ เส้นทางขาดตอนไหน และ เวลากระโดดขึ้นที่ hop ไหน เช่น หาก hop ที่ 1-5 อยู่ที่ 2 ms แล้ว hop ที่ 6 กระโดดเป็น 180 ms แปลว่าออกนอกประเทศที่จุดนั้น ซึ่งเป็นเรื่องปกติหากปลายทางอยู่ต่างทวีป

ขั้นตอนที่ 4: mtr เพื่อดูภาพต่อเนื่อง

ปัญหาเครือข่ายส่วนใหญ่เป็นแบบเป็นช่วง ๆ การยิง traceroute ครั้งเดียวจึงมักไม่เจอ mtr รวม ping กับ traceroute เข้าด้วยกันและวัดต่อเนื่อง

mtr -rwzbc 100 example.com

ความหมายของตัวเลือก -r พิมพ์รายงานแล้วจบ -w แสดงชื่อโฮสต์แบบเต็ม -z แสดงหมายเลข AS ของผู้ให้บริการแต่ละ hop -b แสดงทั้งชื่อและ IP และ -c 100 คือยิง 100 รอบ

ปล่อยให้รันจนครบ ยิ่งจำนวนรอบมากยิ่งเชื่อถือได้ สำหรับปัญหาที่เกิดเป็นช่วง แนะนำให้รันแบบต่อเนื่องนาน ๆ ด้วย mtr -c 1000 example.com

ขั้นตอนที่ 5: อ่านผล mtr ให้ถูกต้อง

นี่คือส่วนที่คนตีความผิดมากที่สุด กฎสามข้อที่ต้องจำ

• Packet Loss ที่เห็นกลางทางแต่หายไปใน hop ถัดไป ไม่ใช่ปัญหา เราเตอร์กลางทางจำนวนมากตั้งค่าให้ลดความสำคัญของการตอบ ICMP เมื่อตัวเองยุ่ง แต่ยังส่งต่อแพ็กเก็ตจริงครบถ้วน ถ้า hop ที่ 5 แสดง Loss 40% แต่ hop ที่ 6 ถึง 12 แสดง 0% แปลว่าเส้นทางไม่มีปัญหา
• Loss ที่มีปัญหาจริงต้องต่อเนื่องไปจนถึง hop สุดท้าย หากเริ่ม Loss ที่ hop 7 แล้ว hop 8, 9 และปลายทางก็ Loss ในระดับใกล้เคียงกัน แปลว่าปัญหาเริ่มที่ hop 7 จริง
• เวลาที่กระโดดขึ้นแล้วคงที่ต่อไป คือระยะทาง ไม่ใช่ปัญหา แต่เวลาที่กระโดดขึ้นแล้วลดลงใน hop ถัดไปคือความผิดปกติของการตอบ ICMP เท่านั้น

คอลัมน์ StDev ที่สูงคือสัญญาณของเส้นทางที่ไม่นิ่ง ซึ่งมักสร้างปัญหามากกว่าเวลาเฉลี่ยที่สูง

ขั้นตอนที่ 6: ทดสอบสองทิศทาง

เส้นทางขาไปกับขากลับบนอินเทอร์เน็ตไม่จำเป็นต้องเหมือนกัน หากพบปัญหา ให้รัน mtr จากทั้งสองฝั่ง

# จากเครื่องคุณไปเซิร์ฟเวอร์
mtr -rwzbc 100 203.0.113.10

# SSH เข้าเซิร์ฟเวอร์แล้วยิงกลับมาที่ IP ขาออกของคุณ
mtr -rwzbc 100 198.51.100.25

ผลทั้งสองชุดคือสิ่งที่ผู้ให้บริการเครือข่ายต้องการเวลารับแจ้งปัญหา แนบไปพร้อมเวลาที่เกิดเหตุและ Timezone ด้วยเสมอ

ขั้นตอนที่ 7: ตรวจฝั่งเครื่องตัวเองก่อนโทษเส้นทาง

ip -s link show
ip route
ss -s

ใน ip -s link ให้ดูค่า errors และ dropped ของการ์ดเครือข่าย ถ้าตัวเลขเพิ่มขึ้นเรื่อย ๆ ปัญหาอยู่ที่เครื่องหรืออุปกรณ์ ไม่ใช่เส้นทาง ตรวจว่ามีการจำกัดแบนด์วิดท์หรือ Firewall ที่ทิ้งแพ็กเก็ตอยู่หรือไม่

sudo nft list ruleset | grep -i drop
sudo journalctl -k --since '1 hour ago' | grep -i -E 'drop|reject'

ปัญหาที่พบบ่อย

ping ได้แต่เปิดเว็บไม่ขึ้น

เครือข่ายถึงกันแล้ว ปัญหาอยู่ที่ชั้นบริการ ตรวจว่าโปรแกรมฟังพอร์ตอยู่จริงด้วย sudo ss -tlnp และตรวจ Firewall ทั้งบนเครื่องและที่ผู้ให้บริการ

traceroute แสดง * * * ตลอดตั้งแต่ hop กลาง

เป็นเรื่องปกติ เราเตอร์หลายตัวไม่ตอบ ICMP ให้ลองแบบ TCP ด้วย traceroute -T -p 443 ซึ่งมักได้ผลครบกว่า

ช้าเฉพาะบางเว็บ บางเว็บปกติ

มักเป็นเส้นทางเฉพาะปลายทางนั้นหรือ CDN ที่จับคุณไปยัง Node ที่ไกล ตรวจ IP ที่ปลายทางตอบกลับด้วย dig +short แล้วดูว่า mtr ไปทางไหน

ช้าเฉพาะช่วงเย็น

เป็นลักษณะของเส้นทางที่แออัดตามชั่วโมงการใช้งาน เก็บผล mtr ทั้งช่วงที่ปกติและช่วงที่ช้า แล้วส่งให้ผู้ให้บริการเปรียบเทียบ

หากผลชี้ว่าปัญหาอยู่ที่เส้นทางเข้าสู่เซิร์ฟเวอร์ ส่งผล mtr ทั้งสองทิศทางมาที่ทีมงาน THAI DATA CLOUD ได้ที่ https://thaidata.cloud/contact/