Caddy เทียบกับ Nginx บน VPS: การเปรียบเทียบไฟล์ config

example.com {
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

server {
    listen 80;
    server_name example.com;
    return 301 https://$host$request_uri;
}

บรรทัด TLS ในบล็อก Nginx สมมติว่า Certbot ทำงานไปแล้ว สำหรับ HTTP upstream อย่างข้างต้น Caddy จะส่งผ่านค่า Host header ที่เข้ามาและตั้งค่า X-Forwarded-For, X-Forwarded-Proto, และ X-Forwarded-Host โดยค่าเริ่มต้น. ด้วย Nginx โดยปกติคุณจะเพิ่ม proxy header อย่างชัดเจนเมื่อ upstream ต้องการ host, scheme และ chain ของที่อยู่ client ต้นฉบับ นั่นคือการแลกเปลี่ยนในรูปแบบย่อ: Caddy มาพร้อมค่าเริ่มต้นของ proxy ที่ใช้งานได้จริง ในขณะที่ Nginx ทำให้พฤติกรรมนั้นชัดเจนมากขึ้น

การให้บริการไฟล์ static:

Caddyfile

example.com {
    root * /var/www
    file_server
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    root /var/www;
    index index.html;
    location / {
        try_files $uri $uri/ =404;
    }
}

Basic auth ปกป้องทุกอย่างไว้หลังชื่อผู้ใช้และรหัสผ่าน:

Caddyfile

example.com {
    basic_auth {
        Bob $2a$14$Zkx19XLiW6VYouLHR5NmfOFU0z2GTNmpkT/5qqR7hx4IjWJPDhjvG
    }
    reverse_proxy localhost:3000
}

nginx.conf

server {
    listen 443 ssl;
    server_name example.com;
    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    auth_basic           "Restricted";
    auth_basic_user_file /etc/nginx/.htpasswd;
    location / {
        proxy_pass http://localhost:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

ทั้งสองเครื่องมือทำการ hash รหัสผ่านแยกต่างหาก Caddy ใช้ caddy hash-password; Nginx ใช้ htpasswd เพื่อสร้างไฟล์ .htpasswd ไดเรกทีฟคือ basic_auth ใน Caddy ปัจจุบัน อนึ่ง มันเคยเป็น basicauth จนกระทั่ง v2.8.0 เปลี่ยนชื่อมัน ตามที่ระบุไว้ใน เอกสาร basic_auth ของ Caddy, และบทเรียนเก่าๆ ยังคงทำให้ผู้คนสะดุดกับมัน

เคล็ดลับ: hash ใน Caddyfile นั้นไม่ใช่รหัสผ่าน มันคือผลลัพธ์ bcrypt จาก caddy hash-password. รันคำสั่ง แล้ววางสิ่งที่มันแสดงออกมา Caddy ปฏิเสธรหัสผ่านแบบ plaintext ใน config ซึ่งเป็นค่าเริ่มต้นที่ถูกต้องและเป็นเรื่องน่าประหลาดใจเล็กน้อยในครั้งแรก

ตัว config สื่อเหตุผลด้วยตัวเอง Caddy รวม TLS, proxy header ที่สมเหตุสมผล และ redirect ไว้ในไม่กี่บรรทัด Nginx ชัดเจนและยาว และมอบทุกปุ่มปรับให้คุณ หากคุณใช้เวลาหลายปีกับ Nginx ความยาวก็คือความเคยชิน และการควบคุมก็คือประเด็นสำคัญ หากคุณยังไม่เคย Caddyfile คือ config ที่คุณสามารถจดจำได้ในหัว ประเด็นเชิงปฏิบัติง่ายๆ ก็คือ: config ของ Caddy อ่านเข้าใจได้ง่ายกว่าเมื่อมองผ่านๆ ในขณะที่ Nginx ให้การควบคุมที่ชัดเจนกว่า

ประสิทธิภาพและหน่วยความจำ: อ่านผลการทดสอบมาตรฐานอย่างระมัดระวัง

การทดสอบที่เผยแพร่ชี้ไปในทิศทางทั่วไปเดียวกัน: Nginx มักใช้หน่วยความจำน้อยกว่าและมักนำหน้าในด้าน throughput ดิบ แต่ขนาดของข้อได้เปรียบนั้นขึ้นอยู่กับสภาพแวดล้อมเป็นอย่างมาก

In การทดสอบ VM แบบสี่คอร์จากบุคคลภายนอกหนึ่งรายการ, Nginx ทำได้ประมาณ 48,000 request ต่อวินาที เมื่อเทียบกับประมาณ 42,000 สำหรับ Caddy การทดสอบเดียวกันรายงาน latency HTTPS p99 ที่ 2.1 ms สำหรับ Nginx และ 2.4 ms สำหรับ Caddy ให้มองว่าสิ่งเหล่านั้นเป็นผลลัพธ์จากการตั้งค่าหนึ่งแบบ ไม่ใช่ส่วนต่างประสิทธิภาพสากล

ช่วงค่าหน่วยความจำในตารางเปรียบเทียบมาจาก การทดสอบ VPS แยกต่างหาก. อีก การทดสอบแบบจำลองที่ 50,000 การเชื่อมต่อพร้อมกัน รายงาน 145 MB สำหรับ Nginx และ 520 MB สำหรับ Caddy แต่การทดสอบนั้นใช้ฮาร์ดแวร์และเงื่อนไขภาระงานที่แตกต่างกันอย่างมาก ตัวเลขสัมบูรณ์ของมันไม่ควรถูกนำมาเปรียบเทียบโดยตรงกับตัวเลข VPS ด้านบน

ข้อสรุปที่เชื่อถือได้นั้นแคบกว่า: โดยทั่วไป Nginx ใช้หน่วยความจำน้อยกว่าและมีแนวโน้มนำหน้าภายใต้ภาระงานที่มี throughput สูงหรือ concurrency สูง สำหรับ reverse proxy บน VPS ขนาดเล็กถึงกลางทั่วไป ทั้งสองมักเร็วพอ ดังนั้นความเรียบง่ายในการปฏิบัติงานจึงมักเป็นปัจจัยตัดสินที่มีประโยชน์กว่า

ข้อสรุปของส่วนนี้: เลือกโดยพิจารณาจากการปฏิบัติงาน เว้นแต่เซิร์ฟเวอร์ของคุณจะมีหน่วยความจำจำกัดหรือการทดสอบภาระงานของคุณเองแสดงว่า throughput ของ proxy คือคอขวด

จุดที่ต้องระวังเรื่อง Wildcard Cert (Caddy ไม่ได้เป็น Zero-Config เสมอไป)

Caddy สามารถทำ wildcard certificate โดยอัตโนมัติได้ แต่ไม่ใช่ด้วย challenge เริ่มต้นแบบ HTTP-01 หรือ TLS-ALPN-01 certificate สำหรับ *.example.com ต้องการการตรวจสอบแบบ DNS-01, ซึ่ง Let's Encrypt กำหนดสำหรับ wildcard certificate นั่นหมายถึงปลั๊กอินผู้ให้บริการ DNS (สร้างเข้าไปใน Caddy binary ของคุณผ่าน xcaddy) บวกกับ API token สำหรับ DNS host ของคุณ ซึ่งกำหนดค่าไว้ในบล็อก tls มันไม่ใช่เรื่องแบบพิมพ์บรรทัดเดียวแล้วเดินจากไปที่ Caddy โฆษณา

สิ่งนี้ส่งผลกระทบต่อผู้ใช้ homelab ที่วางบริการจำนวนมากไว้ภายใต้โดเมนจริงที่พวกเขาควบคุม เช่น *.home.example.com, และคิดว่าการออก wildcard นั้นเป็นอัตโนมัติเหมือนกับ app.example.com. สำหรับชื่อภายในล้วนๆ เช่น *.homelab.internal, ให้มองว่านั่นเป็นขอบเขตของ PKI ภายใน/ท้องถิ่น ไม่ใช่ wildcard สาธารณะของ Let's Encrypt เพื่อให้ชัดเจน: Caddy ทำ wildcard ได้ดี เพียงแต่ไม่ทำด้วย challenge เริ่มต้น และการตั้งค่าก็ยกระดับขึ้นจากกรณีโดเมนเดียว Nginx ก็อยู่ในสถานการณ์เดียวกันตรงนี้ เนื่องจากข้อกำหนด DNS-01 มาจาก Let's Encrypt ไม่ใช่จากเซิร์ฟเวอร์

หากคุณต้องการ GUI: Nginx Proxy Manager (หมายเหตุสั้นๆ)

Nginx Proxy Manager เป็นคนละสิ่งกับสองเครื่องมือข้างต้น และคุ้มค่าที่จะกล่าวถึงสักหนึ่งย่อหน้าเพราะชื่อทำให้ผู้คนสับสน NPM เป็นตัวห่อ GUI ทับ Nginx: มันจัดการกฎ reverse-proxy และ cert ของ Let's Encrypt ผ่านเว็บอินเทอร์เฟซบน port 81 มันไม่ใช่ Nginx core และไม่ได้ถูกตั้งค่าแบบเดียวกับ Nginx core

การแลกเปลี่ยนก็คือแบบคลิกเทียบกับ config ตามปกติ NPM เป็นปุ่มง่ายๆ จนกว่าคุณจะก้าวออกจากเส้นทางที่ราบรื่น การตั้งค่าของมันถูกจัดการผ่านฐานข้อมูลแอปพลิเคชันแทนที่จะเป็นไฟล์ config ไฟล์เดียวที่แก้ไขด้วยมือ การตั้งค่า Docker เริ่มต้นใช้ SQLite ในขณะที่ MySQL/MariaDB และ PostgreSQL เป็นตัวเลือกฐานข้อมูลภายนอกที่รองรับ ความแตกต่างนั้นยังส่งผลต่อความสามารถในการเคลื่อนย้าย: การตั้งค่า Caddy มักสามารถย้ายได้โดยการคัดลอก Caddyfile ไฟล์เดียว, ในขณะที่การใช้งาน Nginx Proxy Manager ต้องการให้ ข้อมูลแอปพลิเคชันและฐานข้อมูล ถูกเก็บรักษาไว้ NPM เป็นตัวเลือกที่ดีหากคุณชอบการคลิกมากกว่าการแก้ไขจริงๆ และการตั้งค่าของคุณยังคงเรียบง่าย มันเป็นตัวเลือกที่ผิดสำหรับ workflow แบบ infrastructure-as-code

การย้ายจาก Nginx ไป Caddy (สิ่งที่แปลงได้และสิ่งที่แปลงไม่ได้)

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

สิ่งที่แปลงได้และง่ายขึ้น ตาม คู่มือการแปลงของชุมชน Caddy:

• สำหรับ HTTP upstream, reverse_proxy ส่งผ่านค่า Host header ที่เข้ามาและ ตั้งค่า header มาตรฐาน X-Forwarded-* โดยค่าเริ่มต้น, ดังนั้นบรรทัด proxy_set_header เหล่านั้นส่วนใหญ่จะหายไป
• PHP ยุบจากบล็อก location ที่มี try_files บวก fastcgi_pass บวกกับพารามิเตอร์กองโตให้เหลือเพียง php_fastcgi ไดเรกทีฟเดียว
• การจัดการ WebSocket เป็นแบบอัตโนมัติใน Caddy v2 หากบทเรียนบอกให้คุณเพิ่มไดเรกทีฟ websocket แยกต่างหาก นั่นคือสิ่งตกค้างจาก Caddy v1 ให้เพิกเฉยต่อมัน

สิ่งที่แปลงอัตโนมัติไม่ได้: อะไรก็ตามที่ผูกกับโมดูล Nginx เฉพาะที่ Caddy ไม่มี, ตรรกะ rewrite และ location ที่ซับซ้อนซึ่งคุณจะต้องคิดใหม่แทนที่จะย้ายมา และการตั้งค่า wildcard cert ที่จะพาคุณกลับไปที่การตั้งค่า DNS-challenge จากหัวข้อด้านบน เผื่อเวลาไว้สำหรับโมดูลและการ rewrite ส่วนที่เหลือมักเป็นการลดจำนวนบรรทัดโดยรวม

คุณควรติดตั้งตัวไหน? (การตัดสินใจ)

คุณได้เห็น config, ตัวเลข, จุดที่ต้องระวังเรื่อง wildcard และต้นทุนการย้ายแล้ว ดังนั้นนี่คือข้อสรุป ติดตั้ง Caddy หากคุณเป็นนักพัฒนาเดี่ยวหรือทีมเล็ก นี่เป็นการใช้งาน VPS ใหม่ คุณต้องการ TLS แบบตั้งแล้วลืมได้ คุณกำลังรัน Docker พร้อมการกำหนดเส้นทางแบบง่าย หรือคุณเพียงต้องการ config ที่จดจำได้ง่าย นั่นคือคนส่วนใหญ่ที่อ่านบทความนี้

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

ไม่ว่าคุณจะเลือกตัวไหน ขั้นตอนต่อไปคือการนำมันขึ้นเครื่อง ทั้งคู่ Caddy และ Nginx มีให้ใช้งานแบบติดตั้งคลิกเดียวใน marketplace ของเรา ดังนั้นคุณสามารถข้ามงานติดตั้งและไปที่ Caddyfile หรือ server block ได้เลย VPS ขนาด 1 GB เป็นจุดเริ่มต้นที่สมเหตุสมผลสำหรับการใช้งานไซต์เดียวที่มีทราฟฟิกต่ำ แต่ให้ปรับขนาดเซิร์ฟเวอร์ให้เหมาะกับแอปพลิเคชันและทราฟฟิกที่อยู่หลัง proxy มากกว่าตัว proxy เพียงอย่างเดียว หากคุณใช้ Caddy เป็นประตูหน้าสำหรับบริการแบบ self-hosted มันสามารถอยู่หน้า stack การมอนิเตอร์ Prometheus และ Grafana หรือ การใช้งาน Uptime Kuma โดยไม่ต้องการเครื่องมือ TLS แยกต่างหาก

ข้อสรุปของส่วนนี้: เลือก Caddy เว้นแต่คุณจะมีเหตุผลเฉพาะที่ชี้ไปที่ Nginx

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