GUI for NGINX: จัดการ Reverse Proxy และ HTTPS ผ่านหน้าเว็บ

• 1. GUI for NGINX คืออะไร
• 2. เปรียบเทียบสองตัวเลือก
• 3. สิ่งที่จะได้จาก Workshop
• 4. ติดตั้ง NGINX Proxy Manager พร้อมเว็บตัวอย่าง
• 5. สร้าง Proxy Host ผ่าน GUI
• 6. เปิด HTTPS ด้วยโดเมนจริง
• 7. ใช้กับ Web App หรือ API ของตนเอง
• 8. Nginx UI เหมาะกับงานแบบไหน
• 9. ปัญหาที่พบบ่อย
• 10. สำรองข้อมูลและอัปเดต
• สรุปการเลือกใช้งาน
• เอกสารอ้างอิง

บทความและ Workshop สำหรับผู้เริ่มต้น ใช้ Docker Compose พร้อมเปรียบเทียบ NGINX Proxy Manager กับ Nginx UI

ตรวจสอบเอกสารอ้างอิงวันที่ 1 ตุลาคม 2569 ชื่อเมนูและขั้นตอนสร้างบัญชีอาจแตกต่างตามรุ่น

#1. GUI for NGINX คืออะไร

GUI หรือ Graphical User Interface คือหน้าจอที่ช่วยให้ผู้ดูแลจัดการระบบผ่านปุ่ม แบบฟอร์ม และตาราง สำหรับ NGINX เครื่องมือกลุ่มนี้ช่วยสร้าง Reverse Proxy จัดการเว็บไซต์ ใบรับรอง HTTPS และตรวจสอบการทำงานผ่านเว็บเบราว์เซอร์

เครื่องมือแต่ละตัวมีขอบเขตต่างกัน ก่อนเลือกจึงควรตอบให้ได้ว่าต้องการ “เพิ่มโดเมนให้บริการที่มีอยู่” หรือ “แก้ไข Configuration ของ NGINX โดยตรง”

ตัวอย่างงานที่พบในห้องปฏิบัติการและระบบจริง ได้แก่ ให้ app.example.com ชี้ไปยังเว็บแอป ให้ api.example.com ชี้ไปยัง API และให้บริการเหล่านั้นใช้ HTTPS โดยผู้ใช้เข้าผ่านพอร์ต 443 ส่วนบริการภายในใช้พอร์ตของตัวเอง

#2. เปรียบเทียบสองตัวเลือก

คำแนะนำของบทความ: หากเป้าหมายคือเพิ่มโดเมนและ HTTPS ให้เว็บแอปหรือ API ให้เริ่มด้วย NGINX Proxy Manager ส่วนผู้ที่มี NGINX เดิมและต้องแก้ Config หรืออ่าน Logs เป็นประจำ ให้พิจารณา Nginx UI และเลือกวิธีติดตั้งให้ตรงกับ NGINX ที่จะจัดการ [1][4][5]

NGINX Proxy Manager มี NGINX ของตัวเองใน Container จึงไม่ใช่เครื่องมือที่ติดตั้งแล้วจะนำ Config ของ NGINX เดิมบน Host เข้ามาจัดการให้อัตโนมัติ ส่วน Docker Image ของ Nginx UI ก็มี NGINX ภายในเช่นกัน การจัดการ NGINX บน Host ควรเลือกวิธีติดตั้งบน Host ตามเอกสาร [2][5]

#3. สิ่งที่จะได้จาก Workshop

เมื่อทำครบจะสามารถเปิดหน้าจัดการ เพิ่ม Proxy Host ให้เว็บไซต์ตัวอย่าง ทดสอบการส่งต่อ HTTP และต่อยอดเป็น HTTPS ด้วยโดเมนจริงได้

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

• Docker Engine หรือ Docker Desktop และ Docker Compose plugin
• พอร์ต 80 และ 443 ของเครื่องทดลองต้องว่าง
• หากทดลอง HTTPS ต้องมีโดเมนจริงที่ควบคุม DNS ได้ และ Server ที่เข้าถึงจากอินเทอร์เน็ตได้ตามวิธี Challenge ที่เลือก

