Caddy reverse proxy: HTTPS tự động chỉ với vài dòng cấu hình
Caddy reverse proxy là cách dựng cổng vào cho ứng dụng web mà không phải tự lo chứng chỉ HTTPS. Chỉ cần ghi tên miền và địa chỉ ứng dụng phía sau, Caddy tự xin chứng chỉ, tự gia hạn và tự chuyển HTTP sang HTTPS. Bài này ProxyVN hướng dẫn viết Caddyfile từ cơ bản tới chia tải, xử lý header, WebSocket, chạy bằng Docker và cách sửa những lỗi cấp chứng chỉ hay gặp. Tham khảo dịch vụ tại ProxyVN.
Tổng quan về Caddy reverse proxy
Caddy là máy chủ web viết bằng Go, nổi tiếng nhờ bật HTTPS mặc định. Phần reverse proxy là một chỉ thị trong cấu hình, nhưng lại là lý do phần lớn người dùng chọn Caddy cho máy chủ nhỏ và vừa.
Điểm khác biệt so với máy chủ web truyền thống
Với Nginx hay Apache, bật HTTPS gồm nhiều bước rời rạc: cài Certbot, xin chứng chỉ, sửa cấu hình để trỏ tới tệp chứng chỉ, đặt lịch gia hạn, rồi viết thêm khối chuyển hướng cổng 80. Mỗi bước là một chỗ có thể quên hoặc sai.
Caddy gộp tất cả vào một hành vi mặc định. Hễ cấu hình có tên miền công khai là Caddy tự lo phần chứng chỉ. Anh em không phải viết một dòng nào liên quan tới SSL nếu không có nhu cầu đặc biệt. Khái niệm reverse proxy nói chung đã có bài reverse proxy là gì, ở đây ProxyVN chỉ tập trung vào cách làm với Caddy.
Khi nào nên chọn Caddy
Caddy hợp nhất khi anh em muốn cấu hình bằng tệp văn bản ngắn gọn, quản lý được bằng Git, mà vẫn có HTTPS tự động. Các trường hợp điển hình gồm:
- Máy chủ cá nhân chạy vài ứng dụng như n8n, trang quản lý ảnh, bảng theo dõi.
- Đội phát triển cần môi trường thử nghiệm có HTTPS thật để test đăng nhập, cookie bảo mật.
- Dịch vụ SaaS nhỏ cần cấp chứng chỉ tự động cho tên miền riêng của khách hàng.
- Môi trường nội bộ muốn HTTPS cho localhost mà không phải tự tạo chứng chỉ.
Nếu anh em thích bấm chọn trên giao diện web hơn là sửa tệp, bài Nginx Proxy Manager là lựa chọn phù hợp hơn. Hai công cụ cùng giải một bài toán, chỉ khác cách thao tác.
Cách Caddy tổ chức cấu hình
Caddy hỗ trợ hai dạng cấu hình. Caddyfile là tệp văn bản thân thiện, viết tay dễ dàng. JSON là định dạng gốc, đầy đủ mọi tuỳ chọn, thường dùng khi cấu hình qua API. Trong bài này ProxyVN dùng Caddyfile vì nó ngắn và dễ đọc hơn nhiều.
Caddy còn có một API quản trị chạy ở cổng 2019 trên localhost. Lệnh nạp lại cấu hình thực chất gửi cấu hình mới qua API này, nên Caddy đổi cấu hình mà không làm rớt kết nối đang có.
Cài đặt và chạy thử Caddy reverse proxy

