วิธีตั้งค่า Nginx Server Blocks (Virtual Hosts) เพื่อโฮสต์เว็บไซต์หลายเว็บบนเซิร์ฟเวอร์เดียว

Nginx Server Blocks คือแนวคิดการตั้งค่าสำหรับโฮสต์เว็บไซต์หลายโดเมนบนเซิร์ฟเวอร์ Nginx เดียวกัน โดยแต่ละเว็บไซต์จะมีการตั้งค่าแยกกัน เช่น โฟลเดอร์ root, ไฟล์ล็อก, SSL certificate และการตั้งค่า PHP ที่แตกต่างกัน ตัวอย่างเช่น บน VPS เดียวกัน คุณสามารถตั้งค่า example.com, blog.example.com และ second-site.com ให้ใช้โฟลเดอร์และการตั้งค่าที่ต่างกันได้อย่างอิสระ โดยกระบวนการหลักคือสร้างโฟลเดอร์แยกสำหรับแต่ละเว็บไซต์ กำหนด DNS ให้ชี้ไปยัง IP ของเซิร์ฟเวอร์ สร้างไฟล์ server block แยกใน /etc/nginx/sites-available และเชื่อมโยงไปยัง sites-enabled ทดสอบการตั้งค่า และสุดท้าย reload Nginx เพื่อให้ระบบทำงาน

ในบทความนี้เราจะสอนวิธีการตั้งค่า Nginx Server Blocks สำหรับโฮสต์เว็บไซต์หลายเว็บในสภาพแวดล้อมจริง โดยไม่ใช่แค่การทำให้ระบบใช้งานได้เท่านั้น แต่ยังเน้นการสร้างระบบที่จัดการง่าย ปลอดภัย เร็ว และสามารถสำรองข้อมูล รวมถึงขยายระบบได้ เหมาะกับทั้งเอเจนซี่ นักพัฒนา เจ้าของร้านค้าออนไลน์ ธุรกิจที่บริหารหลายแบรนด์ และแอดมินระบบที่ต้องดูแลโปรเจกต์หลายเว็บบนเซิร์ฟเวอร์เดียว หากยังไม่มีเซิร์ฟเวอร์ แนะนำให้ดูหัวข้อ เซิร์ฟเวอร์ VPS และการจัดการโดเมนที่ การจดทะเบียนโดเมน

Nginx Server Blocks คืออะไร?

Nginx Server Blocks คือการตั้งค่าประเภทหนึ่งในไฟล์คอนฟิกของ Nginx ที่ใช้กำหนดว่า HTTP หรือ HTTPS request ที่เข้ามาจะถูกส่งไปยังเว็บไซต์ใด คล้ายกับแนวคิด VirtualHost ของ Apache เมื่อผู้ใช้งานพิมพ์ชื่อโดเมนในเบราว์เซอร์ DNS จะทำหน้าที่แปลงชื่อโดเมนไปยัง IP ของเซิร์ฟเวอร์ จากนั้น Nginx จะตรวจสอบค่า Host header และรัน Server Block ที่มีค่า server_name ตรงกับโดเมนนั้น

ทำให้เราสามารถโฮสต์เว็บไซต์หลายเว็บบน IP และเซิร์ฟเวอร์เดียวกันได้อย่างมีประสิทธิภาพ โดยแต่ละเว็บสามารถกำหนด root directory, access log, error log, กฎการเปลี่ยนเส้นทาง, SSL certificate, นโยบาย cache และกฎความปลอดภัยต่างกันได้ เช่น เว็บไซต์บริษัทตั้งไว้ที่ /var/www/kurumsal/public, เว็บบล็อกที่ /var/www/blog/public และเว็บทดสอบที่ /var/www/staging/public

Nginx มีจุดเด่นเรื่องประสิทธิภาพสูง เพราะใช้ Event-driven architecture ที่สามารถจัดการการเชื่อมต่อพร้อมกันจำนวนมากได้โดยใช้ทรัพยากรต่ำ จึงนิยมใช้กับบริการ shared hosting, VPS, cloud servers และเว็บไซต์ที่มีปริมาณผู้ใช้สูง อย่างไรก็ตามการโฮสต์หลายเว็บต้องวางแผนละเอียดตั้งแต่สิทธิ์ไฟล์ การตั้งค่า DNS การติดตั้ง SSL ไปจนถึงการแยกไฟล์ล็อกให้เหมาะสม