ตรวจสอบเครื่องมือ:

docker version
docker compose version

ตัวอย่างคำสั่ง Shell ในบทความใช้ Bash บน Linux, macOS หรือ WSL

#4. ติดตั้ง NGINX Proxy Manager พร้อมเว็บตัวอย่าง

สร้างโฟลเดอร์:

mkdir nginx-gui-lab
cd nginx-gui-lab

สร้างไฟล์ compose.yaml ดังนี้:

services:
  npm:
    image: jc21/nginx-proxy-manager:2.16.0
    restart: unless-stopped
    environment:
      TZ: Asia/Bangkok
    ports:
      - "80:80"
      - "443:443"
      - "127.0.0.1:81:81"
    volumes:
      - ./data:/data
      - ./letsencrypt:/etc/letsencrypt
    networks:
      - proxy

  demo-web:
    image: nginx:alpine
    restart: unless-stopped
    networks:
      - proxy

networks:
  proxy:
    driver: bridge

2.16.0 เป็น Tag ที่ปรากฏในตัวอย่างเอกสารทางการขณะตรวจสอบ ไม่ใช่การยืนยันว่าเป็นรุ่นล่าสุดตลอดเวลา ก่อนนำไปใช้จริงให้ตรวจสอบ Release และเลือก Tag ที่ผ่านการทดสอบ ส่วน nginx:alpine ใช้เป็นเว็บตัวอย่างสำหรับ Lab [2]

ค่าที่ควรเข้าใจ:

เว็บตัวอย่างไม่ Publish พอร์ตออกจาก Host เพราะ NPM ติดต่อผ่าน Network ภายในได้ การใช้ชื่อ Service เป็น Upstream ช่วยหลีกเลี่ยงการอ้าง IP ของ Container ที่อาจเปลี่ยนหลังสร้างใหม่ [3]

ตรวจสอบไฟล์และเริ่มระบบ:

docker compose config
docker compose up -d
docker compose ps
docker compose logs --tail=100 npm

เปิด http://localhost:81 และทำขั้นตอนสร้างผู้ดูแลหรือเข้าสู่ระบบตามหน้าจอของรุ่นที่ใช้งาน เอกสาร Advanced Configuration อธิบาย First User Setup และการกำหนดผู้ดูแลผ่าน Environment Variables จึงควรใช้ขั้นตอนของรุ่นที่ติดตั้ง ไม่อาศัยรหัสผ่านตัวอย่างจากบทความเก่า [3]

หากรันบน Server ระยะไกล ใช้ SSH Tunnel จากเครื่องผู้ดูแล:

ssh -L 8181:127.0.0.1:81 USER@SERVER_IP

แทน USER และ SERVER_IP ด้วยค่าจริง แล้วเปิด http://localhost:8181 บนเครื่องผู้ดูแล เปิดหน้าต่าง SSH ค้างไว้ระหว่างใช้งาน

#5. สร้าง Proxy Host ผ่าน GUI

ไปที่ส่วน Proxy Hosts แล้วเลือกเพิ่ม Proxy Host ชื่อเมนูอาจต่างกันตามรุ่น

ตั้งค่าการทดลอง HTTP:

บันทึก โดยยังไม่ขอ Certificate ในขั้นตอนนี้

อย่าใส่ localhost เป็น Forward Hostname สำหรับเว็บที่อยู่คนละ Container เพราะ localhost ภายใน NPM หมายถึง Container ของ NPM เอง ตัวอย่างนี้ต้องใช้ demo-web

ทดสอบบนเครื่อง Host โดยไม่ต้องสร้าง DNS จริง:

curl -i --resolve demo.example.com:80:127.0.0.1 http://demo.example.com/

ควรได้สถานะ HTTP/1.1 200 OK และ HTML ของหน้า Welcome จาก NGINX เว็บตัวอย่าง --resolve กำหนด IP ให้คำขอนี้โดยยังส่ง Host Header เป็น demo.example.com จึงทดสอบการเลือก Proxy Host ได้