Hai dòng là đủ cho một trang HTTPS
Phần này đi từ cách nhanh nhất là một dòng lệnh, tới cách chuẩn là Caddyfile chạy dưới dạng dịch vụ hệ thống. Anh em nên thử cách nhanh trước để thấy Caddy hoạt động, rồi mới chuyển sang cấu hình lâu dài.
Cài Caddy trên Ubuntu và Debian
Caddy có kho cài đặt chính thức cho Debian và Ubuntu. Sau khi thêm kho theo hướng dẫn trên trang chủ, anh em cài bằng apt. Gói cài sẵn một dịch vụ systemd tên `caddy`, đọc cấu hình từ `/etc/caddy/Caddyfile` và chạy dưới người dùng riêng.
sudo apt install -y debian-keyring debian-archive-keyring apt-transport-https curl
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | sudo gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | sudo tee /etc/apt/sources.list.d/caddy-stable.list
sudo apt update
sudo apt install caddy
Cài qua gói có lợi là dịch vụ tự khởi động cùng máy và đã được cấp quyền dùng cổng 80, 443. Nếu chạy tệp nhị phân tải tay, trên Linux anh em phải cấp quyền bind cổng thấp bằng lệnh `setcap`, nếu không Caddy sẽ báo lỗi permission denied.
Chạy thử bằng một dòng lệnh
Theo hướng dẫn nhanh về reverse proxy của Caddy, lệnh `caddy reverse-proxy` dựng ngay một reverse proxy mà không cần tệp cấu hình. Giả sử ứng dụng của anh em chạy ở cổng 9000:
# Nghe ở cổng 2080, chuyển tới cổng 9000, chỉ HTTP
caddy reverse-proxy --from :2080 --to :9000
# Bỏ --from: Caddy dùng HTTPS cho localhost bằng CA nội bộ
caddy reverse-proxy --to :9000
# Tên miền công khai: Caddy tự xin chứng chỉ
caddy reverse-proxy --from example.com --to :9000
Lệnh này hợp để thử nhanh hoặc demo cho đồng nghiệp. Tắt cửa sổ dòng lệnh là proxy dừng, nên không dùng cho môi trường chạy thật.
Caddyfile tối thiểu
Dạng chuẩn là viết Caddyfile. Một trang HTTPS hoàn chỉnh chỉ cần hai dòng: tên miền và chỉ thị reverse_proxy.
app.tenmien.vn {
reverse_proxy localhost:9000
}
Lưu tệp vào `/etc/caddy/Caddyfile` rồi chạy `sudo systemctl reload caddy`. Khoảng vài giây sau, truy cập `https://app.tenmien.vn` là thấy ứng dụng với ổ khoá xanh. Caddy cũng tự chuyển mọi yêu cầu HTTP ở cổng 80 sang HTTPS, anh em không phải viết thêm khối chuyển hướng.
Nhiều trang trong một Caddyfile
Mỗi tên miền là một khối riêng, đặt nối tiếp nhau trong cùng tệp. Ví dụ một máy chủ chạy ba ứng dụng:
n8n.tenmien.vn {
reverse_proxy localhost:5678
}
anh.tenmien.vn {
reverse_proxy localhost:2283
}
theodoi.tenmien.vn {
reverse_proxy 192.168.1.30:3001
}
Mỗi khối được cấp chứng chỉ riêng. Thêm ứng dụng mới chỉ là thêm một khối ba dòng rồi nạp lại. Đây là lý do nhiều anh em làm homelab chuyển hẳn sang Caddy sau khi thử.
Cơ chế HTTPS tự động của Caddy reverse proxy
Hiểu cơ chế xin chứng chỉ giúp anh em biết vì sao đôi khi nó không chạy. Phần này tóm tắt các điều kiện và cách Caddy xử lý khi gặp lỗi, dựa theo tài liệu Automatic HTTPS của Caddy.
Điều kiện để có chứng chỉ công khai
Caddy chỉ xin được chứng chỉ công khai khi đủ các điều kiện sau:
- Bản ghi A hoặc AAAA của tên miền trỏ về máy chủ.
- Cổng 80 và 443 truy cập được từ bên ngoài, hoặc được chuyển tiếp về máy chủ.
- Caddy có quyền bind vào hai cổng này.
- Thư mục dữ liệu ghi được và tồn tại lâu dài.
- Tên miền xuất hiện trong cấu hình.
Tên miền dạng `.localhost`, `.local`, `.internal`, `.home.arpa` hay địa chỉ IP không nhận chứng chỉ công khai. Với các tên này, Caddy chuyển sang dùng CA nội bộ của chính nó.
Ba kiểu xác minh tên miền
Caddy hỗ trợ ba kiểu thử thách ACME để chứng minh anh em sở hữu tên miền:
- HTTP-01: xác minh qua cổng 80, bật mặc định.
- TLS-ALPN-01: xác minh qua cổng 443, bật mặc định.
- DNS-01: xác minh bằng bản ghi TXT, không cần mở cổng nào, nhưng phải có khoá API của nhà cung cấp DNS.
Hai kiểu đầu chạy song song, Caddy chọn ngẫu nhiên và học xem kiểu nào thành công nhiều hơn. Khi bật DNS-01, hai kiểu kia mặc định bị tắt. DNS-01 cũng là cách duy nhất để xin chứng chỉ wildcard.
Hai nhà cấp và cơ chế thử lại
Caddy bật sẵn hai nhà cấp chứng chỉ là Let's Encrypt và ZeroSSL. Nếu một bên lỗi, Caddy chuyển sang bên kia. Khi mọi cách đều thất bại, Caddy giãn dần thời gian giữa các lần thử, tối đa một ngày một lần, kéo dài tới 30 ngày.
Trong lúc thử lại, Caddy dùng môi trường staging của Let's Encrypt để không đốt hạn mức thật. Đây là điểm Caddy làm tốt hơn hẳn việc tự chạy Certbot bằng tay, vì người mới hay bị khoá hạn mức sau vài lần thử sai liên tiếp.
HTTPS cho localhost
Với localhost và IP nội bộ, Caddy tự dựng một CA riêng và cấp chứng chỉ từ CA đó. Lần đầu chạy, Caddy cố cài chứng chỉ gốc vào kho tin cậy của hệ điều hành, có thể hỏi mật khẩu quản trị. Các tệp CA nằm trong `pki/authorities/local` của thư mục dữ liệu.
Tính năng này rất tiện cho lập trình viên cần test cookie `Secure` hay API chỉ chạy trên HTTPS. Muốn hiểu thêm chứng chỉ hoạt động thế nào giữa trình duyệt và proxy, anh em xem bài proxy SSL là gì.
Chia tải và kiểm tra sức khoẻ với Caddy reverse proxy

