เครื่องมือดูส่วนหัว HTTP
วิธีใช้ เครื่องมือดูส่วนหัว HTTP
- 1
ป้อน URL ของเว็บไซต์
พิมพ์ URL แบบเต็มรวม https:// ของเว็บไซต์ที่คุณต้องการตรวจดูเฮดเดอร์
- 2
ดึงเฮดเดอร์
คลิก "ดึงเฮดเดอร์" เพื่อดึง HTTP response header ที่ URL นั้นส่งกลับมา
- 3
ตรวจดูการตอบกลับ
อ่านภาพรวมที่แสดงรหัสสถานะ เวลาตอบกลับ และจำนวนเฮดเดอร์ทั้งหมด จากนั้นกวาดดูรายการชื่อและค่าเฮดเดอร์ทั้งหมด
- 4
คัดลอกเฮดเดอร์ทั้งหมด
ใช้ "คัดลอกเฮดเดอร์ทั้งหมด" เพื่อส่งรายการเฮดเดอร์ทั้งหมดไปยังคลิปบอร์ดสำหรับการดีบักหรือทำเอกสาร
อ่าน HTTP Response Header ให้เป็นเหมือนมืออาชีพ
เฮดเดอร์ HTTP คืออะไร
ทุกครั้งที่เบราว์เซอร์ร้องขอหน้าเว็บ จะมีเมตาดาตาสองชุดเดินทางมาคู่กับเนื้อหาจริง: request header ที่เบราว์เซอร์ส่งไป และ response header ที่เซิร์ฟเวอร์ส่งกลับมา เฮดเดอร์คือคู่ชื่อกับค่าธรรมดา ๆ เช่น Content-Type: text/html ที่บรรยายตัวข้อความ มากกว่าจะเป็นส่วนหนึ่งของหน้าเว็บที่มองเห็นได้ มันควบคุมการแคช ความปลอดภัย การต่อรองเนื้อหา คุกกี้ การ redirect และอีกมากมาย เนื้อหาของหน้าคือสิ่งที่คุณเห็น ส่วนเฮดเดอร์คือคำสั่งที่บอกเบราว์เซอร์ว่าต้องจัดการกับมันอย่างไร
เครื่องมือนี้แสดงเฮดเดอร์ response ที่เซิร์ฟเวอร์ส่งกลับมาสำหรับ URL หนึ่ง ๆ พร้อมกับรหัสสถานะและระยะเวลาที่ใช้ในการตอบกลับ การอ่านมันคือหนึ่งในวิธีที่เร็วที่สุดในการทำความเข้าใจว่าเว็บไซต์ถูกตั้งค่าไว้อย่างไร เพราะพฤติกรรมจำนวนมากที่มองไม่เห็นบนหน้าเว็บ ถูกระบุไว้อย่างชัดเจนในเฮดเดอร์เหล่านั้น
รหัสสถานะ: สิ่งแรกที่ต้องอ่าน
ก่อนถึงเฮดเดอร์ใด ๆ รหัสสถานะจะบอกคุณว่าเกิดอะไรขึ้น ช่วง 200 หมายถึงสำเร็จ โดยมี 200 OK เป็นกรณีปกติ ช่วง 300 หมายถึงการ redirect: 301 คือการย้ายแบบถาวร ส่วน 302 หรือ 307 เป็นการชั่วคราว แต่ละตัวจะมาพร้อมกับเฮดเดอร์ Location ที่ชี้ไปยัง URL ใหม่ ช่วง 400 หมายถึงปัญหาที่ฝั่งไคลเอนต์ เช่น 404 Not Found หรือ 403 Forbidden ขณะที่ช่วง 500 หมายถึงตัวเซิร์ฟเวอร์เองล้มเหลว อย่างเช่น 500 Internal Server Error หรือ 503 Service Unavailable
รหัสสถานะเป็นกรอบให้กับทุกสิ่งที่เหลือ หน้าเว็บที่ดูปกติดีในเบราว์เซอร์แต่กลับคืนค่า 404 หรือข้อผิดพลาดแบบนุ่มนวลให้กับตัวรวบรวมข้อมูลของเครื่องมือค้นหา จะไม่ถูกจัดทำดัชนี และทรัพยากรที่คืนค่า 500 เป็นพัก ๆ ก็เป็นสัญญาณของปัญหาที่เซิร์ฟเวอร์ซึ่งควรค่าแก่การตรวจสอบ การตรวจรหัสสถานะดิบ แทนที่จะเชื่อหน้าเว็บที่เรนเดอร์ออกมา จะช่วยจับปัญหาที่เบราว์เซอร์แอบกลบเกลื่อนไปอย่างเงียบ ๆ ได้
เฮดเดอร์ด้านเนื้อหาและการแคช
Content-Type ประกาศประเภทสื่อและชุดอักขระของ response เช่น text/html; charset=utf-8 หรือ application/json การมี Content-Type ที่ผิดทำให้เบราว์เซอร์จัดการ response ผิดพลาด เช่น เสนอให้ดาวน์โหลดหน้า HTML แทนที่จะแสดงผลมัน Content-Encoding เผยถึงการบีบอัดอย่าง gzip หรือ br (Brotli) ซึ่งยืนยันว่าสินทรัพย์ที่เป็นข้อความกำลังถูกส่งอย่างมีประสิทธิภาพ ส่วน Content-Length บอกขนาดเป็นไบต์
การแคชถูกกำกับเป็นหลักโดย Cache-Control ซึ่งระบุไว้อย่างชัดเจนว่า response อาจถูกแคชได้นานแค่ไหนและที่ใด ด้วยไดเรกทีฟอย่าง max-age, public, private และ no-store ส่วน ETag และ Last-Modified รองรับคำขอแบบมีเงื่อนไข โดยให้เบราว์เซอร์สอบถามได้ว่าสำเนาที่แคชไว้ยังสดใหม่อยู่หรือไม่ และได้รับ 304 Not Modified ที่เบาบางกลับมาเมื่อไม่มีอะไรเปลี่ยนแปลง เฮดเดอร์การแคชที่ตั้งค่าผิดเป็นสาเหตุอันดับต้น ๆ ของทั้งเนื้อหาที่ค้างเก่าและการเยี่ยมชมซ้ำที่ช้าโดยไม่จำเป็น จึงควรค่าแก่การตรวจสอบอย่างใกล้ชิด
เฮดเดอร์ด้านความปลอดภัยที่ควรตรวจ
เฮดเดอร์ response กลุ่มหนึ่งช่วยเสริมเกราะให้เว็บไซต์ต้านทานการโจมตีที่พบบ่อย และการมีอยู่ของมันก็เป็นการตรวจสุขภาพอย่างรวดเร็ว Strict-Transport-Security (HSTS) บังคับให้เบราว์เซอร์ใช้ HTTPS สำหรับการเยี่ยมชมในอนาคต ปิดช่องโหว่ของการโจมตีแบบลดระดับการเชื่อมต่อ Content-Security-Policy (CSP) จำกัดว่าสคริปต์ สไตล์ และทรัพยากรอื่น ๆ ตัวใดบ้างที่อาจถูกโหลดได้ ซึ่งเป็นการป้องกันที่แข็งแกร่งที่สุดต่อการโจมตีแบบ cross-site scripting X-Frame-Options (หรือไดเรกทีฟ frame-ancestors ใน CSP) ป้องกันไม่ให้หน้าเว็บของคุณถูกฝังลงในไอเฟรมที่มุ่งร้าย จึงเอาชนะการโจมตีแบบ clickjacking ส่วน X-Content-Type-Options: nosniff หยุดไม่ให้เบราว์เซอร์เดาประเภทเนื้อหาเอง
เมื่อตรวจสอบเว็บไซต์ การไม่มีเฮดเดอร์เหล่านี้ก็ให้ข้อมูลในตัวมันเองอยู่แล้ว เว็บไซต์ที่ให้บริการเนื้อหาที่อ่อนไหวโดยไม่มี HSTS ไม่มี CSP และไม่มี X-Frame-Options ย่อมมีช่องโหว่ด้านการเสริมเกราะอย่างชัดเจน การดูเฮดเดอร์ทำให้เห็นท่าทีด้านความปลอดภัยได้ในพริบตา ซึ่งมีประโยชน์ทั้งสำหรับเว็บไซต์ของคุณเอง และสำหรับการประเมินบุคคลที่สาม
คุกกี้ CORS และลายนิ้วมือของเซิร์ฟเวอร์
เฮดเดอร์ Set-Cookie แสดงว่าเซิร์ฟเวอร์กำลังฝังคุกกี้อะไรไว้บ้างและด้วยแฟล็กใด แอตทริบิวต์ Secure, HttpOnly และ SameSite บนคุกกี้กำหนดว่ามันจะถูกส่งเฉพาะผ่าน HTTPS เท่านั้น ถูกซ่อนจาก JavaScript และได้รับการปกป้องจากคำขอแบบข้ามไซต์หรือไม่ ดังนั้นการอ่านมันจึงเผยให้เห็นว่าคุกกี้เซสชันถูกตั้งค่าอย่างปลอดภัยหรือไม่ ส่วนเฮดเดอร์ Access-Control-Allow-Origin ซึ่งเป็นส่วนหนึ่งของ CORS จะบอกคุณว่าทรัพยากรหนึ่งอาจถูกร้องขอโดยสคริปต์บนโดเมนอื่นได้หรือไม่และจากที่ใด ซึ่งจำเป็นอย่างยิ่งเมื่อต้องดีบักว่าทำไมการ fetch ฝั่งหน้าบ้านถึงถูกบล็อก
เฮดเดอร์อื่น ๆ เก็บลายนิ้วมือของสแตกเทคโนโลยี Server ระบุชื่อซอฟต์แวร์เว็บเซิร์ฟเวอร์ X-Powered-By อาจเผยเฟรมเวิร์กของแอปพลิเคชัน และ Via หรือ CF-Cache-Status อาจเปิดเผย CDN อย่าง Cloudflare ที่คั่นอยู่หน้าเซิร์ฟเวอร์ต้นทาง ผู้ดูแลระบบจำนวนมากตัดเฮดเดอร์เหล่านี้ทิ้งเพื่อลดการรั่วไหลของข้อมูล ดังนั้นทั้งสิ่งที่มีอยู่และสิ่งที่หายไปอย่างเด่นชัด ต่างก็บอกเล่าเรื่องราวได้ทั้งคู่
ทำไมการตรวจสอบเฮดเดอร์จึงสำคัญต่อ SEO และการดีบัก
เฮดเดอร์หลายตัวส่งผลโดยตรงต่อการค้นหา เฮดเดอร์ X-Robots-Tag บรรจุไดเรกทีฟชุดเดียวกับ robots meta tag เช่น noindex และ nofollow แต่ทำงานในระดับ HTTP ซึ่งทำให้มันเป็นวิธีเดียวที่จะควบคุมการจัดทำดัชนีของไฟล์ที่ไม่ใช่ HTML อย่างไฟล์ PDF ได้ X-Robots-Tag: noindex ที่วางผิดที่และหลงค้างอยู่ในระบบจริงสามารถถอดหน้าเว็บออกจากดัชนีได้อย่างเงียบ ๆ และเพราะมันมองไม่เห็นบนตัวหน้าเว็บเอง การดูเฮดเดอร์ดิบจึงมักเป็นวิธีเดียวที่จะค้นพบมัน เฮดเดอร์ Link ก็สามารถประกาศความสัมพันธ์เชิง canonical จากฝั่งเซิร์ฟเวอร์ได้เช่นกัน
สำหรับการดีบักในชีวิตประจำวัน เฮดเดอร์คือความจริงพื้นฐาน มันยืนยันได้ว่ามีการบังคับใช้ HTTPS หรือไม่ การบีบอัดและการแคชเปิดใช้งานอยู่จริงหรือไม่ การ redirect เป็น 301 อย่างที่คุณตั้งใจไว้แทนที่จะเป็น 302 หรือไม่ และเซิร์ฟเวอร์กำลังคืนรหัสสถานะที่คุณคาดหวังไว้หรือไม่ เพราะเบราว์เซอร์บล็อกไม่ให้สคริปต์อ่านเฮดเดอร์แบบข้ามต้นทาง เครื่องมือนี้จึงดึง URL ผ่าน server proxy เพื่อให้คุณตรวจสอบเฮดเดอร์ response ของหน้าสาธารณะใด ๆ ได้โดยไม่ติดข้อจำกัดเหล่านั้น
คำถามที่พบบ่อย
เครื่องมือนี้จะแสดง HTTP header ใดให้ฉันบ้าง
ทำไม HTTP header จึงมีประโยชน์ต่อ SEO และการดีบัก
ทำไม URL จึงต้องมี https://
ทำไมการดึงข้อมูลอาจคืนข้อผิดพลาด
เครื่องมือนี้ฟรีไหม และ URL ถูกประมวลผลอย่างเป็นส่วนตัวหรือไม่
เครื่องมือที่เกี่ยวข้อง
ทำงานต่อด้วยเครื่องมือที่มีประโยชน์เหล่านี้