10 จุดที่มือใหม่มักพลาดใน Nginx Config และวิธีเช็กก่อนเว็บพัง

Nginx เป็นเหมือนด่านหน้าของระบบเว็บ ทำหน้าที่รับ request, ส่งไฟล์ static, ทำ reverse proxy, cache และ redirect ได้ครบในตัวเดียว จึงเป็นเครื่องมือสำคัญที่หลายโปรเจกต์ใช้งานจริง

ปัญหาคือ หลายครั้งระบบไม่ได้มีปัญหาเพราะโค้ดแอปพลิเคชันผิดพลาด แต่เกิดจาก config ที่ผิดเพียงบรรทัดเดียว โดยเฉพาะสำหรับมือใหม่ที่เพิ่งเริ่มจับ Nginx เรื่องที่พลาดมักไม่ใช่เรื่องยาก แต่เป็นรายละเอียดเล็ก ๆ ที่มองข้ามได้ง่าย

บทความนี้รวบรวม 10 จุดที่พลาดบ่อย พร้อมอธิบายผลกระทบและวิธีป้องกันแบบใช้งานได้จริง

1) ตั้งค่า server_name ไม่ตรงกับโดเมนจริง

หนึ่งในความผิดพลาดที่เจอบ่อยที่สุดคือกำหนด server_name ไม่ครบ หรือไม่ตรงกับโดเมนที่ใช้งานจริง เช่น มีทั้งโดเมนหลักและ www แต่ config รองรับเพียงชื่อเดียว หรือสะกดชื่อโดเมนผิดไปหนึ่งตัวอักษร

ผลที่ตามมาคือเว็บอาจไม่ล่ม แต่ request ถูกส่งไปยัง virtual host อื่น ทำให้ผู้ใช้เข้าเว็บผิดตัวแบบงง ๆ และการดีบักก็ยากเพราะระบบดูเหมือนยังตอบสนองอยู่

แนวทางที่ดีคือ:

• ระบุโดเมนที่ต้องรองรับให้ครบ
• ตรวจสอบทั้งแบบมีและไม่มี www
• ตั้ง default server ให้ชัดเจนเพื่อลดความสับสน

2) แก้ config แล้วลืม reload

หลายคนแก้ไฟล์เสร็จแล้วมั่นใจว่าปัญหาจะหาย แต่ลืมว่า Nginx ยังทำงานด้วย config ชุดเดิมอยู่ จึงเกิดสถานการณ์ที่ "แก้แล้วแต่ไม่เปลี่ยน" อยู่บ่อยครั้ง

คำสั่งที่ควรจำคือ:

nginx -t

คำสั่งนี้ใช้ตรวจสอบ syntax ของ config ก่อน หากผ่านแล้วค่อย reload จะปลอดภัยกว่า เช่น:

nginx -s reload

หรือใช้ผ่าน service manager ของระบบตามที่ใช้งานอยู่

3) ใช้ root กับ alias สลับกัน

root และ alias เป็นคำสั่งที่หน้าตาคล้ายกันมาก แต่การทำงานต่างกันอย่างมีนัยสำคัญ โดยเฉพาะตอน serve static file

จำง่าย ๆ คือ:

• root จะนำ path ของ request ไปต่อท้าย path ที่กำหนด
• alias จะใช้ path ใหม่แทน location นั้นโดยตรง

ถ้าใช้ผิด ไฟล์รูปภาพ, CSS หรือ JavaScript อาจขึ้น 404 ทั้งที่ไฟล์อยู่จริง ทำให้เสียเวลาไล่หาสาเหตุโดยไม่จำเป็น

4) เขียน location ทับกันเอง

Nginx มีลำดับการ match location ที่ไม่ตรงกับความรู้สึกของมือใหม่เสมอไป หลายคนคิดว่าเขียน location /api/ แล้ว request ที่ขึ้นต้นด้วย /api/ จะเข้าบล็อกนี้ทุกกรณี แต่ในความจริง regex หรือ prefix บางแบบอาจถูกเลือกแทน

