ปิง

ปิงเป็นเครื่องมือฟรีสำหรับตรวจสอบว่าเว็บไซต์ เซิร์ฟเวอร์ หรือพอร์ตเข้าถึงได้หรือไม่ พร้อมรายงานเวลาตอบสนอง รหัสสถานะ หรือข้อผิดพลาด

การตรวจสอบด้วยปิงทดสอบอะไรบ้าง?

การตรวจสอบด้วยปิงใช้ทดสอบว่าระบบปลายทางตอบสนองจากเครือข่ายที่ใช้ตรวจสอบหรือไม่ โดยลักษณะการทดสอบจะขึ้นอยู่กับโปรโตคอลที่เลือก

• HTTP(s) ตรวจสอบ URL เว็บผ่าน HTTP หรือ HTTPS เหมาะสำหรับเว็บไซต์ API และบริการเว็บ เพราะสามารถส่งคืนรหัสสถานะการตอบสนอง HTTP ได้
• ปิง (ICMP) ตรวจสอบว่าโฮสต์ตอบสนองต่อทราฟฟิก echo ของ Internet Control Message Protocol หรือไม่ นี่คือความหมายดั้งเดิมของคำว่า "ping" ในงานเครือข่าย
• โฮสต์ / พอร์ต ตรวจสอบว่าสามารถเข้าถึงพอร์ตเครือข่ายที่ระบุบนโฮสต์ได้หรือไม่ ตัวอย่างที่พบบ่อย ได้แก่ เซิร์ฟเวอร์อีเมล SMTP เซิร์ฟเวอร์ POP หรือปลายทางฐานข้อมูล

การตรวจสอบแต่ละแบบตอบคำถามต่างกันเล็กน้อย การได้รับการตอบสนองผ่าน ICMP แสดงว่าโฮสต์ยอมรับและตอบทราฟฟิกเครือข่ายประเภทนั้น แต่ไม่ได้ยืนยันว่าเว็บไซต์หรือบริการอีเมลทำงานอยู่ การตอบสนอง HTTP จะให้รหัสสถานะซึ่งอาจบ่งชี้ถึงข้อขัดข้อง ส่วนการตรวจสอบพอร์ตที่สำเร็จบอกเพียงว่าเข้าถึงพอร์ตได้ ไม่ได้หมายความว่าการเข้าสู่ระบบในระดับแอปพลิเคชันหรือการสืบค้นฐานข้อมูลจะสำเร็จ

ใช้เครื่องมือปิงอย่างไร?

เลือก โปรโตคอล Ping ที่เหมาะสม ป้อนที่อยู่ตามรูปแบบที่โปรโตคอลนั้นต้องการ แล้วเริ่มตรวจสอบ

1. เลือก HTTP(s) และป้อน URL แบบเต็ม เช่น https://www.example.com/status เมื่อต้องการวิเคราะห์ปัญหาเว็บไซต์ ปลายทาง API หรือบริการเว็บ
2. เลือก ปิง (ICMP) และป้อน Host เช่น server.example.com หรือที่อยู่ IP เมื่อต้องการตรวจสอบว่าเซิร์ฟเวอร์ตอบทราฟฟิก ICMP หรือไม่
3. เลือก โฮสต์ / พอร์ต ป้อน Host แล้วระบุ Port เป็นตัวเลข ตัวอย่างเช่น บริการส่งอีเมลผ่าน SMTP มักใช้พอร์ต 587 ส่วน HTTPS มักใช้พอร์ต 443

อย่าใส่พาธ URL ในการตรวจสอบที่รับเฉพาะโฮสต์ ในทางกลับกัน การตรวจสอบ HTTP อาจต้องใช้พาธแบบเต็ม หากปัญหาเกิดขึ้นกับเส้นทาง API หรือหน้าใดหน้าหนึ่ง ไม่ใช่ทั้งโดเมน หมายเลขพอร์ตของโปรโตคอลขนส่งเป็นค่า 16 บิต ตั้งแต่ 0 ถึง 65,535 พอร์ต 0 เป็นพอร์ตที่สงวนไว้และโดยปกติไม่ใช้เป็นพอร์ตบริการ ช่องว่าง เครื่องหมายจุลภาค และข้อความกำกับอย่าง "port 443" ไม่ถือเป็นส่วนหนึ่งของหมายเลขพอร์ต

