Nginx Config Generator: สร้าง Server Block พร้อม Production ในไม่กี่วินาที

ถ้าถาม DevOps engineer คนไหนว่าสัปดาห์แรกบน server ใหม่เป็นยังไง ส่วนใหญ่มักจะมีเรื่องเล่าเกี่ยวกับ nginx config ที่พัง เพราะแค่ semicolon หายไปตัวเดียว typo ใน URL ของ proxy_pass หรือลืมใส่ directive ssl_certificate ก็ทำให้ site ล่มได้ทั้งก้อน — บางทีกระทบทุก virtual host บนเครื่อง ไม่ใช่แค่ตัวที่กำลังแก้อีกด้วย

Nginx Config Generator ถูกสร้างมาเพื่อกำจัดปัญหากลุ่มนี้ออกไปจากต้นเหตุ แทนที่จะก็อปปี้ config อายุห้าปีจากบล็อกสักแห่งแล้วมานั่งแก้ทีละบรรทัด คุณแค่ระบุการติดตั้งของคุณผ่านฟอร์มสั้น ๆ — domain, ประเภท config, ที่อยู่ backend และ toggle อีกไม่กี่ตัว — แล้วรับกลับมาเป็น server block ที่สะอาด มี comment กำกับ พร้อมใช้งาน production ตาม best practices ปัจจุบัน ฟรี ทำงานในเบราว์เซอร์ทั้งหมด และไม่ส่ง configuration ของคุณออกไปไหนเลย

ไม่ว่าคุณจะเอา Node.js app ไปไว้หลัง reverse proxy ติดตั้ง WordPress ด้วย PHP-FPM หรือกระจายโหลดข้ามหลาย app instance เจ้า generator ตัวนี้จัดการ boilerplate ของ nginx.conf ที่คุณเคยต้องพิมพ์ใหม่จากความจำทั้งหมดให้เอง

ทำไมต้องใช้ Nginx Config Generator

• หมดปัญหา syntax พังกลางคัน — grammar ของ nginx config ไม่เคยให้อภัยใคร ลืม semicolon หรือวงเล็บปีกกาไม่เป็นคู่ reload ทั้งก้อน fail ทันที ตัว generator ปล่อย directive ที่ถูก syntax ออกมาทุกครั้ง เหลือแค่คุยกับ value ที่คุณกรอกเองเท่านั้น
• Best practices ฝังมาในตัว ไม่ต้องไปหามาต่อ — output ที่ได้ใช้ TLSv1.2/TLSv1.3 เท่านั้น, cipher แบบ ECDHE สมัยใหม่, OCSP stapling, SSL session caching ที่เหมาะสม และ security headers ชุดเต็มตามที่แนะนำกัน คุณได้ config ที่ harden แล้วตั้งแต่ค่าเริ่มต้น ไม่ต้องนั่งจำเคล็ดลับ hardening สิบห้าข้อ
• ครอบคลุม 4 รูปแบบการติดตั้งยอดนิยม — static site, reverse proxy, PHP-FPM และ load balancing ครอบคลุม use case ของ nginx ไปเกือบทั้งหมด สลับกันด้วย dropdown ตัวเดียว ไม่ใช่การเขียนใหม่ทั้งก้อน
• พร้อม Let's Encrypt ตั้งแต่คลิกแรก — path ของ SSL certificate ตั้ง default ไว้ที่ /etc/letsencrypt/live/โดเมนคุณ/fullchain.pem ซึ่งเป็น layout มาตรฐานที่ Certbot สร้างให้ config ใช้งานได้ทันทีที่ certificate ออก
• 100% client-side — ทุกอย่าง generate ในเบราว์เซอร์ของคุณ domain, IP ของ backend และ socket path ไม่เคยออกจากเครื่อง ซึ่งสำคัญมากเวลา config infrastructure ภายในองค์กร
• Copy หรือ download ได้ตามสะดวก — คลิกเดียวส่ง config เข้า clipboard สำหรับ paste ลง SSH session หรือดาวน์โหลดเป็นไฟล์เก็บเข้า config management repo ของทีม

ฟีเจอร์หลัก

มีสองรายละเอียดที่อยากเน้น อันดับแรกคือ security headers ทุกตัวใส่ flag always ไว้ด้วย แปลว่า header จะถูกส่งแม้กระทั่ง response แบบ error (404, 500) — ซึ่งเป็นช่องโหว่คลาสสิกของ config ที่เขียนเองและเป็นสิ่งที่ security scanner ชอบ flag อันดับสองคือบล็อก static asset caching ครอบคลุมรูปภาพ, CSS, JavaScript, SVG และ web fonts พร้อมปิด access log ของ request กลุ่มนี้ เพื่อให้ log ของคุณอ่านง่ายและ disk ไม่โดนอัด

วิธีใช้งาน