เมื่อใดควรใช้ Nginx Server Blocks?

Server Blocks เหมาะกับกรณีที่ต้องบริหารเว็บไซต์หลายเว็บบนเซิร์ฟเวอร์เดียวกัน ทั้งเว็บเล็กๆ สองสามเว็บ หรือหลายสิบโปรเจกต์ของลูกค้า เว็บย่อย (subdomain) หรือตัวบริการย่อย (microservices) โดยจุดสำคัญคือการแยกแต่ละโปรเจกต์ออกจากกันอย่างชัดเจน

• ต้องการโฮสต์หลายโดเมนบน VPS เดียวกัน
• ต้องการเปลี่ยนเส้นทาง www กับ non-www เป็นชื่อโดเมนหลักเดียวกัน
• ต้องการแยก subdomain ไปยังโฟลเดอร์หรือแอปพลิเคชันต่างกัน
• ต้องการ SSL certificate และนโยบายความปลอดภัยแยกสำหรับแต่ละเว็บ
• ต้องการติดตามล็อกของแต่ละเว็บแยกกัน
• ต้องการรันแอปพลิเคชันหลากหลาย เช่น Laravel, WordPress, HTML สแตติก หรือ Node.js บนเซิร์ฟเวอร์เดียว

เช่น เอเจนซี่ดิจิทัลที่ใช้ VPS 4GB RAM โฮสต์เว็บไซต์บริษัท 8 เว็บที่มีทราฟฟิคลดต่ำได้ แต่ต้องคำนวณทรัพยากร เช่น ทราฟฟิค, พื้นที่ดิสก์, จำนวนกระบวนการ PHP และความถี่การสำรองข้อมูลให้เหมาะสม ถ้าทราฟฟิคเยอะหรือเน้นการแยกทรัพยากรชัดเจน ควรเลือก VPS ที่แรงขึ้น, Cloud Server หรือ Managed Hosting แทน ตัวเลือกที่เกี่ยวข้องคือ การโฮสต์เว็บไซต์ และ โฮสติ้งธุรกิจ

สิ่งที่ต้องเตรียมก่อนเริ่ม

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

ข้อกำหนดทางเทคนิค

• บัญชีผู้ใช้ Linux ที่มีสิทธิ์ root หรือ sudo
• ติดตั้งและรัน Nginx แล้ว
• อย่างน้อยหนึ่งโดเมนที่ชี้ไปยัง IP เซิร์ฟเวอร์เรียบร้อย
• เปิดพอร์ต 80 และ 443 ใน firewall
• มีโครงสร้างโฟลเดอร์จัดเก็บไฟล์เว็บไซต์อย่างเป็นระเบียบ
• มี SSL certificate ที่ใช้งานได้ หรือใช้ Let’s Encrypt ฟรี
• ถ้าใช้ PHP ต้องติดตั้ง PHP-FPM

DNS ต้องตั้งค่า A record ให้ชี้โดเมนหลักไปยัง IPv4 และ AAAA record ถ้ามี IPv6 สำหรับ subdomain เช่น www สามารถใช้ CNAME หรือ A record ได้ ระยะเวลาการแพร่กระจาย DNS อาจใช้ตั้งแต่ไม่กี่นาทีจนถึง 24 ชั่วโมง จึงควรเตรียม DNS ก่อนเริ่มตั้งค่า Nginx Server Blocks เพื่อความรวดเร็ว

โครงสร้างโฟลเดอร์ที่แนะนำ

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

ตัวอย่างโครงสร้างเช่น /var/www/site1.com/public, /var/www/site1.com/logs, /var/www/site2.com/public, /var/www/site2.com/logs โดยค่า root ของ Nginx ควรชี้ไปที่ public เพื่อป้องกันไม่ให้ไฟล์สำคัญ เช่น .env หรือไฟล์สำรอง ถูกเข้าถึงผ่านเว็บโดยตรง