การตรวจสอบด้วยปิงทำงานบนเซิร์ฟเวอร์ ข้อมูลที่คุณป้อนในปิงจะถูกส่งไปยังเซิร์ฟเวอร์นั้นผ่าน HTTPS และไม่มีการจัดเก็บไว้ หลีกเลี่ยงการใส่รหัสผ่าน คีย์ API หรือข้อมูลลับอื่นใน URL เพราะ URL อาจเปิดเผยข้อมูลเหล่านี้ต่อบริการปลายทางและส่วนอื่นของโครงสร้างพื้นฐานเว็บตามการทำงานปกติ

อ่านผลการปิงอย่างไร?

ดูผลว่าเข้าถึงได้หรือไม่ก่อน จากนั้นใช้เวลาตอบสนอง สถานะ HTTP หรือรายละเอียดข้อผิดพลาดเพื่อจำกัดขอบเขตของปัญหา

ตัวอย่างเช่น ผล HTTP สมมติอาจแสดง ออนไลน์ เวลาตอบสนอง 180 ms และรหัสสถานะ 200 รหัสสถานะ 200 หมายความว่าคำขอสำเร็จ การตอบสนอง 404 หมายความว่าเซิร์ฟเวอร์ต้นทางไม่พบข้อมูลแทนทรัพยากรเป้าหมายที่มีอยู่ในปัจจุบัน หรือไม่ยินยอมเปิดเผยว่าทรัพยากรนั้นมีอยู่ ส่วนการตอบสนอง 5xx (Server Error) อยู่ในกลุ่ม Server Error โดยสาเหตุที่แน่ชัดขึ้นอยู่กับรหัสสถานะนั้น

ผล Down! ไม่ได้หมายความว่าเครื่องทั้งเครื่องออฟไลน์เสมอไป ไฟร์วอลล์อาจบล็อก ICMP ขณะที่ HTTPS ยังทำงาน หรือพอร์ตหนึ่งอาจปิดอยู่ในขณะที่บริการอื่นยังเข้าถึงได้ ให้เลือกการตรวจสอบที่ตรงกับบริการซึ่งผู้ใช้กำลังพยายามเข้าถึง

ปัญหาที่มักตรวจพบได้ด้วยปิง

หากเว็บไซต์เปิดไม่ได้ ให้เริ่มจาก HTTP(s) และใช้ URL ที่มีปัญหาแบบตรงตัว หากโดเมนตอบสนองแต่หน้าหนึ่งส่งคืน 404 ให้ตรวจสอบเส้นทาง กฎ rewrite หรือการนำระบบขึ้นใช้งาน หากเบราว์เซอร์แสดงคำเตือนเกี่ยวกับใบรับรองเมื่อใช้ HTTPS ให้ใช้การค้นหา SSL เพื่อตรวจสอบรายละเอียดใบรับรอง แทนการอาศัยผลปิงเพียงอย่างเดียว ส่วนค้นหาส่วนหัว HTTP สามารถแสดงการเปลี่ยนเส้นทางและส่วนหัวการตอบสนองได้ด้วย

หากอีเมลส่งมาไม่ถึง ให้ใช้ โฮสต์ / พอร์ต พร้อมชื่อโฮสต์ของเซิร์ฟเวอร์อีเมลและพอร์ตที่ตั้งค่าไว้ในแอปพลิเคชันรับหรือส่งอีเมล การเข้าถึงพอร์ต SMTP ได้ไม่ได้ยืนยันว่าเซิร์ฟเวอร์จะยอมรับข้อความใดข้อความหนึ่ง ความล้มเหลวในการยืนยันตัวตน การกรองสแปม ระเบียนอีเมลใน DNS และนโยบายของผู้รับอยู่นอกขอบเขตของการตรวจสอบพอร์ตขั้นพื้นฐาน

หลังย้ายเว็บไซต์ไปยังโฮสต์ใหม่ ให้ตรวจสอบชื่อโฮสต์ด้วย ICMP หรือ HTTP ตามความเหมาะสม ตรวจสอบระเบียน DNS และเผื่อเวลาสำหรับคำตอบที่ถูกแคชไว้ การค้นหา Whois อาจช่วยยืนยันข้อมูลการจดทะเบียนโดเมน แต่ไม่สามารถแสดงได้ว่าตัวแก้ไข DNS ทุกแห่งมีคำตอบใดอยู่ในขณะนั้น

