Bạn vừa bật HTTPS cho website trên Cloudflare, hào hứng kiểm tra lại thành quả, nhưng trình duyệt lại báo ERR_TOO_MANY_REDIRECTS. Trang web liên tục chuyển hướng và không thể tải bình thường. Đây là một lỗi có thể gặp khi cấu hình SSL/TLS trên Cloudflare, thường liên quan đến sự không đồng bộ giữa chế độ mã hóa (encryption mode), cấu hình HTTPS tại origin server và các quy tắc chuyển hướng.

Cloudflare cung cấp nhiều chế độ SSL/TLS khác nhau, bao gồm Off, Flexible, Full và Full (strict). Mỗi chế độ quy định cách kết nối được mã hóa giữa khách truy cập, Cloudflare và origin server. Hiểu đúng sự khác biệt giữa các chế độ này không chỉ giúp tăng cường bảo mật cho website mà còn giúp hạn chế các lỗi redirect loop do cấu hình HTTP và HTTPS không đồng bộ.

Bài viết này sẽ giúp bạn hiểu cách hoạt động của từng chế độ SSL/TLS trên Cloudflare, so sánh Flexible, Full và Full (strict), đồng thời chỉ ra những cấu hình cần kiểm tra khi website gặp lỗi ERR_TOO_MANY_REDIRECTS.

1. Vì sao Cloudflare cần đến nhiều chế độ mã hóa SSL/TLS?

Khi một website được đặt sau Cloudflare, kết nối được chia thành hai chặng riêng biệt:

Cloudflare áp dụng SSL/TLS cho hai chặng kết nối này. Thông qua encryption mode, bạn có thể xác định cách Cloudflare xử lý mã hóa giữa khách truy cập, Cloudflare và origin server. Vì vậy, việc lựa chọn đúng encryption mode là một bước quan trọng khi thiết lập SSL/TLS, đặc biệt để đảm bảo kết nối tới origin được cấu hình phù hợp với khả năng hỗ trợ HTTPS của máy chủ.

2. Tổng quan các chế độ mã hóa SSL/TLS trên Cloudflare

Cloudflare cung cấp các chế độ mã hóa gồm Off, Flexible, Full, Full (strict) và Strict (SSL-Only Origin Pull) dành cho khách hàng Enterprise. Trong đó, Flexible, Full và Full (strict) là ba chế độ chính cần phân biệt khi cấu hình SSL/TLS cho website.

2.1 Off: Không mã hóa

Ở chế độ Off, HTTPS bị vô hiệu hóa. Kết nối giữa khách truy cập và Cloudflare cũng như giữa Cloudflare và origin server không được bảo vệ bằng SSL/TLS. Vì vậy, chế độ này không phù hợp khi website cần cung cấp kết nối HTTPS an toàn.

2.2 Flexible: Chỉ mã hóa kết nối tới Cloudflare

Ở chế độ Flexible, kết nối giữa khách truy cập và Cloudflare có thể sử dụng HTTPS, nhưng kết nối từ Cloudflare tới origin server vẫn sử dụng HTTP và không được mã hóa.

Chế độ này có thể được sử dụng khi origin server chưa hỗ trợ TLS. Tuy nhiên, do kết nối Cloudflare tới origin không được mã hóa, Cloudflare khuyến nghị sử dụng Full hoặc Full (strict) cho các ứng dụng xử lý thông tin nhạy cảm hoặc dữ liệu cá nhân.

Flexible chỉ hỗ trợ kết nối HTTPS của visitor trên cổng 443. Nếu cần sử dụng HTTPS trên các cổng khác, cần lựa chọn Full hoặc Full (strict).

2.3 Full: Mã hóa kết nối tới origin nhưng không xác thực chứng chỉ

Ở chế độ Full, Cloudflare có thể thiết lập kết nối HTTPS tới origin server, nhờ đó kết nối giữa Cloudflare và origin được mã hóa. Tuy nhiên, khác với Full (strict), chế độ Full không xác thực tính hợp lệ của chứng chỉ tại origin theo các yêu cầu nghiêm ngặt về CA, thời hạn và hostname.

Vì vậy, Full có thể được sử dụng khi origin đã hỗ trợ HTTPS nhưng chứng chỉ tại origin chưa đáp ứng các yêu cầu của Full (strict).

2.4 Full (strict): Mã hóa và xác thực chứng chỉ origin

Full (strict) là chế độ Cloudflare khuyến nghị sử dụng bất cứ khi nào có thể. Chế độ này mã hóa kết nối giữa khách truy cập và Cloudflare cũng như kết nối giữa Cloudflare và origin server, đồng thời xác thực chứng chỉ tại origin.