ผลคือ request อาจถูกส่งไปผิด backend หรือวิ่งเข้ากฎที่ไม่ได้ตั้งใจไว้

สิ่งที่ควรทำคือ:

• ตรวจสอบลำดับและชนิดของ location
• ระวังการใช้ regex ร่วมกับ prefix
• ทดสอบ path สำคัญหลายรูปแบบก่อน deploy

5) ใส่ slash ใน proxy_pass เกินหรือขาด

นี่เป็นจุดพลาดคลาสสิกของคนที่เริ่มใช้ reverse proxy เพราะ slash (/) เพียงตัวเดียวสามารถเปลี่ยน path ที่ส่งต่อไป backend ได้ทันที

ตัวอย่างเช่น:

location /app/ {
    proxy_pass http://backend/;
}

กับ

location /app/ {
    proxy_pass http://backend;
}

แม้ดูใกล้เคียงกันมาก แต่ผลลัพธ์ไม่เหมือนกัน เช่น request เดิมเป็น /app/login ปลายทางอาจได้รับเป็น /login หรือ /app/login ขึ้นอยู่กับรูปแบบที่เขียน

นี่เป็นปัญหาที่ทำให้ดีบักกันนาน เพราะ backend ไม่ได้เสีย แต่รับ path ไม่ตรงจากที่คาดไว้

6) ลืมส่ง header สำคัญไปยัง backend

เมื่อ Nginx ทำหน้าที่ reverse proxy มักต้องส่ง header บางตัวต่อไปยังแอปหลังบ้าน เช่น:

• Host
• X-Forwarded-For
• X-Forwarded-Proto

หากลืมส่ง header เหล่านี้ อาจเกิดปัญหาหลายแบบ เช่น:

• แอป generate URL ผิด
• redirect วนซ้ำ
• มองเห็น IP ผู้ใช้ผิด
• แอปเข้าใจว่า request ยังเป็น http ทั้งที่ผู้ใช้เข้า https

ปัญหาเหล่านี้มักดูเหมือนเกิดที่แอป แต่จริง ๆ แล้วต้นเหตุอาจมาจาก proxy layer

7) ตั้ง client_max_body_size ไว้น้อยเกินไป

ตอนทดสอบระบบด้วยไฟล์เล็ก ๆ ทุกอย่างอาจดูปกติ แต่เมื่อผู้ใช้เริ่มอัปโหลดไฟล์จริง ระบบอาจตอบกลับด้วยสถานะ 413 Request Entity Too Large ทันที

นี่เป็นจุดที่หลายทีมมักเจอหลังขึ้น production เพราะขนาดไฟล์จริงของผู้ใช้ต่างจากข้อมูลทดสอบมาก

ทางแก้คือ:

• ประเมินขนาดไฟล์ที่รองรับจริง
• ตั้ง client_max_body_size ให้เหมาะสม
• ทดสอบการอัปโหลดด้วยไฟล์ขนาดใกล้เคียงการใช้งานจริง

8) เปิด autoindex โดยไม่ตั้งใจ

การเปิด autoindex ทำให้ผู้ใช้สามารถ browse รายการไฟล์ในโฟลเดอร์ได้ หากเปิดไว้โดยไม่ตั้งใจ อาจทำให้รายชื่อไฟล์ภายในถูกมองเห็นจากภายนอก

ความเสี่ยงคืออาจมี:

• ไฟล์ backup
• ไฟล์ทดสอบ
• ไฟล์เก่าที่ไม่ควรถูกเปิดเผย

แม้จะดูเป็นเรื่องเล็ก แต่เป็นประเด็นด้านความปลอดภัยที่ไม่ควรมองข้าม โดยเฉพาะในระบบที่มีไฟล์ภายในหลายชุด

9) เกิด redirect loop เพราะบังคับ HTTPS ซ้ำซ้อน