ทำไมแคช DNS จึงทำให้ผลที่ถูกต้องดูเหมือนผิด?

แคช DNS อาจทำให้เซิร์ฟเวอร์ของเครื่องมือและอุปกรณ์ของคุณแปลงชื่อโฮสต์เดียวกันเป็นคนละที่อยู่ชั่วคราว ตัวแก้ไข DNS แบบเรียกซ้ำจะเก็บคำตอบ DNS ตามอายุการใช้งาน ซึ่งมักเรียกว่า TTL และแอปพลิเคชันหรือระบบปฏิบัติการบางส่วนก็มีแคชภายในเครื่องด้วย

คนทั่วไปมักใช้คำว่า "Propagation" เรียกความล่าช้านี้ แม้ระเบียน DNS จะไม่ได้กระจายไปทุกแห่งพร้อมกันผ่านกระบวนการเดียว แคชแต่ละแห่งจะหมดอายุตามเวลาของตัวเอง ดังนั้นระเบียนที่เพิ่งเปลี่ยนอาจใช้ได้กับการเชื่อมต่อหนึ่ง ขณะที่อีกการเชื่อมต่อยังคงใช้ที่อยู่เดิม

เนื่องจากเครื่องมือนี้ตรวจสอบบนเซิร์ฟเวอร์ ผลลัพธ์จึงสะท้อนเส้นทางเครือข่ายและมุมมอง DNS ของเซิร์ฟเวอร์นั้น ณ เวลาที่ตรวจสอบ ผลดังกล่าวไม่สามารถยืนยันได้ว่าผู้ให้บริการบรอดแบนด์ เครือข่ายมือถือ หรือตัวแก้ไข DNS ขององค์กรทุกแห่งในไทยเห็นปลายทางเดียวกัน หากพฤติกรรมแตกต่างกันตามตำแหน่งที่ตั้ง ให้เปรียบเทียบผลกับการตรวจสอบจากอุปกรณ์ของคุณและสืบค้นระเบียน DNS ที่เกี่ยวข้อง

คำถามที่พบบ่อย

ชื่อโดเมนที่มีเครื่องหมายกำกับเสียงหรือใช้อักษรที่ไม่ใช่ละตินจะเป็นอย่างไร?

IDNA จะแปลงป้ายชื่อโดเมน Unicode ที่เข้าเกณฑ์เป็น A-label แบบ ASCII ส่วน Punycode คืออัลกอริทึมการเข้ารหัสที่ใช้ภายใน A-label ที่เกี่ยวข้อง เบราว์เซอร์มักแปลงรูปแบบที่คนอ่านได้ให้อัตโนมัติ แต่ช่องโฮสต์และระบบวิเคราะห์ปัญหาบางระบบอาจต้องใช้รูปแบบ A-label ตรวจสอบการสะกดอย่างละเอียด เพราะอักขระ Unicode ที่ดูคล้ายกันอาจอ้างถึงคนละโดเมน

เวลาตอบสนองต่ำจะต่ำแบบเดิมตลอดไปไหม?

ไม่ เวลาตอบสนองเปลี่ยนแปลงได้ตามเส้นทางเครือข่าย ความหนาแน่นของทราฟฟิก ภาระของเซิร์ฟเวอร์ และระยะทางทางกายภาพ ควรบันทึกผลจากการตรวจสอบหลายครั้งในช่วงเวลาที่ใกล้เคียงกัน และตรวจสอบการเปลี่ยนแปลงที่เกิดต่อเนื่อง แทนที่จะถือว่าการตอบสนองช้าเพียงครั้งเดียวเป็นหลักฐานว่าระบบขัดข้อง

ก่อนแก้ไขการตั้งค่า DNS ไฟร์วอลล์ หรือเซิร์ฟเวอร์ ให้ยืนยันว่าได้ตรวจสอบชื่อโฮสต์ พาธ URL และพอร์ตที่บริการซึ่งมีปัญหาใช้งานจริง บันทึกเวลาของผลลัพธ์ไว้และเปรียบเทียบกับบันทึกเหตุการณ์ในระบบของคุณ เพื่อให้จับคู่ข้อมูลจากทั้งสองฝั่งของการเชื่อมต่อได้