Cloudflare SSL là gì? HTTPS, Flexible, Full và Full (Strict) khác nhau thế nào?
Bùi Tấn Lực - 107
- 06/09/2026
Khi đưa một website lên Internet, SSL/TLS gần như là lớp bảo vệ cơ bản mà bất kỳ website chuyên nghiệp nào cũng cần có. Người dùng truy cập website qua HTTPS không chỉ nhìn thấy biểu tượng ổ khóa trên trình duyệt mà còn được bảo vệ dữ liệu trong quá trình trao đổi giữa trình duyệt và hệ thống máy chủ. Với những website sử dụng Cloudflare, việc bật SSL lại có thêm một điểm cần hiểu rõ: Cloudflare có thể mã hóa kết nối giữa khách truy cập và Cloudflare, đồng thời có thể tiếp tục mã hóa hoặc không mã hóa kết nối từ Cloudflare đến máy chủ gốc.
Đây chính là lý do nhiều người bật SSL trên Cloudflare nhưng vẫn gặp lỗi HTTPS, lỗi vòng lặp chuyển hướng, cảnh báo chứng chỉ hoặc tình trạng website lúc có HTTPS, lúc lại báo không an toàn. Nguyên nhân thường không nằm ở việc “có SSL hay chưa”, mà nằm ở cách Cloudflare kết nối với máy chủ gốc và chế độ SSL/TLS đang được lựa chọn.
Trong thực tế, bốn chế độ thường được nhắc đến là Flexible, Full, Full (Strict) và một số cấu hình liên quan đến việc Cloudflare xử lý HTTPS. Muốn lựa chọn đúng, trước tiên cần hiểu HTTPS hoạt động như thế nào và Cloudflare đứng ở vị trí nào trong toàn bộ quá trình kết nối.
SSL/TLS trên website thực chất là gì?
SSL là tên gọi quen thuộc của công nghệ bảo mật được sử dụng để mã hóa dữ liệu truyền qua mạng. Về kỹ thuật hiện đại, giao thức đang được sử dụng chủ yếu là TLS (Transport Layer Security), còn cụm từ “SSL” vẫn được sử dụng phổ biến vì đã trở thành cách gọi quen thuộc đối với chứng chỉ bảo mật website.
Khi một website sử dụng HTTPS, trình duyệt không đơn giản chỉ kiểm tra xem website có một file chứng chỉ hay không. Trình duyệt và máy chủ sẽ thực hiện quá trình thiết lập kết nối bảo mật, xác thực danh tính của máy chủ và tạo các khóa mã hóa để bảo vệ dữ liệu trong phiên truy cập.
Điều này đặc biệt quan trọng với các dữ liệu như:
- Tài khoản và mật khẩu đăng nhập.
- Thông tin khách hàng gửi qua biểu mẫu.
- Nội dung tìm kiếm hoặc dữ liệu được gửi từ trình duyệt.
- Thông tin thanh toán khi website có chức năng thương mại điện tử.
- Cookie và các dữ liệu phiên có tính chất nhạy cảm.
Nếu kết nối không được mã hóa, dữ liệu truyền giữa các thiết bị có thể có nguy cơ bị quan sát hoặc can thiệp trên đường truyền. HTTPS giúp giảm đáng kể rủi ro này bằng cách mã hóa kết nối.
Chứng chỉ SSL có nhiệm vụ gì?
Một chứng chỉ TLS không chỉ phục vụ mục đích mã hóa. Nó còn giúp trình duyệt xác định rằng máy chủ đang cung cấp website có chứng chỉ phù hợp với tên miền được truy cập.
Ví dụ, khi người dùng truy cập:
https://webmoi.vn
trình duyệt sẽ kiểm tra chứng chỉ được máy chủ cung cấp có hợp lệ đối với tên miền hay không, chứng chỉ còn thời hạn hay không và có được cấp bởi một tổ chức chứng thực được tin cậy hay không.
Nếu các điều kiện cần thiết được đáp ứng, trình duyệt có thể thiết lập kết nối HTTPS bình thường. Ngược lại, người dùng có thể nhìn thấy cảnh báo liên quan đến chứng chỉ.
Điểm cần lưu ý là HTTPS chỉ thực sự có ý nghĩa khi toàn bộ đoạn kết nối cần bảo vệ đều được mã hóa phù hợp. Với Cloudflare, vấn đề trở nên phức tạp hơn vì Cloudflare nằm giữa người truy cập và máy chủ gốc.
Cloudflare SSL hoạt động theo mô hình nào?
Khi website sử dụng Cloudflare làm proxy, trình duyệt của khách truy cập thường không kết nối trực tiếp đến máy chủ gốc. Luồng kết nối có thể hình dung đơn giản như sau:
Trình duyệt
↓ HTTPS
Cloudflare
↓ HTTP hoặc HTTPS
Máy chủ gốc
Cloudflare đứng giữa hai phía và xử lý nhiều nhiệm vụ như CDN, DNS, bảo mật, chống tấn công và SSL/TLS. Vì vậy, cần phân biệt rõ hai đoạn kết nối:
- Kết nối từ trình duyệt của người dùng đến Cloudflare.
- Kết nối từ Cloudflare đến máy chủ gốc của website.
Đây là điểm quan trọng nhất để hiểu Flexible, Full và Full (Strict).
Ví dụ, khi người dùng mở:
https://webmoi.vn
người dùng có thể đang thiết lập kết nối HTTPS với Cloudflare. Nhưng phía sau Cloudflare, Cloudflare có thể tiếp tục kết nối đến máy chủ bằng HTTP hoặc HTTPS tùy thuộc vào chế độ SSL/TLS.
Do đó, việc trình duyệt hiển thị HTTPS không đồng nghĩa với việc đoạn kết nối Cloudflare → máy chủ gốc cũng đang được mã hóa.
HTTPS khác gì so với HTTP?
HTTP là giao thức được sử dụng để truyền tải dữ liệu giữa trình duyệt và máy chủ web. HTTPS có thể hiểu đơn giản là HTTP được truyền thông qua một kết nối TLS đã được bảo mật.
Với HTTP thông thường:
http://webmoi.vn
kết nối không có lớp mã hóa TLS.
Với HTTPS:
https://webmoi.vn
dữ liệu được truyền thông qua kết nối TLS.
HTTPS mang lại ba lợi ích quan trọng:
- Mã hóa: giúp bảo vệ dữ liệu khỏi việc bị đọc trực tiếp trên đường truyền.
- Xác thực: giúp trình duyệt kiểm tra danh tính máy chủ thông qua chứng chỉ.
- Toàn vẹn dữ liệu: giúp phát hiện việc dữ liệu bị thay đổi trái phép trong quá trình truyền.
Đối với website doanh nghiệp, HTTPS còn ảnh hưởng đến mức độ tin cậy của người dùng. Một trang web hiển thị cảnh báo “Not Secure” có thể khiến khách hàng ngần ngại nhập thông tin, đăng nhập hoặc thực hiện giao dịch.
Vì sao dùng Cloudflare lại cần quan tâm đến chế độ SSL?
Nếu website không sử dụng Cloudflare, mô hình thường khá đơn giản:
Trình duyệt
↓ HTTPS
Máy chủ website
Máy chủ website trực tiếp cung cấp chứng chỉ và xử lý kết nối HTTPS.
Khi đưa website qua Cloudflare, mô hình trở thành:
Trình duyệt
↓
Cloudflare
↓
Máy chủ website
Cloudflare có thể cung cấp chứng chỉ ở phía người dùng, nhưng máy chủ gốc vẫn có thể cần một chứng chỉ riêng tùy theo cấu hình.
Đây là lý do một website có thể rơi vào những tình huống tưởng như mâu thuẫn:
- Trình duyệt hiển thị HTTPS nhưng máy chủ gốc chỉ chạy HTTP.
- Cloudflare báo lỗi khi kết nối đến máy chủ.
- Website xuất hiện lỗi 525 hoặc 526.
- Website bị redirect liên tục giữa HTTP và HTTPS.
- Máy chủ đã cài SSL nhưng Cloudflare vẫn không kết nối được.
Muốn xử lý đúng, không nên chỉ nhìn vào ổ khóa trên trình duyệt. Cần xác định cả hai đoạn kết nối đang sử dụng giao thức nào.
Ba lớp cần phân biệt khi cấu hình HTTPS với Cloudflare
Một cách dễ hiểu để tránh nhầm lẫn là chia hệ thống thành ba thành phần:
- Trình duyệt của khách truy cập.
- Cloudflare.
- Máy chủ gốc.
Trình duyệt cần biết website có thể truy cập an toàn qua HTTPS. Cloudflare cần biết nó nên kết nối đến máy chủ gốc bằng HTTP hay HTTPS. Máy chủ gốc, nếu sử dụng HTTPS, cần có cấu hình TLS phù hợp.
Ví dụ với một cấu hình mã hóa đầy đủ:
Người dùng
│
│ HTTPS
▼
Cloudflare
│
│ HTTPS
▼
Máy chủ gốc
Cả hai đoạn đều sử dụng HTTPS.
Trong một cấu hình khác:
Người dùng
│
│ HTTPS
▼
Cloudflare
│
│ HTTP
▼
Máy chủ gốc
Người dùng vẫn nhìn thấy HTTPS ở phía trình duyệt, nhưng đoạn Cloudflare đến máy chủ gốc không được mã hóa bằng TLS.
Chính sự khác nhau này tạo ra các chế độ SSL/TLS của Cloudflare.
Cloudflare SSL không chỉ là bật hoặc tắt HTTPS
Một hiểu lầm khá phổ biến là nghĩ rằng chỉ cần vào Cloudflare, bật SSL rồi website sẽ tự động có HTTPS hoàn chỉnh. Thực tế, Cloudflare cung cấp nhiều cách để xây dựng kết nối giữa người dùng và máy chủ.
Điểm khác biệt cốt lõi nằm ở câu hỏi:
Cloudflare sẽ kết nối với máy chủ gốc bằng HTTP hay HTTPS, và nếu dùng HTTPS thì có kiểm tra chứng chỉ của máy chủ gốc hay không?
Câu hỏi này dẫn trực tiếp đến ba chế độ quan trọng:
- Flexible: trình duyệt có thể kết nối HTTPS với Cloudflare nhưng Cloudflare kết nối HTTP với máy chủ gốc.
- Full: Cloudflare kết nối HTTPS với máy chủ gốc nhưng việc xác thực chứng chỉ không nghiêm ngặt như Full (Strict).
- Full (Strict): Cloudflare kết nối HTTPS với máy chủ gốc và yêu cầu chứng chỉ ở máy chủ gốc đáp ứng các điều kiện xác thực cần thiết.
Vì vậy, không nên đánh giá ba chế độ này đơn giản theo kiểu “chế độ nào mạnh hơn” mà cần lựa chọn dựa trên cấu hình SSL thực tế của máy chủ gốc.
Điều gì xảy ra nếu cấu hình SSL Cloudflare không phù hợp?
Sai chế độ SSL có thể tạo ra lỗi mà người mới sử dụng Cloudflare rất khó hiểu vì website có thể vẫn hoạt động trong một số trường hợp nhưng lại lỗi ở trường hợp khác.
Một trong những lỗi phổ biến là vòng lặp chuyển hướng. Ví dụ, Cloudflare nhận HTTPS từ trình duyệt nhưng kết nối HTTP đến máy chủ. Trong khi đó, máy chủ được cấu hình bắt buộc chuyển HTTP sang HTTPS.
Luồng có thể trở thành:
Trình duyệt → HTTPS → Cloudflare
Cloudflare → HTTP → Máy chủ
Máy chủ → yêu cầu HTTPS
Cloudflare → trình duyệt
Trình duyệt → HTTPS → Cloudflare
...
Nếu cấu hình không được xử lý đúng, quá trình chuyển hướng có thể lặp lại và trình duyệt báo lỗi quá nhiều lần chuyển hướng.
Ngoài redirect loop, việc cấu hình sai còn có thể dẫn đến lỗi chứng chỉ hoặc lỗi kết nối giữa Cloudflare và máy chủ gốc. Vì vậy, trước khi bật các tùy chọn ép HTTPS, cần xác định chính xác máy chủ đang hỗ trợ HTTPS theo cách nào.
Hiểu đúng bản chất trước khi chọn Flexible, Full hay Full (Strict)
Có thể ghi nhớ bằng một nguyên tắc rất đơn giản:
Flexible
Người dùng → HTTPS → Cloudflare → HTTP → Server
Full
Người dùng → HTTPS → Cloudflare → HTTPS → Server
nhưng
không xác thực nghiêm ngặt
Full (Strict)
Người dùng → HTTPS → Cloudflare → HTTPS → Server
và
xác thực chứng chỉ
Như vậy, sự khác biệt giữa các chế độ không nằm ở việc người dùng có nhìn thấy HTTPS hay không mà chủ yếu nằm ở đoạn Cloudflare kết nối tới máy chủ gốc và mức độ Cloudflare kiểm tra chứng chỉ của máy chủ.
Đây cũng là nền tảng để lựa chọn cấu hình phù hợp cho từng website. Một website mới dựng, máy chủ chưa cài chứng chỉ, website có chứng chỉ tự ký và website sử dụng chứng chỉ hợp lệ đều có thể cần cách cấu hình khác nhau.
Flexible hoạt động như thế nào?
Flexible là chế độ có cấu hình đơn giản nhất vì Cloudflare chỉ mã hóa kết nối ở phía người truy cập, còn kết nối từ Cloudflare đến máy chủ gốc sử dụng HTTP.
Trình duyệt
│
│ HTTPS
▼
Cloudflare
│
│ HTTP
▼
Máy chủ gốc
Điều này có nghĩa là người dùng vẫn có thể truy cập website bằng HTTPS và trình duyệt vẫn có thể hiển thị kết nối bảo mật. Tuy nhiên, dữ liệu trên đoạn đường từ Cloudflare đến máy chủ gốc không được truyền qua TLS.
Flexible thường chỉ phù hợp trong một số trường hợp đặc biệt, chẳng hạn máy chủ gốc chưa có SSL/TLS và người quản trị cần nhanh chóng đưa website hoạt động qua HTTPS ở phía người dùng. Tuy nhiên, đây không phải lựa chọn nên ưu tiên cho một website cần bảo mật toàn diện.
Ưu điểm của Flexible
- Không bắt buộc máy chủ gốc phải có chứng chỉ SSL/TLS.
- Dễ triển khai với máy chủ cũ hoặc hệ thống chưa được cấu hình HTTPS.
- Người dùng vẫn có thể truy cập website thông qua HTTPS ở phía Cloudflare.
- Phù hợp như một giải pháp tạm thời trong quá trình chuyển đổi hệ thống.
Hạn chế quan trọng của Flexible
Điểm yếu lớn nhất là kết nối Cloudflare đến máy chủ gốc không được mã hóa. Nếu website xử lý dữ liệu quan trọng, việc để một đoạn kết nối chạy bằng HTTP không phải phương án lý tưởng.
Flexible cũng dễ gây nhầm lẫn khi máy chủ gốc được cấu hình ép HTTPS. Cloudflare có thể gửi yêu cầu HTTP đến máy chủ, trong khi máy chủ lại trả về yêu cầu chuyển sang HTTPS. Nếu không hiểu cơ chế proxy của Cloudflare, người quản trị rất dễ gặp lỗi chuyển hướng.
Vì vậy, không nên xem Flexible là cách “bật SSL cho website” hoàn chỉnh. Nó chỉ bảo vệ một phần đường truyền.
Full bảo vệ kết nối đến máy chủ ra sao?
Khác với Flexible, Full yêu cầu Cloudflare kết nối đến máy chủ gốc bằng HTTPS.
Trình duyệt
│
│ HTTPS
▼
Cloudflare
│
│ HTTPS
▼
Máy chủ gốc
Như vậy, cả hai đoạn kết nối đều được mã hóa bằng TLS. Đây là bước tiến quan trọng so với Flexible vì dữ liệu không còn phải đi bằng HTTP trên đoạn Cloudflare đến máy chủ.
Tuy nhiên, Full có một điểm cần đặc biệt chú ý: Cloudflare không yêu cầu chứng chỉ trên máy chủ gốc phải được xác thực nghiêm ngặt theo cách của Full (Strict).
Điều này cho phép Full hoạt động với một số hệ thống sử dụng chứng chỉ không đáp ứng đầy đủ các yêu cầu xác thực công khai, chẳng hạn chứng chỉ tự ký trong những môi trường nhất định.
Khi nào Full có thể hữu ích?
Full thường phù hợp khi máy chủ gốc đã hỗ trợ HTTPS nhưng chứng chỉ trên máy chủ chưa đáp ứng đầy đủ điều kiện để sử dụng Full (Strict).
Ví dụ, máy chủ có thể đang sử dụng một chứng chỉ được cài đặt riêng để mã hóa kết nối giữa Cloudflare và server. Khi đó, Full giúp duy trì kết nối HTTPS ở cả hai phía mà không yêu cầu mức xác thực chứng chỉ chặt chẽ như Strict.
Tuy nhiên, nếu có thể cài đặt một chứng chỉ hợp lệ và được Cloudflare tin cậy, việc chuyển sang Full (Strict) thường là hướng cấu hình tốt hơn.
Full (Strict) khác Full ở điểm nào?
Full (Strict) cũng sử dụng HTTPS ở cả hai đoạn kết nối:
Trình duyệt
│
│ HTTPS
▼
Cloudflare
│
│ HTTPS
▼
Máy chủ gốc
Điểm khác biệt nằm ở việc xác thực chứng chỉ của máy chủ gốc.
Với Full (Strict), Cloudflare không chỉ yêu cầu máy chủ có thể thiết lập kết nối HTTPS mà còn kiểm tra chứng chỉ của máy chủ gốc theo các yêu cầu xác thực tương ứng. Chứng chỉ cần phù hợp với hostname đang được sử dụng và còn hiệu lực, đồng thời phải được phát hành bởi nguồn chứng thực được chấp nhận hoặc thuộc loại chứng chỉ mà Cloudflare có thể xác thực theo cấu hình của hệ thống.
Vì vậy, Full (Strict) tạo ra một mô hình bảo mật chặt chẽ hơn:
Người dùng
│
│ HTTPS + TLS
▼
Cloudflare
│
│ HTTPS + TLS
│ + kiểm tra chứng chỉ
▼
Máy chủ gốc
Đây thường là lựa chọn nên hướng tới đối với website hoạt động thực tế, đặc biệt khi máy chủ gốc đã được cài SSL/TLS đúng cách.
Vì sao Full (Strict) thường được ưu tiên?
Nếu Cloudflare kết nối đến máy chủ bằng HTTPS nhưng không kiểm tra chứng chỉ một cách nghiêm ngặt, việc mã hóa vẫn có giá trị nhưng mức độ xác thực danh tính máy chủ phía sau chưa đạt mức chặt chẽ nhất.
Full (Strict) bổ sung lớp xác thực đó. Cloudflare có thể xác định rằng nó đang kết nối đến máy chủ cung cấp chứng chỉ phù hợp thay vì đơn giản chấp nhận bất kỳ kết nối TLS nào đáp ứng được việc mã hóa.
Đối với website doanh nghiệp, website bán hàng, website có tài khoản thành viên hoặc hệ thống quản trị, đây là điểm rất đáng quan tâm.
So sánh Flexible, Full và Full (Strict)
| Tiêu chí | Flexible | Full | Full (Strict) |
|---|---|---|---|
| Kết nối người dùng → Cloudflare | HTTPS | HTTPS | HTTPS |
| Kết nối Cloudflare → máy chủ | HTTP | HTTPS | HTTPS |
| Máy chủ cần hỗ trợ HTTPS | Không bắt buộc | Có | Có |
| Xác thực chứng chỉ máy chủ gốc | Không áp dụng theo cách này | Không nghiêm ngặt như Strict | Có xác thực |
| Mức độ bảo vệ đường truyền | Chỉ mã hóa phía người dùng | Mã hóa cả hai đoạn | Mã hóa và xác thực cả hai đoạn |
| Phù hợp lâu dài | Thường không nên ưu tiên | Có thể sử dụng trong một số trường hợp | Thường là lựa chọn ưu tiên |
Bảng trên cho thấy điểm khác biệt quan trọng nhất không phải nằm ở chữ “HTTPS” hiển thị trên trình duyệt mà nằm ở đường kết nối phía sau Cloudflare.
Chọn chế độ nào cho từng loại máy chủ?
Thay vì nhớ máy móc tên các chế độ, có thể lựa chọn dựa trên tình trạng SSL/TLS thực tế của máy chủ.
Máy chủ chưa cài SSL/TLS
Nếu máy chủ gốc hoàn toàn chưa hỗ trợ HTTPS, Flexible có thể giúp website hoạt động với HTTPS ở phía người dùng. Tuy nhiên, đây nên được xem là giải pháp hạn chế hoặc tạm thời thay vì kiến trúc bảo mật lý tưởng.
Nếu website có điều kiện quản trị server, tốt hơn hết là cài SSL/TLS cho máy chủ trước rồi sử dụng Full hoặc Full (Strict).
Máy chủ có HTTPS nhưng chứng chỉ chưa phù hợp
Trong trường hợp máy chủ có HTTPS nhưng chứng chỉ không đáp ứng yêu cầu xác thực của Full (Strict), Full có thể là lựa chọn phù hợp hơn trong thời gian chờ hoàn thiện cấu hình.
Tuy nhiên, cần kiểm tra nguyên nhân khiến chứng chỉ không được chấp nhận thay vì duy trì cấu hình này một cách vô thời hạn.
Máy chủ có chứng chỉ hợp lệ
Đây là trường hợp thuận lợi nhất. Khi máy chủ gốc đã có chứng chỉ hợp lệ, hostname được cấu hình đúng và kết nối HTTPS hoạt động bình thường, Full (Strict) thường là lựa chọn hợp lý.
Cách này giúp mã hóa cả hai đoạn kết nối và đồng thời yêu cầu Cloudflare xác thực máy chủ gốc.
Cloudflare Origin Certificate có vai trò gì?
Một điểm thường gây nhầm lẫn là chứng chỉ dùng ở phía Cloudflare và chứng chỉ dùng giữa Cloudflare với máy chủ gốc không nhất thiết phải là cùng một chứng chỉ.
Cloudflare có thể cung cấp chứng chỉ cho kết nối từ khách truy cập đến mạng lưới Cloudflare. Đồng thời, người quản trị có thể cài một chứng chỉ Origin Certificate trên máy chủ gốc để tạo kết nối HTTPS từ Cloudflare đến server.
Mô hình có thể hiểu như sau:
Khách truy cập
│
│ HTTPS
▼
Cloudflare
│
│ HTTPS
▼
Origin Server
│
└── Origin Certificate
Origin Certificate được thiết kế cho kết nối giữa Cloudflare và máy chủ gốc, không phải để trình duyệt của người dùng trực tiếp xác thực như một chứng chỉ website công khai thông thường.
Đây là một trong những cách triển khai hữu ích khi website toàn bộ lưu lượng cần đi qua Cloudflare và người quản trị muốn mã hóa đoạn kết nối phía máy chủ.
Full (Strict) có bắt buộc dùng chứng chỉ của Cloudflare không?
Không. Full (Strict) không đồng nghĩa với việc máy chủ gốc bắt buộc phải sử dụng một loại chứng chỉ duy nhất do Cloudflare cung cấp.
Điều quan trọng là chứng chỉ trên máy chủ phải đáp ứng các điều kiện xác thực cần thiết và hostname được cấu hình phù hợp.
Vì vậy, website có thể sử dụng chứng chỉ TLS hợp lệ từ một tổ chức chứng thực công khai hoặc sử dụng chứng chỉ Origin Certificate trong mô hình phù hợp với Cloudflare.
Điều cần tránh là cài đặt chứng chỉ sai hostname, chứng chỉ hết hạn hoặc cấu hình máy chủ không cung cấp đúng chuỗi chứng chỉ cần thiết. Những vấn đề này có thể khiến Full (Strict) không thể kết nối tới origin.
Vì sao bật Full (Strict) có thể làm website lỗi ngay?
Nếu chuyển từ Flexible hoặc Full sang Full (Strict), Cloudflare bắt đầu yêu cầu việc xác thực chứng chỉ ở máy chủ gốc chặt chẽ hơn. Nếu server chưa được chuẩn bị đúng, website có thể xuất hiện lỗi ngay sau khi thay đổi.
Một số nguyên nhân thường gặp gồm:
- Chứng chỉ trên máy chủ đã hết hạn.
- Chứng chỉ không bao phủ đúng hostname mà Cloudflare sử dụng để kết nối.
- Máy chủ chưa cấu hình đầy đủ chuỗi chứng chỉ.
- Web server đang cung cấp sai chứng chỉ cho domain.
- HTTPS trên origin chưa hoạt động đúng dù website vẫn truy cập được trong một số trường hợp.
- Cấu hình SNI hoặc virtual host trên máy chủ chưa chính xác.
Vì vậy, không nên chuyển sang Full (Strict) theo kiểu thử ngẫu nhiên trên website đang hoạt động. Cần kiểm tra HTTPS ở máy chủ gốc trước.
Ba chế độ nhìn dưới góc độ bảo mật
Nếu chỉ xét riêng đường truyền giữa Cloudflare và origin, có thể hình dung mức độ khác nhau như sau:
Flexible
Cloudflare ── HTTP ──> Origin
Không mã hóa đoạn này
Full
Cloudflare ── HTTPS ──> Origin
Có mã hóa nhưng xác thực chứng chỉ không nghiêm ngặt như Strict
Full (Strict)
Cloudflare ── HTTPS + xác thực ──> Origin
Có mã hóa và xác thực chặt chẽ hơn
Điều này giải thích tại sao một website không nên chỉ dựa vào việc trình duyệt đang hiển thị ổ khóa HTTPS để kết luận rằng toàn bộ đường truyền từ người dùng đến máy chủ đều được bảo vệ ở cùng một mức độ.
HTTPS ở trình duyệt là một phần của câu chuyện; cấu hình kết nối Cloudflare đến origin mới là phần thường bị bỏ sót.
Cách chọn chế độ SSL phù hợp cho website
Không có một chế độ SSL phù hợp tuyệt đối cho mọi website. Cách lựa chọn chính xác nhất là kiểm tra tình trạng HTTPS trên máy chủ gốc trước, sau đó mới quyết định Cloudflare nên kết nối với origin theo phương thức nào.
Có thể áp dụng nguyên tắc thực tế sau:
- Nếu origin chưa có HTTPS: Flexible có thể hoạt động, nhưng nên xem đây là giải pháp tạm thời.
- Nếu origin đã có HTTPS nhưng chứng chỉ chưa đáp ứng yêu cầu xác thực nghiêm ngặt: Full có thể phù hợp.
- Nếu origin có HTTPS và chứng chỉ hợp lệ, cấu hình đúng: ưu tiên Full (Strict).
Đối với một website được triển khai bài bản, mục tiêu cuối cùng nên là:
Người dùng
│
│ HTTPS
▼
Cloudflare
│
│ HTTPS
▼
Origin Server
Trong đó cả hai đoạn kết nối đều được mã hóa và kết nối đến origin được xác thực phù hợp.
Các bước cấu hình HTTPS với Cloudflare
Trước khi thay đổi chế độ SSL/TLS, cần kiểm tra website và máy chủ gốc. Không nên chỉ thay đổi cấu hình trên Cloudflare rồi chờ xem website có hoạt động hay không.
Bước 1: Kiểm tra website đã có HTTPS hay chưa
Mở website bằng HTTPS:
https://tenmiencuaban.vn
Nếu website hoạt động bình thường, kiểm tra chứng chỉ mà trình duyệt nhận được. Cần chú ý tên miền, thời hạn chứng chỉ và tình trạng kết nối.
Tuy nhiên, việc website hoạt động qua HTTPS ở phía trình duyệt chưa đủ để kết luận origin đã được cấu hình đúng, bởi kết nối hiện tại có thể đang được Cloudflare xử lý.
Bước 2: Kiểm tra HTTPS trực tiếp trên origin
Nếu có quyền quản trị máy chủ, cần kiểm tra web server đang lắng nghe trên cổng HTTPS và đang cung cấp đúng chứng chỉ cho domain.
Với một website thông thường, cần bảo đảm cấu hình máy chủ có thể xử lý yêu cầu HTTPS tương ứng với tên miền.
Nếu origin không hoạt động HTTPS nhưng đang sử dụng Full hoặc Full (Strict), Cloudflare sẽ không thể hoàn tất kết nối đến máy chủ theo yêu cầu của chế độ đó.
Bước 3: Kiểm tra chứng chỉ trên máy chủ
Chứng chỉ phải phù hợp với hostname mà website sử dụng. Ngoài tên miền chính, cần kiểm tra cả các hostname khác nếu website có sử dụng chúng.
Ví dụ, nếu website sử dụng:
www.tenmiencuaban.vn
tenmiencuaban.vn
thì cần bảo đảm cấu hình chứng chỉ và web server xử lý đúng các hostname này.
Bước 4: Chọn chế độ phù hợp
Sau khi xác nhận origin đã hoạt động, mới chọn Flexible, Full hoặc Full (Strict). Nếu máy chủ đã được cấu hình SSL/TLS hợp lệ, Full (Strict) thường là lựa chọn nên ưu tiên.
Cách kiểm tra website có đang thực sự sử dụng HTTPS đúng cách
Kiểm tra HTTPS không nên chỉ dựa vào biểu tượng ổ khóa. Cần kiểm tra cả quá trình chuyển hướng và trạng thái kết nối giữa Cloudflare với origin.
Kiểm tra HTTP có chuyển sang HTTPS không
Thử truy cập:
http://tenmiencuaban.vn
và kiểm tra website có chuyển sang:
https://tenmiencuaban.vn
hay không.
Nếu website được yêu cầu sử dụng HTTPS, việc chuyển hướng cần được cấu hình nhất quán. Tránh để nhiều hệ thống cùng ép chuyển hướng theo những logic khác nhau mà không hiểu rõ thứ tự xử lý.
Kiểm tra phiên bản www và non-www
Nếu website chỉ sử dụng một phiên bản tên miền chính, nên thống nhất phiên bản đó. Ví dụ, nếu chọn tên miền không có www làm phiên bản chính thì mọi yêu cầu đến phiên bản www có thể được chuyển hướng về tên miền chính.
Điều quan trọng là chuyển hướng phải dẫn đến một URL cuối cùng ổn định, thay vì tạo chuỗi chuyển hướng qua nhiều lớp.
Kiểm tra nội dung hỗn hợp
Một website có HTTPS nhưng vẫn tải tài nguyên bằng HTTP có thể gặp lỗi mixed content.
Ví dụ:
<img src="http://tenmiencuaban.vn/images/logo.png">
Trong khi trang chính đang sử dụng HTTPS, hình ảnh trên lại được gọi qua HTTP.
Trường hợp này cần chuyển tài nguyên sang HTTPS:
<img src="https://tenmiencuaban.vn/images/logo.png">
Hoặc sử dụng URL tương đối giao thức:
<img src="//tenmiencuaban.vn/images/logo.png">
Trong các website hiện đại, tốt hơn nên sử dụng URL HTTPS rõ ràng để tránh phụ thuộc vào ngữ cảnh giao thức.
Lỗi redirect loop khi sử dụng Cloudflare SSL
Redirect loop là một trong những lỗi dễ gặp nhất khi cấu hình HTTPS thông qua proxy.
Một tình huống điển hình là Cloudflare nhận yêu cầu HTTPS từ người dùng nhưng kết nối đến origin bằng HTTP. Trong khi đó, origin lại được cấu hình bắt buộc chuyển mọi HTTP sang HTTPS.
Vấn đề nằm ở chỗ origin có thể nhìn thấy yêu cầu mà Cloudflare gửi đến dưới dạng HTTP, dù người dùng ban đầu đang sử dụng HTTPS.
Nếu ứng dụng hoặc web server xử lý logic chuyển hướng mà không nhận biết đúng trạng thái HTTPS ban đầu, quá trình có thể lặp lại.
Client
↓ HTTPS
Cloudflare
↓ HTTP
Origin
↓ Redirect HTTPS
Cloudflare
↓
Client
↓ HTTPS
Cloudflare
↓ HTTP
Origin
↓ Redirect HTTPS
...
Do đó, khi gặp lỗi “too many redirects”, không nên chỉ xóa cache trình duyệt. Cần kiểm tra đồng thời chế độ SSL/TLS của Cloudflare và logic chuyển hướng HTTPS trên origin.
Lỗi 525 và 526 có ý nghĩa gì?
Khi sử dụng Full hoặc Full (Strict), Cloudflare cần thiết lập kết nối HTTPS với origin. Nếu quá trình này thất bại, Cloudflare có thể trả về lỗi thay vì tải website bình thường.
Lỗi 525
Lỗi 525 thường liên quan đến việc Cloudflare không thể thiết lập SSL handshake thành công với máy chủ gốc.
Các nguyên nhân có thể bao gồm:
- Origin không lắng nghe HTTPS đúng cách.
- Cổng HTTPS trên server không hoạt động hoặc bị chặn.
- Web server gặp lỗi khi thực hiện TLS handshake.
- Cấu hình SSL/TLS trên origin không tương thích.
- Chứng chỉ hoặc cấu hình virtual host trên server có vấn đề.
Trong trường hợp này, cần kiểm tra origin thay vì chỉ thay đổi tùy ý chế độ Cloudflare.
Lỗi 526
Lỗi 526 thường liên quan đến việc Cloudflare không thể xác thực chứng chỉ SSL của origin khi sử dụng chế độ yêu cầu xác thực nghiêm ngặt.
Nếu website hoạt động với Full nhưng chuyển sang Full (Strict) lại xuất hiện lỗi 526, đây là dấu hiệu cần kiểm tra chứng chỉ và cấu hình HTTPS trên origin.
Không nên giải quyết bằng cách quay lại Flexible chỉ để website hoạt động tạm thời nếu nguyên nhân thực sự là chứng chỉ origin chưa được cấu hình đúng. Cách tốt hơn là sửa cấu hình máy chủ để có thể sử dụng chế độ bảo mật phù hợp.
Những lỗi cấu hình Cloudflare SSL thường gặp
Chỉ kiểm tra ổ khóa trên trình duyệt
Ổ khóa chỉ cho biết trình duyệt đang có kết nối HTTPS với endpoint mà nó kết nối tới. Khi Cloudflare làm proxy, điều này không cho biết đầy đủ đoạn kết nối phía sau Cloudflare đang sử dụng HTTP hay HTTPS.
Đây là lý do cần hiểu rõ mô hình hai đoạn kết nối thay vì chỉ kiểm tra giao diện trình duyệt.
Dùng Flexible trong thời gian quá dài
Flexible có thể giải quyết bài toán HTTPS ở phía người dùng khi origin chưa có SSL, nhưng nó không mã hóa đoạn Cloudflare đến origin.
Nếu có thể cấu hình HTTPS trên server, nên chuyển sang mô hình mã hóa cả hai đoạn thay vì coi Flexible là cấu hình mặc định lâu dài.
Bật Full (Strict) khi origin chưa sẵn sàng
Full (Strict) yêu cầu origin đáp ứng điều kiện xác thực chứng chỉ. Nếu server chưa được cấu hình đúng, việc bật Strict có thể khiến website không truy cập được thông qua Cloudflare.
Vì vậy, hãy kiểm tra origin trước khi chuyển sang Strict.
Ép HTTPS ở quá nhiều lớp
Cloudflare có thể thực hiện chuyển hướng HTTPS, trong khi web server hoặc mã nguồn website cũng có thể thực hiện chuyển hướng. Nếu các lớp này không được thiết kế thống nhất, rất dễ xuất hiện redirect loop.
Việc ép HTTPS không sai, nhưng cần xác định rõ lớp nào chịu trách nhiệm chính và ứng dụng có nhận biết đúng trạng thái HTTPS phía người dùng hay không.
Quên cập nhật URL trong mã nguồn
Website chuyển sang HTTPS nhưng mã nguồn vẫn chứa nhiều URL HTTP có thể tạo ra mixed content, lỗi tài nguyên hoặc hành vi không nhất quán.
Các thành phần cần kiểm tra có thể bao gồm:
- Ảnh.
- CSS.
- JavaScript.
- Font.
- API.
- Iframe.
- URL được lưu trong cơ sở dữ liệu.
Cloudflare SSL có thay thế SSL trên máy chủ không?
Câu trả lời phụ thuộc vào chế độ đang sử dụng.
Trong Flexible, origin không bắt buộc phải có HTTPS vì Cloudflare có thể kết nối đến origin bằng HTTP.
Trong Full và Full (Strict), origin cần hỗ trợ HTTPS vì Cloudflare phải thiết lập kết nối TLS đến máy chủ.
Do đó, không nên hiểu rằng việc Cloudflare cấp hoặc cung cấp chứng chỉ cho phía khách truy cập đồng nghĩa với việc máy chủ gốc không cần SSL.
Nếu mục tiêu là bảo vệ toàn bộ đường truyền:
Client
│
│ HTTPS
▼
Cloudflare
│
│ HTTPS
▼
Origin
thì origin vẫn phải được cấu hình HTTPS phù hợp.
Full hay Full (Strict): nên chọn phương án nào?
Nếu cả hai đều có HTTPS ở đoạn Cloudflare đến origin, câu hỏi tiếp theo là tại sao không dùng Full trong mọi trường hợp.
Lý do nằm ở xác thực chứng chỉ.
Full phù hợp khi cần kết nối HTTPS đến origin nhưng chứng chỉ chưa đáp ứng được yêu cầu xác thực nghiêm ngặt. Đây có thể là bước trung gian trong quá trình hoàn thiện hệ thống.
Full (Strict) phù hợp hơn khi origin đã được cấu hình chứng chỉ đúng cách. Nó không chỉ mã hóa kết nối mà còn yêu cầu Cloudflare xác thực chứng chỉ của origin.
Với một hệ thống production được quản trị tốt, mục tiêu nên là Full (Strict) thay vì duy trì Full chỉ vì cấu hình chứng chỉ chưa hoàn thiện.
Câu hỏi thường gặp về Cloudflare SSL
Cloudflare SSL có miễn phí không?
Cloudflare có cung cấp chứng chỉ SSL/TLS cho nhiều trường hợp sử dụng mà người quản trị không cần tự mua chứng chỉ riêng cho phía Cloudflare. Tuy nhiên, việc một website có cần chứng chỉ riêng trên origin hay không còn phụ thuộc vào kiến trúc và chế độ SSL/TLS đang sử dụng.
Flexible có phải là HTTPS hoàn toàn không?
Không. Flexible mã hóa kết nối giữa người dùng và Cloudflare nhưng đoạn Cloudflare đến origin sử dụng HTTP. Vì vậy, nó không cung cấp mã hóa đầu-cuối giữa trình duyệt và máy chủ gốc.
Full có an toàn hơn Flexible không?
Có xét riêng về mã hóa đường truyền giữa Cloudflare và origin, vì Full sử dụng HTTPS trên đoạn kết nối này. Tuy nhiên, mức độ xác thực chứng chỉ không giống Full (Strict).
Full (Strict) có phải lựa chọn tốt nhất không?
Trong trường hợp origin đã được cấu hình HTTPS đúng và chứng chỉ đáp ứng yêu cầu xác thực, Full (Strict) thường là lựa chọn nên ưu tiên vì vừa mã hóa kết nối đến origin vừa xác thực chứng chỉ của origin.
Đang dùng Flexible có cần đổi ngay không?
Không nên thay đổi một cách máy móc trên website đang hoạt động. Trước tiên cần kiểm tra HTTPS trên origin và khả năng tương thích của web server. Nếu origin đã sẵn sàng, có thể chuyển sang Full hoặc Full (Strict) và kiểm tra toàn bộ website sau khi thay đổi.
Tại sao bật Full (Strict) lại lỗi nhưng Full vẫn chạy?
Khả năng cao nằm ở chứng chỉ hoặc cấu hình TLS của origin. Full cho phép kết nối HTTPS mà không áp dụng mức xác thực chứng chỉ nghiêm ngặt như Strict, trong khi Full (Strict) yêu cầu origin đáp ứng các điều kiện xác thực tương ứng.
Kết luận
Cloudflare SSL không đơn giản là một công tắc bật hoặc tắt HTTPS. Khi Cloudflare hoạt động như proxy, cần phân biệt rõ kết nối giữa người dùng và Cloudflare với kết nối giữa Cloudflare và máy chủ gốc.
Flexible cho phép Cloudflare nhận HTTPS từ người dùng nhưng kết nối đến origin bằng HTTP. Full sử dụng HTTPS ở cả hai đoạn nhưng không xác thực chứng chỉ origin nghiêm ngặt như Strict. Full (Strict) vừa mã hóa kết nối đến origin vừa yêu cầu chứng chỉ origin đáp ứng các điều kiện xác thực cần thiết.
Nếu website chỉ cần một cấu hình tạm thời trong khi origin chưa có HTTPS, Flexible có thể đáp ứng một phần nhu cầu. Nếu origin đã hỗ trợ HTTPS nhưng chứng chỉ chưa hoàn thiện, Full có thể là bước trung gian. Còn với website được cấu hình SSL/TLS đầy đủ, Full (Strict) thường là lựa chọn đáng ưu tiên.
Quan trọng nhất, đừng đánh giá HTTPS chỉ bằng biểu tượng ổ khóa. Hãy kiểm tra toàn bộ đường đi của dữ liệu, từ trình duyệt đến Cloudflare và từ Cloudflare đến máy chủ. Khi hiểu được hai đoạn kết nối này, việc xử lý lỗi SSL, redirect loop, 525, 526 hay lựa chọn chế độ Cloudflare sẽ trở nên rõ ràng hơn rất nhiều.
- 0 Bình luận
Email, Điện thoại của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *
