Vì sao nhiều người “vấp” ở bước domain và DNS khi dùng CapRover?
CapRover được yêu thích vì giúp triển khai ứng dụng nhanh, giao diện thân thiện và tự động hóa khá nhiều phần việc phức tạp của DevOps. Nhưng trên thực tế, không ít người dùng lại gặp rắc rối ngay ở giai đoạn tưởng như đơn giản nhất: trỏ domain, cấu hình DNS và thiết lập reverse proxy sao cho ổn định, bảo mật, dễ mở rộng.
Chỉ cần sai một bản ghi DNS, chọn nhầm kiểu reverse proxy, hoặc chưa hiểu rõ cách CapRover xử lý HTTP/HTTPS, bạn có thể gặp hàng loạt vấn đề: không cấp được SSL, domain hoạt động chập chờn, app trả 502/404, webhook không nhận được callback, hoặc tệ hơn là hệ thống chạy được nhưng rất khó bảo trì về sau.
Bài viết này sẽ đi theo hướng thực chiến: giải thích cách cấu hình domain, DNS và reverse proxy “chuẩn chỉnh” với CapRover, vì sao cần làm như vậy, và những lỗi phổ biến cần tránh để hệ thống vận hành mượt ngay từ đầu.
Hiểu đúng vai trò của domain, DNS và reverse proxy trong CapRover
Trước khi bắt tay cấu hình, cần hình dung rõ ba lớp chính:
- Domain là tên truy cập của hệ thống, ví dụ example.com.
- DNS là nơi ánh xạ domain về IP máy chủ CapRover.
- Reverse proxy là lớp đứng trước ứng dụng, nhận request từ Internet rồi chuyển tiếp vào container/app phù hợp.
Trong CapRover, reverse proxy mặc định được tích hợp rất chặt với nền tảng. Khi bạn tạo app, gán domain và bật HTTPS, CapRover sẽ tự sinh cấu hình proxy tương ứng. Điều đó giúp thao tác rất nhanh, nhưng cũng khiến nhiều người chủ quan và không để ý đến nền tảng vận hành phía sau.
Muốn làm “chuẩn”, bạn cần quan tâm đến ba mục tiêu:
- Truy cập đúng: domain trỏ chính xác về server. - An toàn: HTTPS hoạt động ổn định, không lỗi chứng chỉ. - Dễ mở rộng: thêm subdomain, app mới hoặc dịch vụ nội bộ mà không phải vá víu thủ công.
Bước 1: Chuẩn bị domain và IP theo tư duy lâu dài
Sai lầm đầu tiên là mua domain xong trỏ bừa về server mà chưa nghĩ đến cấu trúc tổng thể. Với CapRover, bạn nên xác định sớm các nhóm domain:
- Domain gốc cho website chính, ví dụ example.com
- Subdomain quản trị cho dashboard CapRover, ví dụ captain.example.com
- Subdomain cho app như api.example.com, admin.example.com, blog.example.com
- Wildcard domain nếu bạn muốn tạo app linh hoạt sau này, ví dụ *.example.com
Nếu có thể, hãy giữ dashboard quản trị tách biệt với domain public chính. Cách làm này giúp dễ quản lý, giảm rủi ro cấu hình nhầm và thuận tiện hơn khi thiết lập rule bảo mật sau này.
Về IP, máy chủ CapRover nên có:
- 1 IPv4 public tĩnh
- Firewall mở tối thiểu cổng 80, 443, và cổng SSH quản trị nếu cần
- Tên miền trỏ trực tiếp về IP đó, không vòng vo qua nhiều lớp trung gian trong giai đoạn đầu
Nếu bạn dùng Cloudflare hoặc dịch vụ proxy DNS khác, nên bắt đầu ở chế độ DNS thuần trước, sau khi SSL và routing ổn định mới cân nhắc bật proxy/CDN.
Bước 2: Cấu hình DNS đúng ngay từ đầu
Đây là phần quyết định việc CapRover có nhận diện được domain và cấp SSL thành công hay không.
Bản ghi tối thiểu nên có
Thông thường bạn sẽ cần:
- Bản ghi A cho domain gốc: example.com -> IP_SERVER
- Bản ghi A cho dashboard: captain.example.com -> IP_SERVER
- Các bản ghi A hoặc CNAME cho subdomain app
- Có thể thêm wildcard: *.example.com -> IP_SERVER
Ví dụ cấu hình phổ biến:
- example.com → A → 203.0.113.10
- captain.example.com → A → 203.0.113.10
- *.example.com → A → 203.0.113.10
Cấu hình wildcard đặc biệt hữu ích nếu bạn thường xuyên tạo app mới trên CapRover. Khi đó, bạn không cần thêm DNS thủ công cho từng subdomain nữa.
Nên dùng A hay CNAME?
- Dùng A record khi trỏ trực tiếp về IP server - Dùng CNAME khi trỏ một subdomain về một hostname khác
Trong đa số tình huống với CapRover tự host trên VPS, A record là lựa chọn đơn giản và ít lỗi nhất. CNAME chỉ nên dùng khi bạn thực sự có tầng định danh trung gian hoặc hạ tầng đặc biệt.
TTL nên để bao nhiêu?
Khi mới cấu hình, nên để TTL thấp như 300 giây để dễ thay đổi và kiểm tra. Sau khi hệ thống ổn định, có thể tăng lên để tối ưu caching DNS.
Kiểm tra propagation
Sau khi thêm bản ghi, đừng vội kết luận là CapRover lỗi. Hãy kiểm tra trước:
- dig example.com
- dig captain.example.com
- nslookup api.example.com
Nếu domain chưa trả về đúng IP, lỗi nằm ở DNS chứ chưa phải ở CapRover.
Bước 3: Cấu hình domain chính cho CapRover một cách sạch sẽ
Khi cài CapRover, bạn sẽ được yêu cầu chỉ định root domain hoặc captain domain. Đây là mốc rất quan trọng vì nó ảnh hưởng đến cách CapRover sinh subdomain và route request.
Thông lệ tốt là:
- Dùng captain.example.com cho giao diện quản trị
- Dùng *.example.com cho ứng dụng
- Không để dashboard trùng vai trò với website public chính
Cách tách biệt này mang lại lợi ích rõ ràng:
- Giảm nguy cơ cấu hình đè lẫn nhau - Dễ đặt chính sách bảo vệ riêng cho dashboard - Thuận tiện cấp SSL cho từng app - Dễ chuyển đổi hoặc thêm hệ thống CDN/WAF sau này
Sau khi thiết lập xong, hãy truy cập dashboard qua đúng subdomain quản trị, kiểm tra xem CapRover đã nhận domain và hiển thị trạng thái SSL chính xác chưa.
Quảng cáo
300x250 In-Content Advertisement
Bước 4: Hiểu reverse proxy của CapRover để tránh lỗi “khó đoán”
Reverse proxy trong CapRover là lớp tiếp nhận request từ bên ngoài rồi định tuyến vào app/container bên trong. Nói đơn giản, người dùng truy cập api.example.com, reverse proxy sẽ quyết định chuyển request đó tới app api-service đang chạy ở đâu.
Reverse proxy xử lý những gì?
- Phân giải request theo hostname
- Chuyển tiếp về đúng app
- Terminate SSL/TLS
- Chuyển hướng HTTP sang HTTPS nếu bật
- Thêm các header quan trọng như X-Forwarded-For, X-Forwarded-Proto
Đây là lý do nhiều app “chạy local thì được, lên server thì lỗi”. Ứng dụng phía sau reverse proxy phải hiểu rằng:
- Client thật đang đi qua proxy - Giao thức gốc có thể là HTTPS dù app nội bộ chỉ nhận HTTP - IP client có thể nằm trong header thay vì socket trực tiếp
Những lưu ý quan trọng với app phía sau proxy
Nếu app của bạn là Node.js, Laravel, Django, Rails hay NestJS, hãy kiểm tra hỗ trợ trusted proxy hoặc cấu hình tương đương. Nếu không, bạn dễ gặp các lỗi:
- Redirect loop giữa HTTP và HTTPS - Callback URL sinh sai scheme - Session/cookie hoạt động không đúng - Webhook báo signature mismatch do URL không khớp
Nói ngắn gọn: CapRover proxy tốt, nhưng app cũng phải được cấu hình để “tin” reverse proxy.
Bước 5: Bật HTTPS đúng cách, đừng chỉ “bật cho có”
Một hệ thống “chuẩn chỉnh” không dừng ở việc domain truy cập được. HTTPS phải hoạt động ổn định, tự gia hạn và không gây lỗi redirect.
Nguyên tắc thực tế
- Chỉ bật SSL sau khi DNS đã trỏ đúng
- Đảm bảo cổng 80 và 443 public ra Internet
- Không chặn Let’s Encrypt bằng tường lửa hoặc proxy sai cấu hình
- Sau khi cấp SSL thành công, bật ép HTTPS cho app public
Nếu bạn dùng Cloudflare proxy ngay từ đầu, có thể phát sinh lỗi cấp chứng chỉ hoặc xung đột chế độ SSL. Trong giai đoạn thiết lập ban đầu, cách an toàn là:
- Trỏ DNS trực tiếp về server - Cấp SSL thành công trên CapRover - Kiểm tra truy cập HTTPS ổn định - Sau đó mới bật thêm lớp proxy/CDN nếu cần
Khi nào nên cẩn thận với redirect?
Nếu ứng dụng bên trong tự redirect HTTP sang HTTPS, trong khi reverse proxy cũng làm điều đó, bạn có thể gặp vòng lặp chuyển hướng. Giải pháp là thống nhất trách nhiệm:
- Ưu tiên để CapRover xử lý redirect ở tầng proxy - App chỉ cần nhận biết request gốc là HTTPS thông qua forwarded headers
Bước 6: Mô hình domain nên dùng cho nhiều app
Khi hệ thống có từ 3-5 ứng dụng trở lên, cấu trúc domain rõ ràng sẽ giúp vận hành nhàn hơn rất nhiều. Một mô hình dễ quản lý:
- captain.example.com: dashboard CapRover
- app.example.com: frontend chính
- api.example.com: backend API
- admin.example.com: trang quản trị nội bộ
- docs.example.com: tài liệu hoặc landing page
Nếu triển khai staging:
- staging-app.example.com
- staging-api.example.com
Tránh đặt tên tùy hứng hoặc trộn lẫn môi trường production với staging trên cùng pattern khó hiểu. Domain là thứ người vận hành, lập trình viên và cả đối tác tích hợp đều nhìn vào mỗi ngày, nên càng rõ càng tốt.
Những lỗi phổ biến nhất và cách xử lý nhanh
Domain trỏ đúng nhưng app không vào được
Thường do:
- App chưa expose đúng port - Container không chạy - Mapping domain trong CapRover chưa gán vào app đúng cách
Không cấp được SSL
Thường do:
- DNS chưa propagation xong
- Cổng 80 hoặc 443 bị chặn
- Domain đang bật proxy bên thứ ba sai chế độ
- Bản ghi DNS trỏ nhầm IP
Truy cập bị redirect loop
Nguyên nhân phổ biến:
- App tự ép HTTPS nhưng không trust proxy - Proxy và app cùng redirect theo logic khác nhau
Webhook hoặc OAuth callback lỗi
Nguyên nhân thường gặp:
- Ứng dụng tạo callback URL với http thay vì https
- Thiếu cấu hình trusted proxy hoặc forwarded headers
Kết luận: Làm đúng từ đầu sẽ tiết kiệm rất nhiều thời gian về sau
CapRover giúp đơn giản hóa triển khai ứng dụng, nhưng muốn hệ thống thật sự ổn định thì domain, DNS và reverse proxy phải được cấu hình với tư duy hạ tầng bài bản. Công thức thực tế nhất là:
- Tách rõ domain quản trị và domain ứng dụng
- Dùng DNS đơn giản, ưu tiên A record và wildcard khi cần
- Kiểm tra propagation trước khi đổ lỗi cho nền tảng
- Hiểu reverse proxy để cấu hình app tương thích
- Bật HTTPS sau khi mọi thứ đã trỏ đúng và thông suốt
Nếu làm tốt các bước này, bạn sẽ có một nền tảng triển khai rất “nhàn”: thêm app mới nhanh, SSL gọn gàng, route rõ ràng và ít gặp lỗi khó hiểu. Với CapRover, phần khó không phải là bấm nút deploy, mà là thiết kế lớp truy cập bên ngoài đủ sạch để hệ thống vận hành lâu dài. Đó cũng chính là khác biệt giữa một server “chạy tạm được” và một hạ tầng self-hosted thực sự đáng tin cậy.