คู่มือ Debug HTTP Response แบบมืออาชีพ · Dev365TH เรียนออนไลน์

เคยไหมที่โค้ดของคุณรันได้ปกติสุดๆ ในเครื่อง Local แต่พอขึ้นไปบน Server จริง กลับเจอแค่หน้าจอขาวหรือ Error 500 ที่ไม่บอกอะไรเลย? การเขียนเว็บไม่ใช่แค่ทำให้โค้ดรันได้ แต่คือการทำให้มันสื่อสารกันได้ถูกต้องผ่าน HTTP

หากคุณเคยเจอปัญหาที่ Frontend ดึงข้อมูลจาก Backend ไม่ได้ แต่ไม่รู้จะเริ่มตรวจสอบยังไง บทความนี้คือคำตอบ เราจะมาเจาะลึกการทำ HTTP response header debug แบบมืออาชีพ ไม่ใช่แค่ดู Status Code แล้วเดา แต่รู้วิธีอ่านข้อมูลที่ซ่อนอยู่และแก้ปัญหาแบบเห็นผลจริง

ทบทวน Status Code สั้นๆ ให้พร้อม

ก่อนจะลงลึก เรามาทบทวนสัญญาณที่ Server ส่งกลับมากันสั้นๆ แต่เน้นๆ ว่ามันคืออะไรจริงๆ:

2xx (Success): ทุกอย่างเป็นไปได้ด้วยดี โดยเฉพาะ 200 OK และ 201 Created
3xx (Redirection): ข้ามไปหน้าอื่น เช่น 301 Moved Permanently หรือ 304 Not Modified (สำคัญมากเวลาทำแคช)
4xx (Client Error): ฝั่ง Frontend หรือ Client ส่งของมาผิด เช่น 401 Unauthorized (ไม่มีบัตร) หรือ 403 Forbidden (มีบัตรแต่ไม่มีสิทธิ์เข้า)
5xx (Server Error): Backend พังหรือเจอปัญหาหนักๆ เช่น 500 Internal Server Error หรือ 502 Bad Gateway

Status Code เป็นแค่ไฟเล็กๆ ที่บอกว่ามีปัญหา แต่สาเหตุจริงๆ มักซ่อนอยู่ใน Response Header

อ่าน Response Header ให้ออก: CORS กับ Cache-Control

หัวใจสำคัญของการทำ HTTP response header debug คือการรู้ว่าแต่ละบรรทัดใน Header มันพยายามบอกอะไรเรา ลองมาดู 2 ตัวที่เจอบ่อยและเจ็บบ่อยที่สุด

ปัญหาคลาสสิกที่นักพัฒนาทุกคนต้องเจอ ตอนที่ Frontend ฝั่ง http://localhost:3000 ยิง API ไปหา Backend ฝั่ง http://localhost:8000 แล้วเจอ Error ใน Console ว่า "Blocked by CORS policy"

ถ้าดูแค่ Status Code คุณอาจเห็น 200 OK หรือบางครั้งเห็นเป็น Error ฝั่ง Browser แต่จริงๆ แล้ว Server อาจจะตอบกลับมาพร้อม Header ประมาณนี้:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST
Access-Control-Allow-Headers: Content-Type

ถ้า Header เหล่านี้หายไป หรือค่าไม่ตรงกับ Origin ของฝั่ง Frontend (เช่น ตั้งไว้เป็น https://a.com แต่ยิงมาจาก https://b.com) Browser จะบล็อกการอ่าน Response ทันที การดู Header นี้ใน DevTools คือกุญแจสำคัญที่จะบอกว่า Backend ของเราตั้งค่าผิดตรงไหน

Cache-Control

อีาคำสั่งที่ทำให้หลายคนปวดหัวเวลาแก้บั๊กแล้วดัน "ไม่เห็นอัปเดต" ลองสังเกต Header นี้:

Cache-Control: max-age=3600

ถ้าคุณแก้โค้ดที่ Backend แล้วรีเฟรชหน้าเว็บ แต่ข้อมูลยังเป็นของเดิม อย่าเพิ่งด่าตัวเอง ลองเช็คดูว่า Browser มันไปดึงข้อมูลจากแคชมาแสดงหรือไม่ การตั้งค่า max-age หรือ no-cache ผิดๆ ถูกๆ สามารถทำให้เกิดบั๊กหลอนตาได้ง่ายๆ

ใช้ Browser DevTools ตรวจสอบ HTTP Response

เครื่องมือเดียวที่คุณต้องพึ่งพาตอนเกิดปัญหาคือ Browser DevTools (กด F12 หรือ Ctrl+Shift+I)

ไปที่แท็บ Network
ทำการกระทำที่ทำให้เกิดปัญหา (เช่น กดปุ่ม Submit หรือรีเฟรชหน้า)
คลิกที่ Request ที่มีปัญหา
ดูแท็บ Headers และ Response

ในส่วนของ Headers คุณจะเห็นข้อมูลแบ่งเป็น 2 ส่วนคือ Request Headers (ที่คุณส่งไป) และ Response Headers (ที่ Server ตอบกลับมา) การเปรียบเทียบสองส่วนนี้คือหัวใจของการ debug ยกตัวอย่างเช่น ถ้าคุณส่ง Authorization: Bearer <token> ไป แต่กลับได้ 401 Unauthorized ลองเช็คดูว่า Token หมดอายุหรือไม่ หรือรูปแบบผิดไหม

กรณีศึกษาปัญหาจริง: 403, 429, 502

มาดูปัญหาจริงที่เจอบ่อยและวิธีอ่าน Header เพื่อหาสาเหตุกัน

1. ปัญหา 403 Forbidden

คุณมี Token แล้ว ล็อกอินแล้ว แต่ยิง API กลับโดน 403 ส่วนใหญ่คือปัญหาสิทธิ์ (Permission) ลองเช็ค Response Header ดูบางที Server อาจจะส่ง X-RateLimit-Remaining: 0 หรือ Header ที่บอกรายละเอียดว่าทำไมถึงห้ามเข้า บางครั้งอาจเป็นเพราะส่ง Origin หรือ Referer ไม่ถูกต้องตามที่ API กำหนด

2. ปัญหา 429 Too Many Requests

เมื่อเร็วเกินไป หรือยิง API บ่อยเกินขีดจำกัด สิ่งที่คุณต้องดูใน Response Header คือ:

HTTP/1.1 429 Too Many Requests
Retry-After: 60

Header Retry-After บอกตรงๆ ว่าต้องรอกี่วินาถีจึงจะยิงได้อีกครั้ง ถ้าคุณเขียน Script ไปดึงข้อมูลแบบลูป การอ่านค่านี้มาใส่ sleep() คือวิธีแก้ปัญหาที่ถูกต้องที่สุด

3. ปัญหา 502 Bad Gateway

ปัญหานี้มักเกิดจาก Backend ที่อยู่หลัง Reverse Proxy (เช่น Nginx หรือ Load Balancer) ดับไปหรือใช้เวลาตอบสนองนานเกินไปจน Proxy ตัดการเชื่อมต่อ การทำ HTTP response header debug ในกรณีนี้ อาจจะเห็น Header ประมาณนี้:

HTTP/1.1 502 Bad Gateway
Server: nginx

สิ่งที่คุณทำได้คือไปเช็ค Log ของ Nginx และ Log ของ Backend ว่ามี Error อะไรหรือไม่ ปัญหานี้ฝั่ง Client แก้ไม่ได้ ต้องแก้ที่ฝั่ง Server เท่านั้น

เขียน Python requests พร้อม Error Handling

เมื่อเราเข้าใจปัญหาและวิธีอ่าน Header แล้ว ต่อไปคือการเขียนโค้ดฝั่ง Client ให้รอบคอบ การใช้ requests ใน Python นั้นง่าย แต่หลายคนมักลืมจัดการ Error ทำให้โปรแกรมพังกลางอากาศ

นี่คือตัวอย่างโค้ดที่มีการจัดการ Error และอ่าน Response Header อย่างถูกต้อง:

import requests
import time

url = "https://api.example.com/data"
headers = {
    "Authorization": "Bearer YOUR_TOKEN",
    "Accept": "application/json"
}

try:
    response = requests.get(url, headers=headers, timeout=10)
    
    # ตรวจสอบว่ามี Error หรือไม่ (จะ raise HTTPError ถ้า Status Code เป็น 4xx หรือ 5xx)
    response.raise_for_status()
    
    print("Success!")
    print(response.json())

except requests.exceptions.HTTPError as err:
    print(f"HTTP Error occurred: {err}")
    print(f"Status Code: {response.status_code}")
    
    # ตรวจสอบหากโดน Rate Limit (429)
    if response.status_code == 429:
        retry_after = response.headers.get("Retry-After")
        if retry_after:
            print(f"Rate limited. Retrying after {retry_after} seconds...")
            time.sleep(int(retry_after))
            # สามารถเรียกฟังก์ชันยิง API ใหม่ได้ที่นี่

except requests.exceptions.ConnectionError:
    print("Failed to establish a connection. (เช็คอินเทอร์เน็ตหรือ URL ผิดไหม)")
except requests.exceptions.Timeout:
    print("Request timed out. (Server ตอบช้าเกินไป)")
except requests.exceptions.RequestException as err:
    print(f"Something went wrong: {err}")

จะเห็นว่าในบล็อก except เราสามารถเข้าถึง response.headers เพื่ออ่านค่า Retry-After มาจัดการ Retry ได้อย่างชาญฉลาด นี่คือการทำ HTTP response header debug ที่นำไปใช้ได้จริงในโปรดักชัน

สรุป

การแก้ปัญหาเว็บไม่ใช่การนั่งเดา แต่ต้องอาศัยการสังเกตและอ่านสัญญาณที่ Server ส่งมา การเข้าใจ Status Code, Response Header และการใช้ DevTools อย่างคล่องแคล่ว จะช่วยประหยัดเวลาในการหาสาเหตุปัญหาได้มาก

ครั้งต่อไปที่เจอ Error แทนที่จะรีบไปแก้โค้ด ลองเปิด DevTools และอ่าน Header ดูก่อน คุณอาจจะพบคำตอบที่ซ่อนอยู่

อ่านบทความดีๆ เกี่ยวกับการพัฒนาเว็บได้ที่นี่ และอย่าลืมกดติดตามเพื่อไม่พลาดความรู้ใหม่ๆ ลองนำโค้ดตัวอย่างไปรันและทดสอบดูได้เลย แล้วมาแลกเปลี่ยนกันว่าคุณเจอปัญหาอะไรบ้างในช่วงที่ทำ API แล้วใช้วิธีไหนแก้ไข