ถ้าทดสอบจากเครื่องอื่น ให้เปลี่ยน 127.0.0.1 ในคำสั่งเป็น IP ของ Server และตรวจสอบว่าพอร์ต 80 เข้าถึงได้

หากต้องการเปิดผ่าน Browser ใน Lab ให้เพิ่มชื่อโดเมนและ IP ที่ถูกต้องในไฟล์ Hosts ของเครื่องผู้ทดสอบ การแก้ไฟล์ Hosts มีผลเฉพาะเครื่องนั้น และไม่ได้ทำให้โดเมนพร้อมขอ Certificate สาธารณะ

#6. เปิด HTTPS ด้วยโดเมนจริง

ตัวอย่าง demo.example.com ในขั้นตอนก่อนเป็นชื่อสำหรับสาธิต ให้เปลี่ยนเป็นโดเมนที่คุณควบคุม เช่น app.your-domain.com

1. สร้าง DNS A Record ให้โดเมนชี้ไปยัง Public IPv4 ของ Server หากมี AAAA Record ต้องชี้ไปยัง IPv6 ที่ใช้งานได้จริงด้วย
2. ตรวจสอบ Firewall หรือ Security Group และ NAT ให้คำขอเข้าถึง Server ตามวิธี Challenge ที่ใช้
3. เปลี่ยน Domain Names ของ Proxy Host เป็นโดเมนจริง
4. ในส่วน SSL เลือกขอ Certificate จาก Let's Encrypt ทำขั้นตอนอีเมลและยอมรับเงื่อนไขตามหน้า UI
5. เมื่อออก Certificate สำเร็จ เลือกใช้ Certificate และเปิด Force SSL หากต้องการ Redirect HTTP ไป HTTPS
6. ทดสอบด้วย Browser และคำสั่งด้านล่าง

curl -I https://app.your-domain.com/

สำหรับ HTTP-01 Challenge ต้องเปิดให้ระบบตรวจสอบเข้าถึงโดเมนผ่านพอร์ต 80 ได้ หากใช้ DNS Challenge ต้องตั้งค่า DNS Provider และ Credentials ให้ถูกต้อง ใบรับรอง Wildcard ใช้ DNS-01 Challenge

HTTPS ด้านผู้ใช้กับ Protocol ของ Upstream เป็นคนละส่วน: Browser อาจเชื่อมต่อ NPM ด้วย HTTPS แต่ NPM ยังเชื่อมต่อ demo-web:80 ด้วย HTTP ได้ ให้เลือก Scheme ตาม Protocol ที่บริการปลายทางรองรับ

การมี GUI ช่วยลดขั้นตอนตั้งค่า แต่ยังต้องวาง DNS, Network และ Certificate ให้สัมพันธ์กัน

#7. ใช้กับ Web App หรือ API ของตนเอง

แทนที่บริการ demo-web ด้วยแอปจริง และให้บริการนั้นอยู่ใน Docker Network เดียวกับ NPM จากนั้นเปลี่ยน Forward Hostname และ Forward Port ใน GUI

พอร์ตในตารางเป็นตัวอย่าง ต้องตรวจสอบค่าจริงของแอป แอปที่อยู่ใน Container ต้องฟังบน Interface ที่ NPM ติดต่อได้ เช่น 0.0.0.0 ภายใน Container

สำหรับ PHP-FPM พอร์ต 9000 เป็น FastCGI การตั้ง Proxy Host แบบ HTTP ไปยังพอร์ตนี้จะไม่ทำให้ PHP ทำงาน ควรส่งต่อไปยัง NGINX หรือ Apache ของแอปที่รับ HTTP และเชื่อมต่อ PHP-FPM อยู่แล้ว

กรณีแอปกับ NPM อยู่คนละ Compose Project สามารถสร้าง External Network แล้วให้ทั้งสอง Project ใช้ร่วมกันตามแนวทางเอกสาร NPM [3]

#8. Nginx UI เหมาะกับงานแบบไหน

เลือก Nginx UI เมื่ออยากทำงานใกล้กับ Configuration ของ NGINX มากขึ้น เช่น แก้ Site Configuration ดู Logs ตรวจสอบ Config และ Reload หลังบันทึก โครงการยังระบุความสามารถด้าน Backup, เปรียบเทียบ Configuration และจัดการ Certificate [4]

