Hướng dẫn · 19/09/2026

Hướng dẫn cấu hình Cloudflare DNS và HTTPS an toàn cho website

Cloudflare có thể cải thiện HTTPS, hiệu năng và khả năng chống tấn công cho website, nhưng một lần chuyển DNS vội vàng cũng có thể làm gián đoạn web, email hoặc API. Hướng dẫn này đi theo thứ tự an toàn: kiểm kê DNS, chuẩn bị chứng chỉ tại máy chủ gốc, chuyển nameserver, bật proxy, chọn Full (strict), kích hoạt DNSSEC và kiểm thử trước khi siết firewall.

Hướng dẫn cấu hình Cloudflare DNS và HTTPS an toàn cho website

Cloudflare có thể cải thiện HTTPS, hiệu năng và khả năng chống tấn công cho website, nhưng một lần chuyển DNS vội vàng cũng có thể làm gián đoạn web, email hoặc API. Hướng dẫn này đi theo thứ tự an toàn: kiểm kê DNS, chuẩn bị chứng chỉ tại máy chủ gốc, chuyển nameserver, bật proxy, chọn Full (strict), kích hoạt DNSSEC và kiểm thử trước khi siết firewall.

Cloudflare nằm ở đâu trong kiến trúc?

Khi bản ghi web bật proxy, trình duyệt kết nối TLS tới Cloudflare; Cloudflare tạo một kết nối riêng tới máy chủ gốc. Vì có hai chặng, biểu tượng ổ khóa trên trình duyệt không tự chứng minh chặng Cloudflare–origin đã được mã hóa và xác thực đúng. Chế độ SSL/TLS quyết định chặng thứ hai này.

Mục tiêu nên là HTTPS hợp lệ từ đầu đến cuối. Không dùng Flexible như giải pháp lâu dài vì lưu lượng từ Cloudflare tới origin không được mã hóa và cấu hình redirect rất dễ tạo vòng lặp.

1. Chuẩn bị trước khi đổi nameserver

Đăng nhập được cả nhà đăng ký tên miền, hệ thống DNS hiện tại và máy chủ web. Xuất zone DNS hoặc chụp lại toàn bộ bản ghi. Ghi rõ IP origin, nhà cung cấp email, các subdomain, dịch vụ xác minh, API và webhook đang sử dụng.

  • Kiểm tra website hoạt động trực tiếp tại origin và cổng 443 đang mở.
  • Đảm bảo origin có chứng chỉ TLS hợp lệ cho đúng hostname.
  • Ghi lại A, AAAA, CNAME, MX, TXT, CAA và SRV; chú ý SPF, DKIM, DMARC.
  • Giảm TTL trước khi chuyển nếu hệ thống DNS hiện tại cho phép.
  • Chuẩn bị cửa sổ theo dõi và cách quay lại cấu hình cũ.

Không xóa zone cũ ngay sau khi thay nameserver. Giữ nó trong vài ngày để có dữ liệu đối chiếu trong thời gian cập nhật DNS.

2. Thêm domain và rà soát bản ghi

Thêm domain vào Cloudflare, chọn gói phù hợp và chờ hệ thống quét bản ghi. Kết quả quét chỉ là điểm khởi đầu; hãy so sánh từng dòng với zone gốc. Tạo lại những bản ghi bị thiếu trước khi đổi nameserver.

Với bản ghi A, AAAA hoặc CNAME phục vụ website, biểu tượng đám mây màu cam nghĩa là lưu lượng đi qua Cloudflare. DNS only chỉ trả địa chỉ đích và người dùng kết nối trực tiếp. MX và TXT không được proxy; máy chủ mail cũng nên để DNS only.

  • Nên proxy: website và subdomain HTTP/HTTPS muốn dùng CDN, WAF hoặc che IP origin.
  • Nên để DNS only: mail, SSH, FTP, cổng không được hỗ trợ và dịch vụ cần kết nối trực tiếp.
  • Cần cân nhắc: API, webhook và WebSocket; proxy được nếu giao thức, giới hạn tải lên và timeout phù hợp.

3. Đổi nameserver tại nhà đăng ký

Cloudflare cung cấp hai nameserver. Thay nameserver hiện tại tại registrar bằng đúng hai giá trị đó, không thêm IP và không tạo chúng như bản ghi NS trong zone cũ. Chờ trạng thái zone chuyển sang Active rồi kiểm tra từ nhiều mạng.

dig NS example.com
dig A example.com
dig MX example.com
dig TXT example.com

Trên Windows có thể dùng nslookup -type=ns example.com. DNS có thể được cache theo TTL nên kết quả chưa đồng nhất ngay lập tức không nhất thiết là lỗi. Tuy nhiên, nếu web hoặc email mất bản ghi, hãy bổ sung tại Cloudflare thay vì chờ.

4. Cài chứng chỉ TLS tại máy chủ gốc

Ưu tiên chứng chỉ công khai như Let’s Encrypt nếu origin đôi lúc cần truy cập trực tiếp. Cloudflare Origin CA cũng phù hợp khi origin chỉ nhận lưu lượng qua proxy Cloudflare, nhưng trình duyệt không tin cậy chứng chỉ này nếu tắt proxy hoặc truy cập thẳng origin.

Chứng chỉ phải chưa hết hạn, bao phủ đúng hostname và đi kèm private key tương ứng. Cấu hình virtual host để trả đúng chứng chỉ bằng SNI. Với Origin CA, tự theo dõi ngày hết hạn vì Cloudflare hiện không gửi thông báo hết hạn cho loại chứng chỉ này.

openssl s_client -connect 203.0.113.10:443 -servername example.com

Lệnh trên giúp xem chuỗi chứng chỉ tại origin. Không đưa private key, Global API Key hoặc API token vào source code; dùng secret manager và token có quyền tối thiểu.

5. Chọn Full (strict), tránh Flexible

Trong SSL/TLS, chọn Full (strict) khi origin đã có chứng chỉ hợp lệ. Chế độ này mã hóa cả hai chặng và xác minh chứng chỉ origin còn hạn, đúng hostname, được cấp bởi CA công khai hoặc Cloudflare Origin CA. Đây là lựa chọn nên dùng cho production.

  • Flexible: Cloudflare dùng HTTP tới origin; không phù hợp với dữ liệu nhạy cảm và dễ gây redirect loop.
  • Full: mã hóa tới origin nhưng không xác minh tính hợp lệ của chứng chỉ origin.
  • Full (strict): mã hóa và xác minh origin; lỗi xác minh thường trả mã 526.

Sau khi strict hoạt động, bật chuyển hướng HTTP sang HTTPS tại một nơi có chủ đích. Nếu ứng dụng đứng sau reverse proxy, cấu hình trusted proxy để ứng dụng hiểu header giao thức và không tự redirect vô hạn. Sửa mixed content bằng URL HTTPS thay vì tắt kiểm tra trình duyệt.

6. Bật DNSSEC đúng trình tự

DNSSEC giúp resolver phát hiện câu trả lời DNS bị giả mạo. Bật DNSSEC tại Cloudflare, lấy thông tin DS rồi thêm chính xác DS tại registrar. Chờ trạng thái xác nhận hoạt động và kiểm tra bằng công cụ DNSSEC.

Không để bản ghi DS cũ khi đổi nhà cung cấp DNS. DS không khớp có thể khiến domain không phân giải được với các resolver xác thực.

Nếu sau này chuyển nameserver khỏi Cloudflare, hãy thực hiện quy trình chuyển DNSSEC của hai nhà cung cấp hoặc xóa DS đúng thời điểm, thay vì chỉ đổi nameserver.

7. Bảo vệ origin sau khi kiểm thử

Proxy không che được origin nếu IP vẫn xuất hiện trong lịch sử DNS, subdomain DNS only hoặc máy chủ mail dùng chung IP. Tách mail khỏi web nếu có thể, rà soát bản ghi cũ và không công khai IP trong nội dung ứng dụng.

Sau khi xác nhận web ổn định, có thể giới hạn cổng web tại firewall chỉ nhận dải IP Cloudflare. Cập nhật danh sách này tự động từ nguồn chính thức và giữ đường quản trị riêng để tránh tự khóa mình. Authenticated Origin Pulls bổ sung xác thực rằng kết nối tới origin đến từ Cloudflare; Cloudflare Tunnel là lựa chọn khác khi muốn kết nối outbound và không mở cổng web công khai.