Chia tải cho nhiều máy chủ phía sau
Khi ứng dụng chạy trên nhiều máy hoặc nhiều tiến trình, Caddy có thể chia yêu cầu đều cho tất cả. Phần này dựa trên tài liệu chỉ thị reverse_proxy.
Khai báo nhiều upstream
Anh em liệt kê nhiều địa chỉ phía sau trên cùng một dòng, hoặc dùng dải cổng:
app.tenmien.vn {
reverse_proxy node1:8080 node2:8080 node3:8080
}
api.tenmien.vn {
reverse_proxy localhost:8001-8006
}
Có một giới hạn hay khiến người mới bối rối: địa chỉ upstream không được chứa đường dẫn hay tham số truy vấn. Viết `localhost:9000/api` sẽ báo lỗi. Muốn đổi đường dẫn, anh em dùng chỉ thị `rewrite` hoặc `handle_path` trước khi chuyển tiếp.
Các chính sách chia tải
Mặc định Caddy chọn ngẫu nhiên một upstream. Anh em đổi bằng tuỳ chọn `lb_policy`. Bảng dưới tóm tắt các chính sách hay dùng:
Chính sách |
Cách chọn |
Hợp với |
|---|---|---|
random |
Ngẫu nhiên, mặc định |
Các máy cấu hình giống nhau |
round_robin |
Lần lượt từng máy |
Tải đều, yêu cầu ngắn |
least_conn |
Máy ít kết nối nhất |
Yêu cầu dài, thời gian xử lý khác nhau |
ip_hash |
Theo IP người dùng |
Cần giữ phiên trên một máy |
cookie |
Theo cookie gán sẵn |
Giữ phiên khi IP người dùng thay đổi |
first |
Máy đầu tiên còn sống |
Mô hình chính và dự phòng |
Chính sách `first` rất hữu ích cho mô hình một máy chính, một máy dự phòng. Caddy luôn gửi tới máy đầu tiên, chỉ chuyển sang máy thứ hai khi máy đầu bị đánh dấu không khoẻ.
Kiểm tra sức khoẻ chủ động và bị động
Kiểm tra chủ động là Caddy tự gọi định kỳ vào một đường dẫn của từng upstream. Kiểm tra bị động là Caddy theo dõi các yêu cầu thật, máy nào lỗi nhiều thì tạm loại ra. Ví dụ kết hợp cả hai:
app.tenmien.vn {
reverse_proxy node1:8080 node2:8080 {
lb_policy least_conn
lb_retries 2
health_uri /healthz
health_interval 10s
health_timeout 3s
fail_duration 30s
max_fails 3
}
}
Theo tài liệu, khoảng kiểm tra mặc định là 30 giây và thời gian chờ là 5 giây. Thử lại khi lỗi mặc định tắt, nên anh em cần bật `lb_retries` hoặc `lb_try_duration` nếu muốn người dùng không thấy lỗi khi một máy chết giữa chừng.
So với HAProxy khi chia tải lớn
Caddy đủ tốt cho chia tải ở quy mô vừa phải. Với hệ thống cần chia tải tầng TCP, hàng trăm nghìn kết nối đồng thời và thống kê chi tiết, HAProxy vẫn là lựa chọn chuyên dụng hơn. Bài HAProxy là gì đi sâu vào phần này. Nhiều hệ thống dùng cả hai: HAProxy ở tầng ngoài, Caddy phía sau lo HTTPS và định tuyến theo tên miền.
Xử lý header và IP thật qua Caddy reverse proxy
Header quyết định ứng dụng phía sau nhìn thấy gì về người dùng. Cấu hình sai phần này dẫn tới ứng dụng ghi nhật ký toàn IP của proxy, hoặc tệ hơn là tin vào IP giả do người dùng tự gửi.
Header mặc định Caddy gửi xuống
Caddy chuyển nguyên các header của yêu cầu, kể cả Host, đồng thời tự đặt ba header chuẩn: `X-Forwarded-For`, `X-Forwarded-Proto` và `X-Forwarded-Host`. Ứng dụng phía sau đọc các header này để biết IP thật của người dùng và việc họ có đang dùng HTTPS hay không.
Theo mặc định, Caddy bỏ qua giá trị X-Forwarded-* mà người dùng tự gửi lên để tránh giả mạo. Đây là hành vi an toàn, khác với một số máy chủ khác nối thêm vào chuỗi có sẵn.
Khai báo trusted_proxies
Khi Caddy đứng sau một lớp proxy khác như Cloudflare hay bộ cân bằng tải đám mây, nó cần tin vào header của lớp đó. Tài liệu khuyên khai báo ở phần tuỳ chọn toàn cục để áp dụng cho mọi trang:
{
servers {
trusted_proxies static 173.245.48.0/20 103.21.244.0/22
}
}
app.tenmien.vn {
reverse_proxy localhost:9000
}
Chỉ nên khai báo đúng các dải IP của lớp proxy phía trước. Khai báo `0.0.0.0/0` cho tiện là mở cửa để bất kỳ ai cũng giả được IP. Nếu lớp phía trước dùng PROXY protocol thay vì header, Caddy có module listener wrapper riêng để đọc.
Thêm, sửa, xoá header
Hai tuỳ chọn `header_up` và `header_down` lần lượt sửa header gửi xuống upstream và header trả về cho người dùng. Dấu `+` để thêm, dấu `-` để xoá, không dấu là đặt giá trị:
app.tenmien.vn {
reverse_proxy localhost:9000 {
header_up X-Real-IP {remote_host}
header_up -Authorization
header_down -Server
header_down +X-Frame-Options "SAMEORIGIN"
}
}
Ví dụ trên gửi thêm header `X-Real-IP` cho các ứng dụng cũ chỉ đọc header này, đồng thời ẩn header Server khỏi phản hồi. Từ bản 2.11, Caddy tự đặt Host phù hợp khi upstream dùng HTTPS, nên anh em ít phải sửa Host bằng tay như trước.
Upstream chạy HTTPS
Khi ứng dụng phía sau tự phục vụ HTTPS, anh em ghi scheme `https://` trước địa chỉ. Nếu upstream dùng chứng chỉ tự ký trong mạng nội bộ, có tuỳ chọn bỏ qua xác minh, nhưng tài liệu ghi rõ không dùng cho môi trường thật. Cách đúng là khai báo CA nội bộ qua `tls_trust_pool`.
WebSocket và luồng dữ liệu qua Caddy reverse proxy
Ứng dụng thời gian thực như chat, bảng điều khiển trực tiếp hay công cụ AI trả lời từng chữ đều cần kết nối kéo dài. Caddy xử lý các trường hợp này khá gọn.
WebSocket không cần cấu hình thêm
Khác với Nginx phải thêm header Upgrade và Connection, Caddy tự nhận ra yêu cầu nâng cấp WebSocket rồi mở đường hầm hai chiều. Anh em chỉ cần reverse_proxy như bình thường.
Điểm cần biết là các kết nối WebSocket mặc định bị đóng khi nạp lại cấu hình. Với ứng dụng nhạy cảm, anh em dùng `stream_close_delay` để cho kết nối cũ thêm thời gian kết thúc tự nhiên, tránh mọi người dùng bị ngắt cùng lúc.
Server-Sent Events và phản hồi từng phần
Ứng dụng AI hay trả kết quả dạng luồng, từng đoạn một. Với kiểu nội dung `text/event-stream`, Caddy tự đẩy dữ liệu ngay khi có. Với các trường hợp khác, tuỳ chọn `flush_interval -1` bật chế độ độ trễ thấp, đẩy dữ liệu sau mỗi lần ghi:
ai.tenmien.vn {
reverse_proxy localhost:11434 {
flush_interval -1
}
}
Thiếu dòng này, người dùng có thể thấy câu trả lời hiện ra một cục sau vài giây thay vì chạy từng chữ. Lỗi này hay bị nhầm là ứng dụng chậm.
Chặn và thay phản hồi lỗi
Khối `handle_response` cho phép bắt phản hồi từ upstream theo mã trạng thái rồi xử lý riêng. Ví dụ khi ứng dụng trả 502 hay 503, Caddy hiện một trang bảo trì thân thiện thay vì trang lỗi thô. Tính năng này cũng dùng được cho mô hình xác thực, khi upstream trả về header báo đã đăng nhập thì Caddy mới chuyển tiếp tiếp.
Chạy Caddy reverse proxy bằng Docker