Để sử dụng Full (strict), origin phải cho phép kết nối HTTPS trên cổng 443 và chứng chỉ tại origin phải đáp ứng các yêu cầu sau:

Nếu origin không đáp ứng các yêu cầu này, khách truy cập có thể gặp lỗi 526.

Cloudflare khuyến nghị sử dụng Full (strict) bất cứ khi nào có thể, ngoại trừ trường hợp khách hàng Enterprise sử dụng Strict (SSL-Only Origin Pull). Full (strict) giúp duy trì mã hóa trên cả hai chặng kết nối và bổ sung bước xác thực chứng chỉ của origin server.

2.5 Strict (SSL-Only Origin Pull): Dành cho Enterprise

Strict (SSL-Only Origin Pull) là chế độ dành cho khách hàng Enterprise. Khi sử dụng chế độ này, kết nối từ Cloudflare tới origin luôn sử dụng HTTPS, bất kể kết nối từ khách truy cập tới Cloudflare sử dụng HTTP hay HTTPS. Cloudflare đồng thời thực hiện xác thực chứng chỉ tại origin.

3. Bảng so sánh nhanh: Flexible vs Full vs Full (strict)

4. Nguyên nhân gốc rễ của lỗi ERR_TOO_MANY_REDIRECTS

Lỗi ERR_TOO_MANY_REDIRECTS có thể xảy ra khi chế độ mã hóa trên Cloudflare không đồng bộ với cách origin server xử lý HTTP/HTTPS hoặc khi nhiều quy tắc chuyển hướng cùng hoạt động và xung đột với nhau. Để xác định nguyên nhân, cần phân biệt rõ encryption mode với các thiết lập dùng để chuyển hướng HTTP sang HTTPS.

4.1 Trường hợp 1: Vòng lặp khi sử dụng Flexible mode

Ở chế độ Flexible, kết nối giữa khách truy cập và Cloudflare có thể sử dụng HTTPS, nhưng Cloudflare kết nối tới origin server bằng HTTP. Nếu origin được cấu hình để tự động chuyển mọi request HTTP sang HTTPS, vòng lặp chuyển hướng có thể xuất hiện.

Quá trình thường diễn ra như sau:

Cách khắc phục: kiểm tra và điều chỉnh quy tắc redirect HTTP sang HTTPS tại origin. Nếu origin đã hỗ trợ HTTPS và có chứng chỉ phù hợp, nên chuyển sang Full hoặc Full (strict) để mã hóa kết nối giữa Cloudflare và origin.

4.2 Trường hợp 2: Xung đột redirect khi sử dụng Full hoặc Full (strict)

Khi sử dụng Full hoặc Full (strict), Cloudflare có thể thiết lập kết nối HTTPS tới origin server. Tuy nhiên, encryption mode không có chức năng tự động chuyển request HTTP của khách truy cập sang HTTPS. Việc ép khách truy cập sử dụng HTTPS được thực hiện thông qua các thiết lập HTTPS riêng.

Redirect loop có thể xảy ra khi một cấu hình chuyển HTTP sang HTTPS, trong khi origin hoặc một quy tắc khác lại chuyển HTTPS trở về HTTP.

Ví dụ:

Cách khắc phục: rà soát các quy tắc chuyển hướng HTTP/HTTPS tại Cloudflare và origin server. Cần đảm bảo không tồn tại đồng thời các quy tắc chuyển HTTP sang HTTPS và HTTPS trở lại HTTP.

4.3 Trường hợp 3: Always Use HTTPS xung đột với redirect tại origin

Always Use HTTPS được sử dụng để chuyển các request HTTP của khách truy cập sang HTTPS. Nếu tính năng này được bật trong khi origin hoặc một cấu hình khác lại chuyển request HTTPS trở về HTTP, website có thể rơi vào vòng lặp chuyển hướng.

Quá trình có thể diễn ra như sau:

Cách khắc phục: kiểm tra các quy tắc redirect tại origin và Cloudflare, đồng thời loại bỏ những cấu hình chuyển HTTPS trở về HTTP nếu website đã được thiết lập để sử dụng HTTPS.

4.4 Trường hợp 4: HSTS được bật khi cấu hình HTTPS chưa đồng bộ

HTTP Strict Transport Security (HSTS) yêu cầu trình duyệt sử dụng HTTPS khi truy cập website. Vì vậy, HSTS chỉ nên được bật khi HTTPS đã hoạt động ổn định và các cấu hình HTTP/HTTPS của website đã được thiết lập đồng bộ.