สำหรับทดสอบสามารถสร้างไฟล์ index.html ง่ายๆ ในแต่ละโฟลเดอร์เพื่อแสดงชื่อเว็บไซต์ ช่วยตรวจสอบว่า Server Block นั้นทำงานอยู่หรือไม่ ในสภาพแวดล้อมจริง ควรกำหนดเจ้าของไฟล์เป็น www-data หรือผู้ใช้ที่ทำการ deploy และตั้งสิทธิ์โฟลเดอร์เป็น 755 ไฟล์เป็น 644 เพื่อความปลอดภัย ส่วนแอปที่ต้องเขียนไฟล์ เช่น WordPress ให้พิจารณาโฟลเดอร์ uploads แยกต่างหาก

ขั้นตอนการสร้าง Nginx Server Block

ตัวอย่างนี้ใช้โดเมน site1.com ซึ่งวิธีเดียวกันนี้สามารถทำซ้ำกับเว็บอื่นๆ ได้ สิ่งสำคัญคือแต่ละเว็บต้องมี server_name, root และไฟล์ล็อกที่ไม่ซ้ำกัน

1. สร้างโฟลเดอร์เว็บไซต์

สร้างโฟลเดอร์สำหรับเก็บไฟล์เว็บ เช่น sudo mkdir -p /var/www/site1.com/public จากนั้นสร้างไฟล์ทดสอบ /var/www/site1.com/public/index.html เช่นใส่ข้อความ "นี่คือหน้าทดสอบของ site1.com" เพื่อยืนยันการทำงาน

ตั้งเจ้าของไฟล์ให้เหมาะสมโดยใช้คำสั่ง sudo chown -R www-data:www-data /var/www/site1.com หากใช้ผู้ใช้สำหรับ deploy ต่างกัน ให้ปรับสิทธิ์กลุ่มตามนั้น หลีกเลี่ยงการตั้งสิทธิ์ 777 เพราะเสี่ยงถูกแฮกเกอร์อัปโหลดไฟล์อันตราย

2. สร้างไฟล์ Server Block

ตามหลักปฏิบัติ Nginx จะเก็บไฟล์คอนฟิกในโฟลเดอร์ /etc/nginx/sites-available และเปิดใช้งานโดยเชื่อมโยงไปยัง /etc/nginx/sites-enabled เช่นไฟล์ /etc/nginx/sites-available/site1.com

ตัวอย่าง Server Block สำหรับ HTTP

server {
    listen 80;
    server_name site1.com www.site1.com;
    root /var/www/site1.com/public;
    index index.html index.htm;
    access_log /var/log/nginx/site1.com.access.log;
    error_log /var/log/nginx/site1.com.error.log;
    location / {
        try_files $uri $uri/ =404;
    }
}

คำสั่งนี้หมายความว่า Nginx จะฟังที่พอร์ต 80 สำหรับโดเมน site1.com และ www.site1.com โดย root ชี้ไปยังไฟล์เว็บใน public กำหนดไฟล์ index และถ้าไม่พบไฟล์ จะคืนค่า 404

3. เปิดใช้งานเว็บไซต์

ใช้คำสั่ง sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com เพื่อสร้าง symbolic link วิธีนี้ดีกว่าการก็อปปี้ไฟล์เพราะสะดวกในการจัดการและแก้ไข

ถ้าไม่ต้องการให้หน้า default ของ Nginx มาแสดงก่อนเว็บไซต์ของคุณ สามารถลบลิงก์ default ได้ด้วยคำสั่ง sudo rm /etc/nginx/sites-enabled/default แต่ต้องมั่นใจว่า Server Block ของคุณทำงานถูกต้องก่อน

4. ทดสอบและรีโหลด Nginx

หลังแก้ไขทุกครั้งให้ทดสอบด้วย sudo nginx -t หากไม่มีข้อผิดพลาดให้ใช้คำสั่ง sudo systemctl reload nginx เพื่อโหลดคอนฟิกใหม่โดยไม่หยุดการให้บริการ รีโหลดปลอดภัยกว่าการ restart เพราะไม่ตัดการเชื่อมต่อทันที