อีกปัญหาที่พบบ่อยคือ redirect loop เมื่อมีการบังคับ HTTPS มากกว่าหนึ่งชั้น เช่น:

• Nginx บังคับครั้งหนึ่ง
• แอปหลังบ้านบังคับอีกครั้ง
• อยู่หลัง load balancer แล้วตรวจสอบ proto ไม่ถูกต้อง

ผลคือผู้ใช้เข้าเว็บไม่ได้ หรือเบราว์เซอร์แจ้งว่ามีการ redirect มากเกินไป

แนวทางป้องกันคือ:

• กำหนดให้ชัดว่าใครเป็นผู้รับผิดชอบเรื่อง redirect
• ตรวจสอบ X-Forwarded-Proto ให้ถูกต้อง
• ทดสอบเส้นทาง request เมื่ออยู่หลัง proxy หรือ load balancer จริง

10) รวมทุกอย่างไว้ในไฟล์ config เดียว

ช่วงเริ่มต้น การเก็บ config ทั้งหมดไว้ในไฟล์เดียวอาจดูสะดวก แต่เมื่อระบบเติบโต มีหลายโดเมน หลาย service และหลาย rule ไฟล์จะยาวจนอ่านยากและแก้พลาดง่าย

แนวทางที่ดีสำหรับมือใหม่คือ:

• แยก site config เป็นส่วน ๆ
• ตั้งชื่อไฟล์ให้เดาได้ง่าย
• มี default server ที่ชัดเจน
• ใส่ comment เฉพาะจุดที่ซับซ้อนจริง ๆ

การจัดโครงสร้าง config ให้ดีไม่ได้ช่วยแค่ให้เว็บรันได้ แต่ยังช่วยให้ทีมอื่นเข้ามาอ่านและดูแลต่อได้โดยไม่หลง

Checklist สั้น ๆ ก่อน deploy

ก่อนนำ config ขึ้นใช้งานจริง ควรเช็กอย่างน้อยตามรายการนี้:

• ตรวจสอบ server_name
• ตรวจสอบ location
• ตรวจสอบ slash ใน proxy_pass
• ตรวจสอบ header ที่ส่งต่อไป backend
• ตรวจสอบ upload limit
• ตรวจสอบ redirect
• รัน nginx -t ทุกครั้งก่อน reload

นิสัยเล็ก ๆ อย่างการเช็ก syntax ก่อนใช้งานจริง ช่วยลดความเสี่ยงจากความผิดพลาดได้มากกว่าที่หลายคนคิด

ทำไมเรื่องเล็ก ๆ ใน config ถึงสำคัญ

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

การเข้าใจภาษากลางของ Nginx ในระดับที่ใช้งานจริงได้ จึงเป็นทักษะสำคัญสำหรับทั้งสาย Dev และ Ops ยิ่งเรียนรู้เร็ว ก็ยิ่งลดเวลาที่ต้องเสียไปกับการงมหา log และดีบักปัญหาที่ดูเหมือนซับซ้อน แต่จริง ๆ เริ่มจาก config เพียงบรรทัดเดียว

สรุป

Nginx ไม่ได้ยากเพราะคำสั่งซับซ้อนเสมอไป แต่ยากเพราะรายละเอียดเล็ก ๆ ที่มีผลต่อพฤติกรรมของระบบอย่างมาก ไม่ว่าจะเป็น server_name, location, proxy_pass, header, ขนาดไฟล์อัปโหลด หรือการ redirect ทุกจุดล้วนมีโอกาสทำให้เว็บทำงานผิดจากที่ตั้งใจได้

หากสร้างนิสัยตรวจสอบ config อย่างเป็นระบบ แยกไฟล์ให้ชัด และรัน nginx -t ก่อน reload ทุกครั้ง ก็จะช่วยลดความผิดพลาดได้อย่างมาก และทำให้การดูแลระบบในระยะยาวง่ายขึ้นด้วย

แหล่งอ้างอิง

• http://backend/;
• http://backend