ประเด็นก่อนติดตั้ง:

• หากจัดการ NGINX เดิมบน Linux Host ให้เลือกวิธีติดตั้งบน Host ตามคู่มือ
• Docker Image uozi/nginx-ui มี NGINX ภายใน จึงต้องแยกให้ชัดว่าจะจัดการ Instance ใด
• คู่มือปัจจุบันให้เปิดผ่านพอร์ต Host ที่แมปไปยังพอร์ต 80 ของ Container และมี Install Secret สำหรับ First-run Setup
• โครงการใช้โครงสร้าง sites-available และ sites-enabled จึงต้องตรวจสอบ nginx.conf เดิมก่อนนำมาใช้ [5]

ไม่ควรให้ NPM กับ Nginx UI แก้ Config ของ NGINX Instance เดียวกันพร้อมกัน เพราะแต่ละเครื่องมือมีวิธีจัดเก็บและสร้าง Config ของตัวเอง

#9. ปัญหาที่พบบ่อย

คำสั่งสำหรับวิเคราะห์:

docker compose ps
docker compose logs --tail=100 npm
docker compose logs --tail=100 demo-web
docker compose exec npm nginx -t

nginx -t ใช้ตรวจ Syntax และไฟล์ที่ NGINX ต้องอ่าน ไม่ได้ยืนยันว่า Upstream หรือ DNS ภายนอกทำงานครบถ้วน

#10. สำรองข้อมูลและอัปเดต

ตัวอย่างนี้เก็บข้อมูลลงโฟลเดอร์ data และ letsencrypt บน Host ควรสำรองทั้งสองโฟลเดอร์ รวมถึงไฟล์ Compose

สำหรับ Lab ที่ใช้ SQLite สามารถหยุดบริการชั่วคราวเพื่อสำรองข้อมูลให้สอดคล้องกัน:

docker compose stop
tar -czf nginx-gui-backup.tar.gz compose.yaml data letsencrypt
docker compose start

คำสั่งนี้ทำให้ Lab หยุดให้บริการระหว่างสำรอง หากใช้งานจริงให้วางแผนช่วงหยุดระบบหรือใช้วิธีสำรองที่เหมาะกับฐานข้อมูลและระบบไฟล์ของคุณ

อัปเดตโดยสำรองข้อมูลก่อน เปลี่ยน Image Tag เป็นรุ่นที่เลือกใน Compose แล้วรัน:

docker compose pull
docker compose up -d
docker compose ps

หลังอัปเดตให้ทดสอบหน้า Admin, HTTP, HTTPS และเว็บปลายทาง การดึง Image ด้วย Tag รุ่นเดิมไม่ได้เปลี่ยนระบบไปเป็นรุ่นใหม่โดยอัตโนมัติ

#สรุปการเลือกใช้งาน

NGINX Proxy Manager เหมาะกับการเริ่มทำ Reverse Proxy ให้หลายเว็บหรือ API ผ่านแบบฟอร์ม พร้อมจัดการ HTTPS ส่วน Nginx UI เหมาะกับผู้ดูแลที่ต้องแก้ Configuration และดูการทำงานของ NGINX โดยตรง

Workshop นี้เริ่มจาก HTTP ในเครื่องก่อน เพื่อให้เห็นว่าการจับคู่โดเมนและการส่งต่อไปยังบริการภายในถูกต้อง แล้วจึงต่อยอดเป็น HTTPS ด้วยโดเมนจริง

#เอกสารอ้างอิง

1. NGINX Proxy Manager — Guide และ Features
2. NGINX Proxy Manager — Full Setup Instructions
3. NGINX Proxy Manager — Advanced Configuration
4. Nginx UI — Repository และ Features
5. Nginx UI — Getting Started

การตรวจสอบบทความ: ตรวจสอบตัวอย่าง YAML และความสอดคล้องของ Service, Network และพอร์ตแล้ว แต่ไม่ได้รัน Container หรือออก Certificate จริงในสภาพแวดล้อมนี้