Chạy Caddy trong Docker
Docker là cách triển khai phổ biến nhất hiện nay, đặc biệt khi các ứng dụng phía sau cũng chạy bằng container. Phần này dựa theo trang image Caddy chính thức trên Docker Hub.
Tệp compose mẫu
Tạo thư mục dự án có thư mục con `conf` chứa Caddyfile, rồi viết tệp compose:
services:
caddy:
image: caddy:2
restart: unless-stopped
cap_add:
- NET_ADMIN
ports:
- "80:80"
- "443:443"
- "443:443/udp"
volumes:
- ./conf:/etc/caddy
- caddy_data:/data
- caddy_config:/config
volumes:
caddy_data:
caddy_config:
Cổng 443 UDP dành cho HTTP/3. Quyền `NET_ADMIN` không bắt buộc, chỉ giúp thư viện QUIC tăng bộ đệm UDP. Với môi trường thật, anh em nên ghim một phiên bản cụ thể thay vì tag chung.
Hai lưu ý về volume
Thứ nhất, thư mục `/data` phải được giữ lâu dài. Nó chứa chứng chỉ, khoá riêng và dữ liệu OCSP, không phải bộ nhớ đệm. Mất thư mục này, mỗi lần tạo lại container Caddy phải xin chứng chỉ mới, rất dễ chạm hạn mức Let's Encrypt.
Thứ hai, hãy gắn cả thư mục `conf` thay vì gắn riêng tệp Caddyfile. Nhiều trình soạn thảo lưu tệp bằng cách tạo tệp mới thay tệp cũ, khi đó container vẫn giữ bản cũ và lệnh nạp lại không có tác dụng.
Nạp lại cấu hình và gọi container khác
Sau khi sửa Caddyfile, anh em nạp lại mà không phải khởi động lại container:
docker compose exec -w /etc/caddy caddy caddy reload
Nếu các ứng dụng phía sau chạy chung mạng compose, anh em ghi tên dịch vụ thay cho localhost, ví dụ `reverse_proxy n8n:5678`. Bên trong container Caddy, localhost là chính nó, nên ghi localhost sẽ báo lỗi kết nối.
Thêm plugin bằng xcaddy
Một số tính năng như DNS-01 với Cloudflare cần plugin không có sẵn. Image `builder` cho phép biên dịch Caddy kèm plugin:
FROM caddy:2-builder AS builder
RUN xcaddy build --with github.com/caddy-dns/cloudflare
FROM caddy:2
COPY --from=builder /usr/bin/caddy /usr/bin/caddy
Image cuối vẫn nhỏ gọn vì chỉ chép tệp nhị phân đã biên dịch. Xong anh em đổi `image:` trong compose thành `build: .` và chạy lại.
So sánh Caddy reverse proxy với Nginx và Traefik
Mỗi công cụ có thế mạnh riêng. Chọn đúng từ đầu giúp đỡ mất công chuyển đổi sau này.
Bảng so sánh ngắn
Bảng dưới so sánh ba reverse proxy mã nguồn mở hay dùng nhất cho máy chủ nhỏ và vừa:
Tiêu chí |
Caddy |
Nginx |
Traefik |
|---|---|---|---|
HTTPS tự động |
Mặc định |
Cần Certbot |
Có, cần khai báo |
Độ dài cấu hình |
Rất ngắn |
Dài, nhiều chỉ thị |
Trung bình, qua nhãn |
WebSocket |
Tự xử lý |
Cần thêm header |
Tự xử lý |
Tự phát hiện container |
Cần plugin |
Không |
Có sẵn |
Tài liệu tiếng Việt |
Ít |
Rất nhiều |
Ít |
Nginx vẫn mạnh ở tài liệu phong phú và khả năng tinh chỉnh từng chi tiết. Bài cấu hình Nginx làm reverse proxy phù hợp nếu anh em cần kiểm soát sâu bộ đệm và hiệu năng.
Hiệu năng trong thực tế
Với máy chủ nhỏ vài chục đến vài trăm yêu cầu mỗi giây, khác biệt hiệu năng giữa ba công cụ gần như không đáng kể. Thứ quyết định là thời gian anh em bỏ ra để cấu hình và bảo trì. Caddy thắng ở điểm này nhờ cấu hình ngắn và ít phải động tới chứng chỉ.
Ở quy mô rất lớn, Nginx có lợi thế nhờ được tối ưu nhiều năm và có hệ sinh thái module phong phú. Nhưng đa số anh em tự vận hành sẽ không chạm tới ngưỡng đó.
Công cụ tốt nhất là công cụ anh em hiểu rõ khi nó hỏng lúc nửa đêm. Với người mới, cấu hình càng ngắn càng dễ hiểu.
Sửa lỗi thường gặp với Caddy reverse proxy