ถ้าพบข้อผิดพลาด ระบบจะแจ้งบรรทัดและไฟล์ที่มีปัญหา เช่น ลืม ;, วงเล็บไม่ปิด, เส้นทางผิด หรือ server_name ซ้ำ ต้องแก้ไขก่อนรีโหลด

เพิ่มเว็บไซต์ที่สองและสาม

ข้อดีของการใช้ Server Blocks คือสามารถทำซ้ำขั้นตอนเดิมกับเว็บไซต์อื่นๆ ได้ง่าย เช่น สำหรับ site2.com สร้างโฟลเดอร์ /var/www/site2.com/public, สร้างไฟล์ /etc/nginx/sites-available/site2.com ปรับ root และ log เป็นของ site2.com แล้วเชื่อมโยงและทดสอบเหมือนเดิม

ตัวอย่าง Server Block สำหรับ site2.com

server {
    listen 80;
    server_name site2.com www.site2.com;
    root /var/www/site2.com/public;
    index index.html;
    access_log /var/log/nginx/site2.com.access.log;
    error_log /var/log/nginx/site2.com.error.log;
    location / {
        try_files $uri $uri/ =404;
    }
}

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

ตั้งค่า SSL และ HTTPS

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

ถ้าใช้ Let’s Encrypt สามารถใช้ Certbot สั่งขอใบรับรองพร้อมตั้งค่าอัตโนมัติ เช่น certbot --nginx -d site1.com -d www.site1.com ระบบจะตรวจหาไฟล์คอนฟิก Nginx และเพิ่มบล็อก HTTPS ให้โดยอัตโนมัติ แต่ควรตรวจสอบไฟล์คอนฟิกหลังทำ เพื่อป้องกันปัญหาการตั้งค่าซ้ำซ้อนหรือบล็อกซ้อนกัน

โดยทั่วไปจะตั้งให้พอร์ต 80 เปลี่ยนเส้นทางแบบถาวร (301) ไปยังพอร์ต 443 เพื่อ SEO ดีขึ้น ให้เลือกว่าต้องการใช้ www หรือไม่ และรวมทุกกรณีไว้ที่ชื่อโดเมนหลักเดียว เช่น หากเลือก https://site1.com ให้เปลี่ยนเส้นทาง traffic จาก http://www.site1.com และ https://www.site1.com ไปยัง https://site1.com เพื่อลดปัญหาคอนเทนต์ซ้ำ

Server Blocks สำหรับ PHP และ WordPress

สำหรับเว็บไซต์ที่ใช้ PHP เช่น WordPress, Laravel หรือแอปพลิเคชัน PHP อื่นๆ ต้องตั้งค่าให้รองรับ PHP-FPM โดยเพิ่มการกำหนด index.php และส่งคำขอ PHP ไปยัง socket ของ PHP-FPM ซึ่งใน Ubuntu PHP 8.3 จะอยู่ที่ /run/php/php8.3-fpm.sock (ขึ้นกับเวอร์ชัน PHP ในเซิร์ฟเวอร์)

ตัวอย่าง Server Block สำหรับ WordPress

server {
    listen 80;
    server_name wordpress-site.com www.wordpress-site.com;
    root /var/www/wordpress-site.com/public;
    index index.php index.html;
    location / {
        try_files $uri $uri/ /index.php?$args;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    }
}

โครงสร้าง try_files ในบล็อกนี้สำคัญสำหรับการทำงานของ permalink ของ WordPress นอกจากนี้ควรพิจารณามาตรการความปลอดภัยเพิ่มเติม เช่น จำกัดการเข้าถึง xmlrpc.php, wp-login.php, การป้องกันการรัน PHP ในโฟลเดอร์ uploads เป็นต้น สำหรับผู้ที่ต้องการโฮสต์ WordPress หลายเว็บบน VPS เดียวกัน แนะนำให้แยกฐานข้อมูลและผู้ใช้แต่ละเว็บ พร้อมนโยบายอัปเดตที่สม่ำเสมอ ดูข้อมูลเพิ่มเติมที่ โฮสติ้ง WordPress

