Chrome DevTools Network: Kiểm tra request lỗi và chia sẻ log an toàn

Bấm nút lưu nhưng giao diện không phản hồi chưa đủ để kết luận API bị lỗi. Request có thể chưa được gửi, bị trình duyệt chặn, trả lỗi HTTP hoặc trả 200 nhưng ứng dụng không xử lý được dữ liệu. Network trong Chrome DevTools giúp phân biệt các tình huống này bằng bằng chứng.

Hướng dẫn dành cho trang bạn sở hữu hoặc được phép kiểm tra. Ưu tiên tài khoản và dữ liệu thử; không lặp lại thao tác thanh toán hay thay đổi dữ liệu thật chỉ để thu log.

1. Ghi lại đúng một lần tái hiện

Theo hướng dẫn Network của Chrome, mở DevTools rồi chọn Network để quan sát hoạt động mạng. Có thể dùng menu trình duyệt vào công cụ dành cho nhà phát triển nếu phím tắt khác giữa các hệ điều hành.

1. Ghi giờ, đường dẫn trang và thao tác gây lỗi.
2. Mở Network, kiểm tra đang ghi, xóa danh sách hiển thị cũ để giảm nhiễu.
3. Thực hiện thao tác một lần với dữ liệu thử.
4. Lọc Fetch/XHR nếu đang tìm request API; kiểm tra các loại khác nếu không thấy.
5. Chọn request liên quan, xem Headers, Payload, Response và Timing.

Không thấy request không có nghĩa server đã nhận rồi làm mất. Kiểm tra bộ lọc, thời điểm mở DevTools và lỗi JavaScript trước khi suy đoán backend.

2. Ghép triệu chứng với lớp cần điều tra

Bảng là khung đặt giả thuyết, không phải chẩn đoán tự động. Ví dụ request bị CORS chặn ở phía trình duyệt không chứng minh server chưa xử lý thao tác; tránh bấm gửi lại mù quáng với hành động có tác dụng phụ.

3. Kiểm tra cache và chuyển trang có chủ đích

Tài liệu Network reference mô tả Preserve log để giữ các request qua lần điều hướng và Disable cache để tắt browser cache khi DevTools mở. Chỉ bật theo câu hỏi đang kiểm tra, và ghi lại trạng thái khi báo lỗi.

Đề xuất làm hai lần quan sát riêng: lần đầu theo điều kiện người dùng thật, lần sau thử không dùng browser cache nếu cần. Đừng trộn hai lần rồi kết luận hiệu năng. Disable cache cũng không đồng nghĩa đã vô hiệu mọi cache CDN, server hoặc cơ chế service worker.

4. Đọc thời gian mà không đoán quá xa

Timing giúp tách các giai đoạn của request, nhưng thời gian chờ phản hồi đầu tiên không phải đồng hồ riêng cho truy vấn database. Nếu muốn biết server chậm ở đâu, cần nối thông tin với log hoặc trace phía server qua mã request nếu hệ thống có cung cấp.

Ghi những gì quan sát được: endpoint nào, mất bao lâu, kết quả gì, xảy ra mấy lần. Tránh câu “database chậm” chỉ dựa trên một thanh waterfall dài. Cũng phân biệt phản hồi mạng nhanh với giao diện xử lý dữ liệu chậm sau đó.

5. Xuất HAR nhưng vẫn bảo vệ dữ liệu

Chrome hỗ trợ HAR đã loại một số header nhạy cảm như Cookie, Set-Cookie và Authorization theo chế độ sanitized. Điều đó không bảo đảm file không còn bí mật: URL, query string, payload và response có thể chứa thông tin khách hàng hoặc token do ứng dụng đặt ở vị trí khác.

Trước khi chia sẻ, chỉ giữ phạm vi cần thiết, kiểm tra nội dung và che thông tin nhạy cảm bằng quy trình nội bộ. Không đăng HAR lên issue công khai hoặc website phân tích lạ. Tính năng Copy as cURL cũng có thể chứa thông tin xác thực; không dán nguyên lệnh vào cuộc trò chuyện công khai.

6. Mẫu báo lỗi hữu ích

• Thời điểm kèm múi giờ và phiên bản trình duyệt.
• Các bước tái hiện với dữ liệu đã ẩn danh.
• Endpoint, method, status quan sát được và mã request nếu có.
• Kết quả kỳ vọng so với thực tế.
• Trạng thái cache, throttling và Preserve log lúc kiểm tra.
• Ảnh hoặc HAR đã rà soát, chỉ chia sẻ qua kênh được phép.

Một báo lỗi tốt không cần chứa mọi request của cả buổi làm việc. Một lần tái hiện gọn, có bối cảnh và dữ liệu an toàn thường giúp đội phát triển khoanh vùng nhanh hơn nhiều.