1. เปิด Nginx Config Generator แล้วเลือกประเภท config: static, reverse proxy, PHP-FPM หรือ load balancer
2. กรอก domain name — path ของ SSL, ชื่อไฟล์ log และกติกา redirect ทั้งหมด derive จากตรงนี้อัตโนมัติ
3. กรอกฟิลด์เฉพาะของแต่ละประเภท: document root สำหรับ static site, URL ของ proxy_pass สำหรับ reverse proxy, socket path ของ PHP-FPM หรือรายชื่อ backend servers สำหรับ load balancing
4. เปิด/ปิด SSL/TLS, HTTP/2, HSTS, gzip, security headers และ static asset caching ตามต้องการ (cert path ตั้ง default ตาม layout ของ Let's Encrypt อยู่แล้ว)
5. Copy config ที่ได้ บันทึกเป็น /etc/nginx/sites-available/โดเมนคุณ.conf แล้วทดสอบด้วย nginx -t ก่อน reload

เข้าใจ Nginx Server Blocks

server block คือหน่วยของ virtual hosting ใน nginx: ทุกอย่างใน server { ... } จะถูก apply กับหนึ่ง site directive listen ผูก port, server_name จับคู่กับ Host header ของ request ที่เข้ามา และ location blocks ต่าง ๆ กำหนดว่า request แบบไหนจะถูกจัดการอย่างไร

กลไก routing สามแบบที่ generator สร้างให้มีจุดประสงค์ต่างกัน:

• proxy_pass ส่งต่อ request ไปยัง HTTP server ตัวอื่น — ปกติคือ app server อย่าง Node.js, Next.js หรือ container nginx คุย HTTP กับ backend แล้วส่ง response กลับมา บล็อกที่ generate ให้ยังตั้งค่า headers Host, X-Real-IP, X-Forwarded-For และ X-Forwarded-Proto เพื่อให้ app เห็น client ตัวจริงแทนที่จะเห็น nginx เอง พร้อม headers Upgrade สำหรับ WebSocket หากเปิดใช้
• fastcgi_pass ส่ง request ต่อให้ FastCGI process — ในทางปฏิบัติคือ PHP-FPM ผ่าน Unix socket แทนที่จะ proxy ด้วย HTTP nginx จะคุยด้วยโปรโตคอล FastCGI และส่ง SCRIPT_FILENAME ให้ PHP รู้ว่าต้องรันไฟล์ไหน บรรทัด try_files $uri $uri/ /index.php?$query_string; ที่ generate ให้คือสิ่งที่ทำให้ clean URLs ทำงานใน WordPress และ Laravel
• upstream ตั้งชื่อให้ pool ของ backend servers ที่ proxy_pass จะเรียก นั่นคือ load balancing: nginx เลือก server ต่อ request ตามวิธีที่คุณเลือก — round-robin (หมุนเวียนเท่า ๆ กัน), least_conn (request ที่ค้างน้อยสุด) หรือ ip_hash (sticky session ผูกกับ IP ของ client)

ฝั่ง SSL นั้น directive แต่ละตัวที่ generate ให้มีเหตุผลของมัน ssl_protocols TLSv1.2 TLSv1.3 ตัด protocol เก่าที่ browser เลิกรับทิ้งไป, ssl_session_cache shared:SSL:10m ให้ worker processes แชร์ TLS session state กันได้ ลดต้นทุน handshake สำหรับ visitor ที่กลับมาซ้ำ, ssl_stapling on เปิด OCSP stapling ให้ nginx ดึงสถานะ certificate เองแทนที่ client ทุกตัวจะไปถาม CA และ ssl_session_tickets off หลีกเลี่ยงจุดอ่อน forward-secrecy ที่รู้กันในการ resume แบบ ticket

ส่วน security headers สำคัญเพราะ browser คือแนวป้องกันสุดท้ายของคุณ X-Frame-Options SAMEORIGIN กัน clickjacking ด้วยการปฏิเสธไม่ให้ site อื่น iframe คุณ, X-Content-Type-Options nosniff กันการโจมตีแบบ MIME-type confusion, Referrer-Policy strict-origin-when-cross-origin กัน URL เต็ม ๆ รั่วไปหา third party และ Content-Security-Policy ที่จำกัด script-src 'self' ตัดอำนาจการโจมตี cross-site scripting ส่วนใหญ่ตั้งแต่ยังไม่เริ่ม

ตัวอย่างการใช้งานจริง

ติดตั้ง Next.js หรือ Node App หลัง Nginx

คุณสร้าง Node app ที่รับฟัง port 3000 แล้วอยากให้ serve บน port 80/443 พร้อม TLS ของจริง เลือก reverse proxy ตั้ง proxy_pass http://127.0.0.1:3000 เปิด SSL ด้วย path ของ Let's Encrypt และเปิด WebSocket headers ถ้า app ใช้งาน config ที่ได้จัดการ redirect HTTP→HTTPS ให้ พร้อม forward headers ที่ framework ส่วนใหญ่คาดหวัง — รวมถึง X-Forwarded-Proto ที่ Express และ Next.js ใช้สร้าง redirect URL แบบ https:// ที่ถูกต้องเมื่ออยู่หลัง proxy

ให้บริการ WordPress หรือ Laravel ด้วย PHP-FPM

เลือกประเภท PHP-FPM ชี้ socket ไปที่ PHP เวอร์ชันของคุณ (default unix:/var/run/php/php8.2-fpm.sock ตรงกับการติดตั้ง Debian/Ubuntu มาตรฐาน) แล้วตั้ง document root ไปที่โฟลเดอร์เว็บของคุณ คุณจะได้ try_files fallback สุดคลาสสิกที่ route ทุก path ผ่าน index.php พร้อม location block ที่ปฏิเสธการเข้าถึง hidden files อย่าง .env และ .git แต่ยังเปิดช่อง ACME challenge ที่ Let's Encrypt ต้องใช้ต่ออายุ certificate

กระจายโหลดหลาย App Instance

เมื่อ process เดียวรับ traffic ไม่ไหว ยิง instance ขึ้นมาสองก้อนขึ้นไปคนละ port แล้วเลือกประเภท load balancer generator จะเขียนบล็อก upstream backend_pool ระบุรายชื่อ backend ของคุณ และ server block หลักจะ proxy เข้า pool นั้น ใช้ round-robin สำหรับ instance ไร้สถานะที่เหมือนกันทุกตัว, least_conn เมื่อ response time แต่ละตัวไม่เท่ากัน และ ip_hash เมื่อ session อยู่ใน memory ของ process และ client ต้องเข้า backend ตัวเดิมเสมอ

Static Site กับ Caching แบบเต็มสูบ

สำหรับบล็อก เอกสาร หรือโฟลเดอร์ build output อะไรก็ตาม ประเภท static บวก caching ให้ setup ที่เร็วที่สุดเท่าที่เป็นไปได้: try_files $uri $uri/ =404 สำหรับ resolve path อย่างปลอดภัย, expires 1y กับ Cache-Control: public, immutable สำหรับ asset ที่มี fingerprint อย่าง app.a1b2c3.js และ gzip สำหรับ response แบบข้อความ จับคู่กับ static site generator ตัวไหนก็ได้ แล้ว config เดียวกันนี้ serve ได้ทุกขนาด

Best Practices

• รัน nginx -t ทุกครั้งก่อน reload — มัน parse config แล้วบอกบรรทัดที่ error แบบเจาะจง การ nginx -s reload ด้วย config พังอาจทำให้ master process เสิร์ฟ state เก่าค้างหรือล่มทั้งตัว
• ยึด TLSv1.2 เป็นขั้นต่ำ — protocol เวอร์ชันเก่าถูก deprecate อย่างเป็นทางการแล้ว browser สมัยใหม่ปฏิเสธ และ scanner ทั้งหลาย flag ทันที
• ใช้ gzip level 5–6 — level ที่สูงกว่านั้นกิน CPU เพิ่มเยอะแต่ได้ byte กลับมาแบบจิ๊บจ๊อย level 6 คือจุดหวานที่ generator ใช้
• สงวน immutable ไว้สำหรับไฟล์ที่มี fingerprint เท่านั้น — ไฟล์ที่ชื่อฝัง content hash จะไม่มีวันเปลี่ยน ส่วนอย่างอื่นควรใช้ cache lifetime สั้นกว่าเพื่อให้ deploy มีผลจริง
• แยก log ตาม domain — แยก access_log และ error_log ต่อ server block ทำให้ debug หนึ่ง site ได้โดยไม่ต้องไป grep ใน traffic ของคนอื่น
• Redirect ตั้งแต่วันแรก — บล็อก HTTP→HTTPS ควรมีตั้งแต่เปิดตัว ไม่ใช่มาเติมทีหลัง เพราะทุก request ที่ยังเป็น plain HTTP คือ redirect ที่คุณต้องมาเพิ่มอยู่ดี

เริ่มต้นใช้งานเลย

เลิกนั่งแก้ boilerplate ด้วยมือแล้วเริ่มจากฐานที่พิสูจน์แล้วว่าใช้ได้ เปิด Nginx Config Generator เลือกรูปแบบการติดตั้งของคุณ แล้วรับ server block ที่ harden พร้อม TLS กลับมาภายในเวลาที่ boot VM ยังไม่เสร็จ ตัวคุณในอนาคต — คนที่นั่ง debug ตอนตีสอง — จะขอบคุณคุณเอง

เครื่องมือที่เกี่ยวข้อง

• ตัวสร้าง Apache .htaccess
• ตัวสร้าง Docker Compose
• ตัวแปลง Apache เป็น Nginx

ขอให้ config ราบรื่น!