เปรียบเทียบ Nginx Server Blocks กับ Apache VirtualHost

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

ถ้าแอปของคุณพึ่งพา .htaccess มาก Apache อาจใช้งานง่ายกว่า แต่ถ้าต้องการรองรับทราฟฟิคสูง, reverse proxy, cache และระบบสมัยใหม่ Nginx มักเป็นตัวเลือกที่ดีกว่า บางระบบอาจใช้ Nginx เป็น reverse proxy ด้านหน้า และ Apache เป็น backend รันแอปพลิเคชันร่วมกัน

แนวทางปฏิบัติด้านความปลอดภัย

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

• สร้างฐานข้อมูลและผู้ใช้ฐานข้อมูลแยกสำหรับแต่ละเว็บไซต์
• เก็บไฟล์สำคัญ เช่น สำรองข้อมูล, .env, .git, ไฟล์ config และ SQL ไว้นอกเว็บไดเรกทอรี
• ต่ออายุ SSL certificate อย่างสม่ำเสมอ และบังคับใช้ HTTPS
• ใช้ firewall เช่น UFW เปิดเฉพาะพอร์ตที่จำเป็น
• อัปเดต Nginx และระบบปฏิบัติการอย่างสม่ำเสมอ
• แยกเก็บ access_log และ error_log สำหรับแต่ละเว็บไซต์
• จำกัดการเข้าถึงแผงควบคุมด้วย IP หรือระบบยืนยันตัวตนเพิ่มเติม
• หลีกเลี่ยงการตั้งสิทธิ์ไฟล์ 777 ที่เปิดกว้างเกินไป

นอกจากนี้ ควรเพิ่ม HTTP security headers เช่น X-Frame-Options, X-Content-Type-Options, Referrer-Policy และ Content-Security-Policy อย่างเหมาะสม แต่ต้องทดสอบในสภาพแวดล้อมทดสอบก่อนเพราะบางกรณีอาจบล็อกสคริปต์หรือไฟล์สไตล์โดยไม่ตั้งใจ ดูข้อมูลเพิ่มเติมเรื่องความปลอดภัยที่ ความปลอดภัยเว็บไซต์

เคล็ดลับด้านประสิทธิภาพและ SEO

Server Blocks ไม่ใช่แค่เรื่องการเผยแพร่เว็บไซต์ แต่มีผลต่อประสิทธิภาพและคุณภาพ SEO การตั้งค่าเปลี่ยนเส้นทางผิด รูปแบบ canonical ไม่ดี การบีบอัด gzip หรือ brotli ที่ขาดหาย ไฟล์ล็อกใหญ่เกินไป หรือตั้งค่า cache ไม่เหมาะสม ล้วนทำให้เว็บไซต์ช้า Google ให้ความสำคัญกับความเร็ว ความปลอดภัย และความเสถียรของเว็บ

ควรกำหนดโดเมนหลัก (canonical) ให้ชัดเจนสำหรับแต่ละเว็บ ตั้งค่า redirection จาก HTTP ไป HTTPS และ www ไป non-www หรือในทางกลับกันในขั้นตอนเดียว ไม่ควรให้เกิดการเปลี่ยนเส้นทางเป็นทอดๆ เช่น http://site.com → http://www.site.com → https://www.site.com → https://site.com แต่ควรเปลี่ยนเส้นทางโดยตรงไปยังที่ต้องการด้วย 301

ใช้ cache-control headers เพื่อเก็บไฟล์สแตติก เช่น รูป, CSS, JS ในเบราว์เซอร์เป็นระยะเวลาที่เหมาะสม แต่ถ้าไฟล์เปลี่ยนบ่อย ควรใช้เวอร์ชันไฟล์หรือ query string เพื่อบังคับโหลดใหม่ การบีบอัด gzip ช่วยลดปริมาณข้อมูลในไฟล์ text เช่น HTML, CSS, JS และ JSON สำหรับเว็บไซต์ที่มีผู้ใช้เยอะ อาจพิจารณาใช้ Nginx microcache, FastCGI cache หรือ CDN เพิ่มเติม ดูข้อมูล CDN ได้ที่ CDN คืออะไร

