Chuyển hướng HTTP sang HTTPS không chỉ là đưa người dùng từ phiên bản không mã hóa sang phiên bản bảo mật. Cấu hình đúng cần bảo đảm mỗi URL đi đến đúng đích, không tạo chuỗi chuyển hướng dài, không lặp vô hạn và thống nhất với canonical, sitemap cùng liên kết nội bộ.
Nếu website đang trong giai đoạn chuyển đổi giao thức, nên chuẩn bị chứng chỉ, bản sao lưu và kế hoạch kiểm thử theo checklist chuyển đổi HTTPS và SSL an toàn trước khi sửa cấu hình máy chủ.
Chuyển hướng HTTP sang HTTPS đúng là như thế nào?
Với một trang còn hoạt động và được phép lập chỉ mục, kết quả lý tưởng thường là:
- Người dùng hoặc bot truy cập URL HTTP.
- Máy chủ trả về mã chuyển hướng vĩnh viễn
301hoặc308. - Header
Locationtrỏ thẳng đến URL HTTPS tương ứng. - URL HTTPS cuối cùng phản hồi
200 OKvà hiển thị đúng nội dung.
Ví dụ về luồng nên hướng tới:
HTTP → HTTPS cuối cùng → 200 OK
Cần hạn chế luồng có nhiều bước như:
HTTP → HTTPS có www → HTTPS không www → URL thêm dấu gạch chéo → 200 OK
Mỗi bước có thể hợp lệ khi đứng riêng, nhưng ghép lại sẽ tạo thành chuỗi chuyển hướng. Cách tốt hơn là cho mọi biến thể cũ chuyển thẳng tới URL chuẩn cuối cùng.
Nên dùng mã 301 hay 308?
Cả 301 và 308 đều thể hiện chuyển hướng vĩnh viễn. 308 giữ nguyên phương thức và nội dung yêu cầu, trong khi hành vi với 301 có thể khác tùy phần mềm khách đối với các phương thức ngoài GET hoặc HEAD.
Với trang nội dung thông thường, 301 được sử dụng phổ biến. Với API, biểu mẫu hoặc luồng có phương thức POST, không nên thay đổi mã phản hồi nếu chưa đánh giá cách ứng dụng xử lý yêu cầu.
Các mã 302 và 307 là chuyển hướng tạm thời. Chúng phù hợp khi việc đổi đích thực sự chỉ diễn ra trong thời gian ngắn, nhưng không nên được dùng thay cho chuyển đổi HTTPS vĩnh viễn chỉ vì cấu hình thuận tiện.
Cách kiểm tra mã phản hồi và đích chuyển hướng
Không nên chỉ nhập URL trên trình duyệt rồi nhìn thanh địa chỉ. Trình duyệt có thể dùng bộ nhớ đệm, tự nâng cấp kết nối hoặc áp dụng HSTS, khiến quá trình chuyển hướng thực tế khó quan sát.
Kiểm tra bằng công cụ dành cho nhà phát triển
Mở công cụ dành cho nhà phát triển của trình duyệt, chọn thẻ Network rồi thực hiện lại yêu cầu với URL HTTP. Khi kiểm tra, nên bật chế độ giữ nhật ký và tắt bộ nhớ đệm nếu trình duyệt hỗ trợ.
Ghi lại các thông tin sau ở từng bước:
- URL được yêu cầu.
- Mã phản hồi như
301,308,200,404hoặc5xx. - Giá trị trong header
Location. - URL cuối cùng sau khi đi qua tất cả chuyển hướng.
- Thời điểm xuất hiện cảnh báo chứng chỉ hoặc lỗi kết nối.
Kiểm tra bằng dòng lệnh
Lệnh curl -I giúp xem header phản hồi của một URL. Thêm tùy chọn --location để đi theo chuyển hướng và --max-redirs 10 để giới hạn số bước, tránh yêu cầu chạy quá lâu khi có vòng lặp.
Cần lưu ý rằng -I gửi yêu cầu HEAD. Một số hệ thống xử lý HEAD khác GET, vì vậy nếu kết quả bất thường, hãy kiểm tra lại bằng yêu cầu GET và chỉ xuất header. Khi đánh giá biểu mẫu, API hoặc URL có xác thực, cần phối hợp với kỹ thuật viên để tránh gửi nhầm dữ liệu hoặc bỏ qua cơ chế phiên đăng nhập.
Những điểm cần xác nhận
Một redirect HTTP sang HTTPS đúng nên đáp ứng các điều kiện sau:
- Header
Locationtrỏ đến URL HTTPS hợp lệ. - Đường dẫn trang được giữ nguyên, trừ khi có chủ đích gộp hoặc thay đổi nội dung.
- Tham số truy vấn cần thiết không bị loại bỏ.
- Không chuyển tất cả URL cũ về trang chủ nếu đã có trang HTTPS tương ứng.
- URL đích không trả về lỗi
404,5xxhoặc tiếp tục chuyển hướng không cần thiết. - Quy tắc hoạt động nhất quán với trang chủ, trang con, tệp và các biến thể tên miền.
Cách phát hiện chuỗi chuyển hướng và vòng lặp
Chuỗi chuyển hướng là gì?
Chuỗi chuyển hướng xảy ra khi một URL phải đi qua từ hai điểm chuyển tiếp trở lên trước khi đến đích cuối. Nguyên nhân thường gặp gồm:
- Quy tắc đổi HTTP sang HTTPS tách biệt với quy tắc chuẩn hóa www.
- Quy tắc thêm hoặc bỏ dấu gạch chéo được xử lý ở bước khác.
- URL cũ chuyển tới URL trung gian, sau đó URL trung gian lại chuyển tới trang mới.
- CDN, proxy, ứng dụng và máy chủ web cùng thực hiện redirect.
- Liên kết nội bộ vẫn trỏ đến URL cũ.
Để xử lý, hãy xác định URL chuẩn cuối cùng trước, sau đó điều chỉnh từng quy tắc để mọi biến thể không chuẩn chuyển trực tiếp đến URL đó. Không nên chỉ xóa một bước giữa chuỗi khi chưa biết bước đó có phục vụ chức năng khác hay không.
Vòng lặp chuyển hướng là gì?
Vòng lặp xuất hiện khi các URL chuyển qua lại và không bao giờ trả về nội dung cuối cùng. Một số mô hình thường gặp:
- HTTP chuyển sang HTTPS nhưng tầng proxy lại báo cho ứng dụng rằng yêu cầu đang dùng HTTP.
- Quy tắc tại CDN ép HTTPS trong khi máy chủ gốc cố chuyển về HTTP.
- Một lớp thêm www, lớp khác lại bỏ www.
- Ứng dụng thêm dấu gạch chéo nhưng máy chủ xóa dấu gạch chéo.
- Hai tiện ích hoặc hai nhóm cấu hình cùng kiểm soát URL chuẩn.
Dấu hiệu nhận biết gồm thông báo có quá nhiều lần chuyển hướng, công cụ kiểm tra dừng vì vượt giới hạn hoặc một URL xuất hiện lặp lại trong danh sách phản hồi.
Không nên giải quyết vòng lặp bằng cách tăng giới hạn số lần redirect. Cần xác định lớp nào chịu trách nhiệm chuẩn hóa giao thức và tên miền, sau đó loại bỏ hoặc điều chỉnh quy tắc xung đột.
Kiểm tra lỗi chuyển hướng SSL
Một số sự cố được gọi chung là lỗi chuyển hướng SSL nhưng thực tế xảy ra trước khi máy chủ có thể trả mã HTTP. Nếu chứng chỉ không hợp lệ, trình duyệt có thể dừng tại bước bắt tay TLS nên người dùng không nhận được trang HTTPS, dù quy tắc redirect HTTP đã hoạt động.
Cần kiểm tra:
- Chứng chỉ có bao phủ đúng tên miền và các biến thể đang sử dụng hay không.
- Chuỗi chứng chỉ có được máy chủ cung cấp đầy đủ hay không.
- Chứng chỉ còn hiệu lực hay đã hết hạn.
- Máy chủ ảo có trả đúng chứng chỉ cho từng tên miền hay không.
- CDN, proxy và máy chủ gốc có dùng chế độ kết nối tương thích hay không.
- Trang HTTPS có tải tài nguyên qua HTTP gây nội dung hỗn hợp hay không.
Redirect không thể sửa một chứng chỉ sai tên miền hoặc hết hạn. Nếu trang chính mở được nhưng ảnh, phông chữ hoặc tệp giao diện không tải sau khi chuyển đổi, có thể áp dụng quy trình kiểm tra ảnh và tài nguyên bị lỗi để phân biệt lỗi URL, quyền truy cập, chứng chỉ và nội dung hỗn hợp.
Thận trọng với HSTS
HSTS yêu cầu trình duyệt chỉ kết nối tới website qua HTTPS trong thời gian được khai báo. Đây không phải là mã chuyển hướng và không thay thế redirect phía máy chủ.
Chỉ nên bật hoặc mở rộng HSTS sau khi đã xác nhận HTTPS hoạt động ổn định trên các tên miền liên quan. Cấu hình sai có thể khiến người dùng không thể truy cập bằng HTTP để nhận một redirect sửa lỗi. Các tùy chọn áp dụng cho tên miền phụ hoặc danh sách nạp sẵn cần được quản trị viên có thẩm quyền đánh giá riêng.
Đồng bộ redirect, canonical và sitemap
Redirect, canonical và sitemap không nên đưa ra ba tín hiệu khác nhau về URL chuẩn.
Redirect
Mọi URL HTTP cần chuyển tới phiên bản HTTPS phù hợp. Nếu nội dung đã đổi địa chỉ, URL cũ nên chuyển thẳng đến địa chỉ chuẩn hiện tại thay vì đi qua phiên bản HTTPS trung gian của URL cũ.
Canonical
Trên trang HTTPS có thể lập chỉ mục, canonical thường nên trỏ đến URL HTTPS chuẩn. Với trang trùng lặp, canonical cần phản ánh đúng URL đại diện đã chọn, không nhất thiết luôn tự tham chiếu.
Cần tránh các trường hợp:
- Trang HTTPS khai báo canonical về HTTP.
- Redirect đưa đến URL A nhưng canonical trên trang đích lại chỉ sang URL B không tương đương.
- Canonical trỏ tới URL lỗi, bị chặn hoặc tiếp tục chuyển hướng.
- Các phiên bản www và không www tham chiếu chéo không nhất quán.
Canonical là tín hiệu hợp nhất URL, không phải cơ chế điều hướng người dùng và không thay thế chuyển hướng máy chủ.
Sitemap XML
Sitemap nên chứa URL HTTPS chuẩn có thể truy cập trực tiếp, thay vì liệt kê URL HTTP hoặc URL phải chuyển hướng. Khi cập nhật sitemap, hãy kiểm tra:
- Mỗi URL trong sitemap trả về nội dung cuối cùng phù hợp.
- URL không phải đi qua chuỗi redirect.
- Canonical trên trang thống nhất với URL được khai báo.
- Sitemap không chứa hàng loạt trang lỗi, trang không được phép lập chỉ mục hoặc URL đã ngừng sử dụng.
- Đường dẫn sitemap được khai báo đúng trong robots.txt nếu website sử dụng cách khai báo này.
Liên kết nội bộ
Liên kết nội bộ nên trỏ thẳng tới URL HTTPS cuối cùng. Phụ thuộc vào redirect cho mọi lượt nhấp sẽ tạo yêu cầu không cần thiết và có thể che giấu URL cũ còn tồn tại trong menu, nội dung, dữ liệu có cấu trúc hoặc mẫu giao diện.
Sau khi đồng bộ, nếu URL quan trọng vẫn không xuất hiện trên công cụ tìm kiếm, hãy thực hiện các bước kiểm tra website không được index để xem xét thêm robots, thẻ robots, canonical, trạng thái HTTP và khả năng thu thập dữ liệu.
Khi nào cần kỹ thuật viên hoặc quản trị hosting?
Không nên tự sửa tệp cấu hình hoặc bảng điều khiển khi chưa biết redirect đang được tạo ở lớp nào. Hãy yêu cầu kỹ thuật viên hoặc quản trị hosting xác nhận trước trong các tình huống sau:
Website dùng nhiều lớp hạ tầng
Nếu hệ thống có CDN, reverse proxy, cân bằng tải, container hoặc nhiều máy chủ, giao thức người dùng nhìn thấy có thể khác giao thức kết nối tới máy chủ gốc. Kỹ thuật viên cần xác nhận cách truyền và tin cậy các header nhận diện giao thức, chẳng hạn thông tin cho biết yêu cầu ban đầu là HTTPS.
Không xác định được nơi tạo redirect
Chuyển hướng có thể nằm trong cấu hình máy chủ web, bảng điều khiển hosting, mã ứng dụng, tiện ích quản trị, CDN hoặc dịch vụ proxy. Sửa đồng thời nhiều nơi dễ tạo chuỗi hoặc vòng lặp.
Website có API, đăng nhập, thanh toán hoặc biểu mẫu
Đổi mã 301, 302, 307 hay 308 có thể ảnh hưởng đến phương thức yêu cầu, dữ liệu gửi đi, callback và phiên đăng nhập. Cần kiểm thử luồng nghiệp vụ thay vì chỉ kiểm tra trang nội dung.
Chứng chỉ được quản lý tập trung
Nếu chứng chỉ do hosting, CDN hoặc hệ thống tự động cấp và gia hạn, việc cài thủ công có thể gây xung đột. Quản trị viên cần xác nhận nơi kết thúc kết nối TLS, phạm vi tên miền và cơ chế gia hạn.
Website dùng nhiều tên miền hoặc tên miền phụ
Không nên bật redirect diện rộng hoặc HSTS cho toàn bộ tên miền phụ khi chưa kiểm kê các dịch vụ đang chạy. Một tên miền phụ chưa hỗ trợ HTTPS có thể bị gián đoạn.
Không có quyền khôi phục cấu hình
Trước khi thay đổi quy tắc máy chủ, cần có bản sao cấu hình, cách quay lại phiên bản trước và quyền truy cập không phụ thuộc hoàn toàn vào giao diện website. Nếu không có các điều kiện này, nên để đơn vị quản trị hạ tầng thực hiện.
Checklist kiểm tra sau khi chuyển sang HTTPS
Sau khi cấu hình, nên kiểm tra theo thứ tự sau:
- Truy cập URL HTTP của trang chủ và một nhóm trang con đại diện.
- Xác nhận mã
301hoặc308dẫn thẳng đến URL HTTPS chuẩn. - Kiểm tra biến thể www, không www, có và không có dấu gạch chéo nếu website hỗ trợ các biến thể này.
- Theo dõi toàn bộ chuỗi để phát hiện URL trung gian hoặc vòng lặp.
- Xác nhận URL cuối trả về trạng thái phù hợp và hiển thị đúng nội dung.
- Kiểm tra chứng chỉ trên các tên miền thực tế đang phục vụ người dùng.
- Tìm tài nguyên HTTP còn sót trong trang HTTPS.
- Cập nhật liên kết nội bộ sang URL HTTPS cuối cùng.
- Kiểm tra canonical trên các mẫu trang quan trọng.
- Làm mới sitemap bằng URL HTTPS chuẩn và gửi lại qua công cụ quản trị tìm kiếm nếu cần.
- Theo dõi lỗi thu thập dữ liệu, trạng thái lập chỉ mục và nhật ký máy chủ sau thay đổi.
- So sánh hiệu suất theo từng nhóm trang, không kết luận chỉ từ biến động ngắn hạn.
Nếu lượng truy cập thay đổi sau quá trình chuyển đổi, nên dùng quy trình tìm đúng nguyên nhân khi traffic giảm để tách ảnh hưởng của redirect khỏi lỗi index, thay đổi nội dung, đo lường hoặc biến động nhu cầu tìm kiếm.
Một cấu hình chuyển hướng HTTP sang HTTPS tốt cần đạt ba mục tiêu: người dùng tới được trang bảo mật, công cụ tìm kiếm nhận tín hiệu URL chuẩn nhất quán và hệ thống không tạo thêm chuỗi hay vòng lặp. Việc kiểm tra mã phản hồi chỉ là bước đầu; canonical, sitemap, liên kết nội bộ, chứng chỉ và các lớp hạ tầng cũng phải được rà soát cùng nhau.