Khi chứng chỉ không cấp được
Phần lớn lỗi của Caddy rơi vào việc không cấp được chứng chỉ, cổng bị chiếm, hoặc ứng dụng phía sau không gọi được. Nhật ký của Caddy khá rõ ràng, đọc kỹ là thấy nguyên nhân.
Cổng 80 hoặc 443 đã bị chiếm
Lỗi `bind: address already in use` nghĩa là một chương trình khác đang giữ cổng, thường là Apache hay Nginx cài sẵn trên VPS. Anh em kiểm tra bằng lệnh:
sudo ss -tlnp | grep -E ':80 |:443 '
sudo systemctl stop nginx apache2
sudo systemctl disable nginx apache2
Nếu cần giữ máy chủ web cũ, anh em cho nó nghe ở cổng khác rồi để Caddy chuyển tiếp tới. Hai chương trình không thể cùng nghe một cổng trên cùng địa chỉ.
DNS chưa trỏ hoặc trỏ sai
Nhật ký báo lỗi xác minh kiểu "NXDOMAIN" hay "no valid A records" nghĩa là tên miền chưa trỏ về máy chủ. Thay đổi DNS có thể mất vài phút tới vài giờ để lan truyền. Anh em kiểm tra bằng `dig +short app.tenmien.vn` từ một máy khác, chỉ bật Caddy khi kết quả đúng IP máy chủ.
Một trường hợp dễ nhầm là tên miền bật chế độ proxy đám mây màu cam của Cloudflare. Lúc đó IP trả về là IP của Cloudflare, xác minh HTTP vẫn có thể chạy nhưng nên chuyển sang DNS-01 để ổn định.
Chạm hạn mức Let's Encrypt
Khi thử đi thử lại với cấu hình sai, anh em có thể chạm giới hạn số chứng chỉ trên mỗi tên miền. Caddy đã tự giảm rủi ro bằng cách dùng staging khi thử lại, nhưng xoá thư mục dữ liệu liên tục vẫn gây ra vấn đề. Khi đang thử nghiệm, anh em chủ động đặt ACME về môi trường staging ở phần tuỳ chọn toàn cục, xong mới bỏ đi.
Lỗi 502 khi gọi ứng dụng phía sau
502 nghĩa là Caddy không gọi được upstream. Kiểm tra theo thứ tự: ứng dụng có đang chạy không, cổng có đúng không, có ghi nhầm localhost trong container không, ứng dụng có chỉ nghe trên một địa chỉ khác không. Lệnh `curl -I http://localhost:9000` chạy ngay trên máy chủ cho biết ứng dụng có phản hồi hay không.
Với lỗi xác thực chứng chỉ khi upstream là HTTPS, nhật ký sẽ ghi rõ "x509". Lúc đó cần khai báo CA nội bộ hoặc đổi upstream về HTTP trong mạng tin cậy.
Kết hợp Caddy reverse proxy với proxy đi ra ngoài
Reverse proxy chỉ lo chiều đi vào. Nhiều hệ thống còn cần chiều đi ra, ví dụ ứng dụng phía sau gọi API bên ngoài, thu thập dữ liệu hay tự động hoá tài khoản. Hai chiều này độc lập với nhau.
Tách bạch hai vai trò
Caddy nhận yêu cầu từ người dùng và chuyển cho ứng dụng. Khi ứng dụng gọi ra ngoài, nó dùng cấu hình mạng riêng, có thể qua biến môi trường `HTTPS_PROXY` hoặc cấu hình proxy trong mã nguồn. Đổi proxy đi ra không cần động tới Caddyfile và ngược lại.
Tách bạch như vậy giúp khoanh vùng lỗi dễ hơn. Người dùng không vào được trang là việc của Caddy. Ứng dụng không gọi được dịch vụ bên ngoài là việc của proxy đi ra.
Chọn IP cho chiều đi ra
Với công cụ thu thập dữ liệu hay tự động hoá cần IP Việt Nam ổn định, IP của VPS thường bị nhiều trang đánh dấu là datacenter. Khi đó anh em có thể mua proxy tốc độ cao tại ProxyVN, gồm dân cư tĩnh Viettel, VNPT, FPT và datacenter Việt Nam, hỗ trợ HTTP và SOCKS5. Proxy được cấp sẵn tên đăng nhập, mật khẩu, khai báo một lần trong ứng dụng là chạy.
Kết luận
Caddy reverse proxy phù hợp với anh em muốn HTTPS tự động mà cấu hình vẫn ngắn, dễ quản lý bằng Git. Chỉ cần tên miền trỏ đúng, mở cổng 80 và 443, giữ thư mục dữ liệu lâu dài, Caddy lo phần còn lại. Cần tư vấn thêm về proxy, hãy liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam khi triển khai Caddy reverse proxy.