Chỉ siết firewall sau khi kiểm tra IPv4, IPv6, health check, cron, webhook và dịch vụ giám sát. Nếu dùng Tunnel thì không cần Authenticated Origin Pulls cho luồng Tunnel.

8. Cấu hình cache và bảo mật có kiểm soát

Cache asset tĩnh như ảnh, CSS và JavaScript trước. Không cache tùy tiện trang đăng nhập, giỏ hàng, dashboard, nội dung cá nhân hóa hoặc API ghi dữ liệu. Để ứng dụng gửi Cache-Control rõ ràng và purge cache sau khi triển khai nội dung cần cập nhật ngay.

Có thể đặt Minimum TLS Version, WAF và rate limiting tùy gói. Chỉ bật HSTS khi toàn bộ website và subdomain cần áp dụng đã chạy HTTPS ổn định; cấu hình includeSubDomains hoặc preload sai có thể khiến subdomain HTTP không thể truy cập trong thời gian dài.

9. Kiểm tra web, email và luồng nghiệp vụ

curl -I http://example.com
curl -I https://example.com
curl --resolve example.com:443:203.0.113.10 https://example.com/ -I

Kiểm tra HTTP chuyển đúng một lần sang HTTPS, hostname chuẩn không tạo chuỗi redirect, chứng chỉ đúng tên miền và nội dung không có mixed content. Sau đó thử đăng nhập, biểu mẫu, upload, thanh toán, API, webhook, WebSocket và các tác vụ nền.

Gửi và nhận email ở cả trong lẫn ngoài tổ chức. Xác nhận MX trỏ đúng, hostname mail không bật proxy và SPF chỉ có một bản ghi hợp lệ; kiểm tra DKIM và DMARC vẫn còn nguyên sau khi chuyển zone.

10. Chẩn đoán lỗi thường gặp

  • 521 Web server is down: origin từ chối kết nối, dịch vụ web dừng hoặc firewall chặn Cloudflare.
  • 522 Connection timed out: Cloudflare không nhận phản hồi kịp thời; kiểm tra route, tải máy chủ và firewall.
  • 525 SSL handshake failed: bắt tay TLS với origin thất bại; kiểm tra giao thức, cipher, SNI và chứng chỉ.
  • 526 Invalid SSL certificate: Full (strict) không xác minh được chứng chỉ origin; kiểm tra hạn, hostname và chuỗi CA.
  • Redirect loop: thường do Flexible kết hợp redirect HTTPS tại origin hoặc ứng dụng không tin proxy header.
  • Email ngừng hoạt động: thường do thiếu MX/TXT, proxy nhầm hostname mail hoặc SPF/DKIM sai.

Checklist trước khi kết thúc

  1. Cloudflare báo zone Active và nameserver đúng.
  2. Tất cả bản ghi web, mail, xác minh và dịch vụ phụ đã được đối chiếu.
  3. Origin có chứng chỉ hợp lệ, SSL/TLS đặt Full (strict).
  4. HTTP chuyển sang HTTPS không có vòng lặp hoặc mixed content.
  5. DNSSEC hoạt động và DS khớp.
  6. Email gửi, nhận, SPF, DKIM và DMARC đều đạt.
  7. Luồng đăng nhập, biểu mẫu, API, webhook và upload đã được thử.
  8. Cache không lưu nội dung riêng tư; firewall chưa chặn nhầm dịch vụ.
  9. Chứng chỉ, lỗi 5xx và ngày hết hạn được giám sát.

Kết luận

Cấu hình Cloudflare an toàn không bắt đầu bằng việc bật thật nhiều tính năng. Trình tự đúng là bảo toàn DNS, chuẩn bị HTTPS tại origin, chuyển nameserver, xác minh dịch vụ, bật Full (strict) và DNSSEC, rồi mới giới hạn truy cập origin. Triển khai theo từng bước có điểm kiểm tra giúp website nhận được lợi ích của CDN và lớp bảo vệ biên mà không đánh đổi tính sẵn sàng.

Nguồn tham khảo

Thảo luận

Bình luận 0

Đăng nhập để bình luận

Bạn cần có tài khoản để tham gia thảo luận và trả lời độc giả khác.

Đăng nhậpĐăng ký

Chưa có bình luận. Hãy là người đầu tiên chia sẻ ý kiến.