Nếu trình duyệt buộc kết nối sử dụng HTTPS nhưng origin hoặc một quy tắc khác lại cố chuyển HTTPS trở về HTTP, website có thể xuất hiện hành vi chuyển hướng không mong muốn và gây khó khăn trong quá trình truy cập.

Cách khắc phục: đảm bảo HTTPS hoạt động ổn định trước khi bật HSTS. Đồng thời, cần kiểm tra và loại bỏ các quy tắc chuyển HTTPS trở về HTTP tại origin hoặc các lớp cấu hình khác.

4.5 Trường hợp 5: Xung đột giữa các redirect rule

Redirect loop không chỉ liên quan đến encryption mode. Lỗi cũng có thể xuất hiện khi nhiều quy tắc chuyển hướng được cấu hình theo những hướng trái ngược nhau.

Ví dụ, một rule chuyển https://a.example.com sang http://b.example.com, trong khi một rule khác lại chuyển b.example.com trở về https://a.example.com. Hai URL lúc này có thể liên tục chuyển hướng qua lại và cuối cùng khiến trình duyệt báo ERR_TOO_MANY_REDIRECTS.

Cách khắc phục: rà soát các Redirect Rules, Page Rules hoặc các quy tắc chuyển hướng khác đang áp dụng cho website. Đảm bảo không có hai hoặc nhiều rule tạo thành chuỗi redirect quay trở lại URL ban đầu.

5. Nên chọn chế độ nào để tránh lỗi ngay từ đầu?

Thay vì xử lý lỗi sau khi nó đã xảy ra, cách tốt hơn là cấu hình SSL/TLS đúng ngay từ đầu theo quy trình sau:

Nếu sau khi chuyển sang Full (strict) mà website hiển thị lỗi 526, nguyên nhân thường là chứng chỉ ở origin chưa đáp ứng đủ điều kiện — có thể đã hết hạn, không được cấp bởi CA đáng tin cậy, hoặc Common Name/SAN không khớp với hostname. Đây là dấu hiệu cho thấy cần kiểm tra lại chứng chỉ trước khi tiếp tục.

6. Một vài lưu ý bổ sung khi thiết lập SSL/TLS

Bên cạnh việc lựa chọn đúng encryption mode, bạn cũng nên xem xét một số yếu tố khác để hoàn thiện cấu hình SSL/TLS cho website trên Cloudflare:

7. Kết luận

Việc lựa chọn đúng Cloudflare SSL/TLS mode đóng vai trò quan trọng trong việc bảo vệ kết nối giữa người dùng, Cloudflare và origin server, đồng thời giúp hạn chế lỗi ERR_TOO_MANY_REDIRECTS do cấu hình SSL/TLS và các quy tắc chuyển hướng không đồng bộ.

Flexible có thể phù hợp khi origin chưa hỗ trợ TLS, nhưng kết nối từ Cloudflare tới origin vẫn không được mã hóa. Full cho phép mã hóa kết nối tới origin nhưng không áp dụng các yêu cầu xác thực chứng chỉ nghiêm ngặt như Full (strict). Trong khi đó, Full (strict) là chế độ Cloudflare khuyến nghị sử dụng bất cứ khi nào có thể, với điều kiện origin hỗ trợ HTTPS và chứng chỉ đáp ứng đầy đủ các yêu cầu xác thực.

Nếu website gặp redirect loop, cần kiểm tra đồng thời encryption mode, cấu hình HTTP/HTTPS tại origin và các thiết lập chuyển hướng đang được áp dụng. Việc đảm bảo các cấu hình này hoạt động đồng bộ sẽ giúp tránh những vòng lặp chuyển hướng không mong muốn. Khi origin đã sẵn sàng, Full (strict) giúp duy trì mã hóa trên cả hai chặng kết nối và xác thực chứng chỉ tại origin, từ đó xây dựng cấu hình SSL/TLS an toàn và ổn định hơn.

Nếu doanh nghiệp cần tư vấn, cấu hình hoặc tối ưu Cloudflare SSL/TLS, xử lý ERR_TOO_MANY_REDIRECTS hoặc triển khai Cloudflare phù hợp với hạ tầng hiện tại, hãy liên hệ LionTech để được đội ngũ kỹ thuật hỗ trợ đánh giá và triển khai cấu hình phù hợp.

Tìm hiểu thêm: Giải pháp Cloudflare tại LionTech