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

Lỗi MIME khiến CSS không tải: Kiểm tra phản hồi trước khi sửa header

Website mất định dạng sau khi deploy, Console báo stylesheet bị từ chối vì MIME type, nhưng URL vẫn kết thúc bằng .css. Đừng vội tắt kiểm tra của trình duyệt: tên đường dẫn không chứng minh phản hồi chứa CSS. Một trang đăng nhập hoặc trang lỗi cũng có thể được trả về tại URL đó.

Lỗi MIME khiến CSS không tải: Kiểm tra phản hồi trước khi sửa header

Website mất định dạng sau khi deploy, Console báo stylesheet bị từ chối vì MIME type, nhưng URL vẫn kết thúc bằng .css. Đừng vội tắt kiểm tra của trình duyệt: tên đường dẫn không chứng minh phản hồi chứa CSS. Một trang đăng nhập hoặc trang lỗi cũng có thể được trả về tại URL đó.

1. Phân biệt URL, header và nội dung thật

URL cho biết nơi yêu cầu tài nguyên. Content-Type khai báo kiểu dữ liệu của phản hồi. Body là dữ liệu máy chủ thực sự gửi. Khi chẩn đoán, cần kiểm tra cả ba thay vì chỉ nhìn tên file trong mã HTML.

Theo tài liệu MDN về X-Content-Type-Options, với yêu cầu stylesheet, nosniff khiến trình duyệt chặn phản hồi nếu MIME type không phải text/css. Vì vậy, thông báo này có thể giúp phát hiện một phản hồi sai đường dẫn hoặc sai cấu hình.

2. Ví dụ: tài nguyên CSS nhưng nhận trang đăng nhập

Giả sử trang tham chiếu /assets/app.css nhưng middleware xác thực chặn đường dẫn này và chuyển hướng đến trang đăng nhập. Đây là tình huống minh họa, không phải kết quả đo trên một website cụ thể.

GET /assets/app.css
302 Found
Location: /login

GET /login
200 OK
Content-Type: text/html; charset=utf-8

Status cuối là 200 nhưng nội dung vẫn không phải stylesheet. Sửa Content-Type của trang đăng nhập thành text/css không giải quyết lỗi: trình duyệt sẽ nhận HTML được gắn nhãn CSS, còn người dùng vẫn không có giao diện đúng.

3. Quy trình kiểm tra trong trình duyệt

  1. Mở DevTools trước khi tải lại trang và chọn Network.
  2. Tìm yêu cầu stylesheet bị lỗi, kiểm tra URL thực tế và các bước chuyển hướng nếu có.
  3. Đọc status cùng Content-Type trong response headers; đừng chỉ xem request headers.
  4. Xem Response hoặc Preview để xác định đó là CSS, HTML hay thông báo lỗi.
  5. Đối chiếu đường dẫn với file của bản build vừa triển khai.

Nếu bật giữ log qua điều hướng, hãy phân biệt request cũ và request của lần thử hiện tại. Trước khi chia sẻ ảnh chụp hoặc log, che cookie, token, URL có chữ ký và dữ liệu cá nhân.

4. Sửa theo nguyên nhân đã xác nhận

  • Nhận trang đăng nhập: kiểm tra middleware và cách phục vụ tài nguyên tĩnh. Chỉ điều chỉnh quyền truy cập cho asset được thiết kế công khai; không bỏ xác thực toàn bộ ứng dụng.
  • Nhận trang HTML của ứng dụng: kiểm tra rewrite hoặc fallback có đang nuốt đường dẫn asset không tồn tại hay không.
  • Nhận trang 404: kiểm tra file build có được deploy và tên file có khớp tham chiếu, kể cả chữ hoa/chữ thường.
  • Body đúng CSS nhưng kiểu dữ liệu sai: kiểm tra MIME mapping ở web server, object storage hoặc metadata của đối tượng.

Chỉ trường hợp cuối mới trực tiếp dẫn đến việc sửa kiểu nội dung. Nếu chưa đọc body, đổi header chỉ là phỏng đoán. Với CDN, hãy xác định phản hồi sai đến từ origin hay bản đã cache trước khi quyết định làm mới cache của tài nguyên liên quan.

5. Hậu kiểm sau khi sửa

Phản hồi thành công chứa CSS nên có khai báo phù hợp như ví dụ dưới. Đây là header minh họa, không phải đoạn cấu hình dùng chung cho mọi máy chủ.

Content-Type: text/css; charset=utf-8
X-Content-Type-Options: nosniff

Kiểm tra lại bằng phiên chưa đăng nhập nếu stylesheet phục vụ trang công khai, rồi bằng phiên đăng nhập cho luồng liên quan. Xác nhận body đúng, Console hết lỗi tương ứng và giao diện thực sự nhận style. Nếu chỉ kiểm tra khi có phiên đăng nhập, lỗi của khách truy cập có thể bị bỏ sót.

Không tắt nosniff chỉ để làm biến mất cảnh báo. Mục tiêu là URL đúng trả dữ liệu đúng với kiểu nội dung đúng, không chỉ đạt status 200.

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.