การจัดการและติดตาม Log

การแยกจัดเก็บ log เป็นกุญแจสำคัญในการแก้ไขปัญหาของแต่ละเว็บไซต์ access_log บันทึกคำร้องขอจากผู้เยี่ยมชม ส่วน error_log บันทึกปัญหาเกี่ยวกับการตั้งค่า สิทธิ์ ไฟล์ไม่พบ หรือปัญหาเชื่อมต่อกับ backend เช่น PHP-FPM

ข้อผิดพลาดยอดนิยม เช่น 502 Bad Gateway มักเกี่ยวกับ PHP-FPM หรือ backend service, 403 Forbidden มักเกิดจากสิทธิ์ไฟล์หรือไม่มีไฟล์ index, 404 Not Found มักเกิดจาก path หรือกฎ try_files ผิดพลาด

ควรตั้งค่า logrotate เพื่อป้องกันไฟล์ log โตเกินและกินพื้นที่ดิสก์มากเกินไป สำหรับเว็บไซต์เล็กอาจตั้งหมุนเวียนรายวันหรือรายสัปดาห์ ส่วนเว็บไซต์ที่มีทราฟฟิคสูง ควรใช้ระบบเก็บ log รวม ศึกษาเมตริก และตั้งระบบแจ้งเตือน แนะนำตั้งค่าเกณฑ์เตือนเมื่อดิสก์ใกล้เต็ม เพราะถ้า log เขียนไม่ได้จะทำให้เว็บไซต์ล่มได้

ข้อผิดพลาดที่พบบ่อยและวิธีแก้ไขเร็ว

ขณะตั้งค่า Server Blocks อาจเจอปัญหาหลักๆ ดังนี้ ซึ่งการรู้ล่วงหน้าจะช่วยประหยัดเวลามาก

• โดเมนเปิดเว็บผิด: ตรวจสอบ server_name ซ้ำซ้อน และ default server block
• 403 Forbidden: ตรวจสอบโฟลเดอร์ root, สิทธิ์ไฟล์ และไฟล์ index ว่ามีหรือไม่
• 404 Not Found: ตรวจสอบ path root และกฎ try_files
• 502 Bad Gateway: ตรวจสอบว่า PHP-FPM ทำงานและ socket path ถูกต้อง
• SSL certificate ผิดเว็บ: ตรวจสอบ server_name และไฟล์ certificate ในบล็อก 443
• เกิดลูปการเปลี่ยนเส้นทาง: ปรับกฎ redirect HTTP/HTTPS และ www ให้เรียบง่าย
• รีโหลด Nginx ไม่ได้: แก้ไขข้อผิดพลาดตามบรรทัดในผลลัพธ์ nginx -t

ผู้ดูแลมืออาชีพมักจะตรวจสอบตามลำดับนี้: DNS ถูกต้องหรือไม่, Nginx คอนฟิกเปิดใช้งานหรือยัง, โฟลเดอร์ root มีอยู่จริงหรือไม่, สิทธิ์ไฟล์ถูกต้องไหม, คอนฟิกผ่านการทดสอบแล้วหรือยัง, และดู log ว่าบอกอะไรบ้าง วิธีนี้ช่วยแก้ปัญหาได้รวดเร็วโดยไม่ต้องตกใจ

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

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

• โดเมน A หรือ AAAA record ชี้ไปยัง IP เซิร์ฟเวอร์ถูกต้อง
• เลือกโดเมนหลัก (canonical) ระหว่าง www กับ non-www เรียบร้อย
• ตั้งค่า HTTP เปลี่ยนเส้นทาง 301 ไป HTTPS แล้ว
• SSL certificate ใช้งานได้และตั้งค่าต่ออายุอัตโนมัติ
• ตั้งค่า root และไฟล์ล็อกแยกสำหรับแต่ละเว็บ
• คอนฟิก Nginx ผ่านคำสั่ง sudo nginx -t
• มีแผนสำรองข้อมูลและทดสอบการกู้คืนแล้ว
• ตั้งสิทธิ์ไฟล์ตามหลัก minimum privilege
• เปิดเฉพาะพอร์ตที่จำเป็นใน firewall
• ติดตาม error log อย่างน้อย 15 นาทีหลังเปิดใช้งาน

รายการนี้แม้ดูง่าย แต่ช่วยลดความเสี่ยงการล่มของระบบได้มาก โดยเฉพาะการต่ออายุ SSL, ตรวจสอบ DNS และการติดตาม log

สรุป

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

ถ้าคุณกำลังจะเริ่มโปรเจกต์ใหม่ แนะนำให้ชัดเจนเรื่องโดเมน เซิร์ฟเวอร์ และ SSL ก่อน แล้วค่อยตั้งค่า Nginx ตามรายการตรวจสอบด้านบน หากต้องการระบบที่ดูแลง่ายขึ้น ลองดูตัวเลือกของ Hostragons ที่มีทั้ง แพ็กเกจโฮสติ้ง, เซิร์ฟเวอร์ VPS และ ใบรับรอง SSL เพื่อเลือกแพ็กเกจที่เหมาะกับคุณ

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

สามารถโฮสต์เว็บไซต์กี่เว็บด้วย Nginx Server Blocks?

ทางเทคนิค Nginx สามารถโฮสต์เว็บไซต์จำนวนมากบนเซิร์ฟเวอร์เดียวได้ ขึ้นอยู่กับความสามารถของ CPU, RAM, พื้นที่ดิสก์, ปริมาณทราฟฟิค, ภาระฐานข้อมูล และ PHP-FPM โดยเว็บไซต์สแตติกที่มีทราฟฟิคต่ำสามารถโฮสต์ได้หลายสิบเว็บ แต่ถ้าเป็น WordPress หรืออีคอมเมิร์ซที่ใช้ทรัพยากรเยอะ ควรลดจำนวนเว็บลงเพื่อความเสถียร

แต่ละเว็บไซต์จำเป็นต้องมี SSL certificate แยกหรือไม่?

ใช่ หากต้องการให้แต่ละโดเมนหรือซับโดเมนรองรับ HTTPS จำเป็นต้องมี SSL certificate ครอบคลุมโดเมนนั้น อาจใช้ใบรับรองแบบแยก หรือ SAN certificate หรือ wildcard certificate ก็ได้ สิ่งสำคัญคือต้องตั้งค่าให้ Nginx ในบล็อกพอร์ต 443 ใช้ไฟล์ certificate ที่ถูกต้องกับแต่ละโดเมน

สามารถใช้ Server Block สำหรับ subdomain ได้ไหม?

ได้ เช่น blog.site.com หรือ panel.site.com สามารถตั้งค่า server_name แยก และกำหนด root หรือ backend ที่ต่างกันได้ เพียงแค่ต้องตั้งค่า DNS ให้ subdomain นั้นชี้ไปยังเซิร์ฟเวอร์ด้วย A record หรือ CNAME

ความแตกต่างระหว่าง sites-available กับ sites-enabled คืออะไร?

sites-available คือโฟลเดอร์ที่เก็บไฟล์คอนฟิกที่พร้อมใช้งาน ส่วน sites-enabled จะเก็บไฟล์ที่เปิดใช้งานจริง ซึ่งมักจะเป็น symbolic link ที่ชี้ไปยังไฟล์ใน sites-available วิธีนี้ช่วยให้เปิด/ปิดเว็บไซต์ได้ง่ายและเป็นระเบียบ

ถ้าเปิดเว็บไซต์ผิดเว็บเกิดจากอะไร?

สาเหตุหลักมักเกิดจาก DNS ชี้ IP ผิด, ค่า server_name ในไฟล์คอนฟิกผิด, มี default server block ที่จับ request ก่อน หรือบล็อก SSL ที่พอร์ต 443 ผิด ตรวจสอบ DNS, รัน nginx -t, ตรวจสอบลิงก์ใน sites-enabled และดูไฟล์ access_log เพื่อตรวจสอบการร้องขอ