Người dùng báo website chuyển đến một trang lạ, nhưng quản trị viên tự mở thì mọi thứ vẫn bình thường. Hoặc trang chủ vẫn còn đó, song đột nhiên xuất hiện quảng cáo và nút tải xuống. Những hiện tượng này thường được gọi chung là “website bị chiếm quyền”, dù nguyên nhân có thể nằm ở những vị trí hoàn toàn khác nhau.

CDN chống DDoS có thể góp phần ngăn chặn các sự cố này, nhưng cần cấu hình đồng thời bảo mật DNS, HTTPS, bảo vệ ứng dụng và bảo vệ máy chủ gốc. Lọc lưu lượng DDoS chủ yếu giúp website duy trì khả năng hoạt động; nó không tự khắc phục tài khoản tên miền bị chiếm đoạt, chương trình bị sửa hoặc mã độc trong script của bên thứ ba.

Chỉ khi xác định được sự cố xảy ra ở đoạn nào, bạn mới biết nên triển khai CDN, điều chỉnh quy tắc hay sửa máy chủ gốc.

Trước tiên, “website bị chiếm quyền” biểu hiện như thế nào?

Từ lúc nhập tên miền đến khi trang hiển thị, trình duyệt phải phân giải DNS, kết nối máy chủ, tải trang và chạy script. Trục trặc ở bất kỳ bước nào cũng có thể khiến người dùng nhìn thấy nội dung ngoài dự kiến.

Bảng này giúp thu hẹp phạm vi, không dùng một hiện tượng để kết luận nguyên nhân. Các khu vực phân giải ra IP khác nhau có thể chỉ là cơ chế định tuyến bình thường của CDN. Mã HTTP 302 cũng có thể thuộc quy trình đăng nhập hợp lệ.

Điều cần tìm là địa chỉ, quy tắc hoặc nội dung không được cho phép đã xuất hiện ở bước nào.

Làm sao tránh DNS đưa người dùng đến sai điểm truy cập?

Sau khi triển khai CDN, tên miền phải đưa người dùng đến CDN theo hướng dẫn của nhà cung cấp. CNAME là cách phổ biến, nhưng một số sản phẩm dùng DNS qua proxy hoặc phương thức khác.

Thay CNAME không tự làm DNS an toàn. Tài khoản tại nhà đăng ký tên miền bị chiếm đoạt, khóa truy cập nền tảng DNS bị lộ, hoặc người dùng nhận phản hồi DNS giả đều có thể khiến lưu lượng đi chệch đường dự kiến.

Bảo vệ tài khoản DNS và quyền quản lý tên miền

Tài khoản tại nhà đăng ký tên miền, nền tảng DNS và bảng điều khiển CDN đều là những điểm quản trị quan trọng. Hãy bật xác thực đa yếu tố cho từng nơi, phân quyền theo vai trò, thu hồi tài khoản của nhân viên đã nghỉ và chỉ cấp quyền tối thiểu cho API token dùng trong tự động hóa.

Cũng cần theo dõi thay đổi ở các bản ghi NS, A, AAAA, CNAME và cấu hình liên quan. Bản ghi NS xác định những máy chủ DNS có thẩm quyền quản lý tên miền; chỉ kiểm tra một bản ghi A là chưa đủ.

Khóa chuyển tên miền có thể giảm nguy cơ chuyển nhượng trái phép, nhưng không đồng nghĩa mọi bản ghi DNS đều không thể bị sửa. Cần xác nhận phạm vi bảo vệ của từng cơ chế khóa.

DNSSEC xác thực dữ liệu DNS, không mã hóa trang web

DNSSEC dùng chữ ký số để giúp kiểm tra nguồn gốc và tính toàn vẹn của dữ liệu DNS. Tài liệu giải thích DNSSEC của ICANN mô tả cách chữ ký và chuỗi tin cậy giúp trình phân giải có xác thực phát hiện dữ liệu bị sửa đổi.

Hiệu quả của nó có điều kiện: tên miền phải được ký, các bản ghi liên quan ở vùng DNS cấp trên và chuỗi xác thực phải chính xác, đồng thời quá trình phân giải phía người dùng phải thực sự kiểm tra chữ ký. Cấu hình không khớp có thể làm phân giải thất bại; khi đổi nhà cung cấp DNS, đặc biệt cần phối hợp cập nhật các bản ghi liên quan.

DNSSEC cũng không ngăn người có quyền quản trị hợp lệ sửa bản ghi. Nếu tài khoản đã bị xâm nhập, kẻ tấn công có thể đổi DNS qua quy trình quản lý thông thường. Vì vậy, phải kết hợp DNSSEC với bảo vệ tài khoản.

HTTPS cần bao phủ hai đoạn kết nối nào?

Sau khi triển khai CDN chống DDoS, thông thường sẽ có hai kết nối độc lập:

• Giữa trình duyệt và CDN;
• Giữa CDN và máy chủ gốc.

Trình duyệt hiển thị HTTPS chỉ cho biết nó đã thiết lập kết nối an toàn với điểm truy cập hiện tại, không chứng minh rằng CDN cũng dùng HTTPS khi kết nối đến máy chủ gốc.

Đã mã hóa ở biên thì cũng phải xác minh máy chủ gốc

Nếu đoạn từ trình duyệt đến CDN được mã hóa, nhưng CDN vẫn lấy nội dung từ máy chủ gốc bằng HTTP qua Internet công khai, đoạn sau vẫn truyền dưới dạng văn bản thuần. Với đăng nhập, đơn hàng, API và các dịch vụ nhạy cảm khác, cần dùng HTTPS tới máy chủ gốc và xác thực chứng chỉ của nó đúng cách.

Xác thực chứng chỉ bao gồm thời hạn hiệu lực, chuỗi tin cậy và tên miền khớp. Tài liệu chế độ Full (strict) của Cloudflare phân biệt rõ kết nối được mã hóa với yêu cầu nghiêm ngặt hơn đối với chứng chỉ máy chủ gốc. Tên chế độ và loại chứng chỉ được chấp nhận ở nhà cung cấp khác cần căn cứ vào tài liệu tương ứng.

Địa chỉ kết nối máy chủ gốc, HTTP Host và Server Name Indication (SNI) trong quá trình bắt tay TLS cũng cần khớp cấu hình máy chủ gốc. Kết nối đến một IP không có nghĩa có thể bỏ qua xác minh tên miền. Nếu chứng chỉ báo lỗi, hãy sửa cấu hình thay vì tắt xác minh lâu dài.

HSTS giảm nguy cơ trình duyệt quay về HTTP

HSTS là chính sách bảo mật của trình duyệt. Sau khi nhận được chính sách hợp lệ qua kết nối an toàn, trình duyệt sẽ bắt buộc dùng HTTPS với máy chủ tương ứng trong thời gian chính sách còn hiệu lực.

Khi HTTPS đã hoạt động ổn định, có thể bắt đầu với thời hạn ngắn trên tên miền thử nghiệm hoặc một phần nhỏ lưu lượng, ví dụ header phản hồi HTTP sau:

Strict-Transport-Security: max-age=300

Giá trị 300 tương ứng 300 giây và chỉ phù hợp cho giai đoạn xác minh ban đầu. Sau khi kiểm tra, hãy tăng dần theo kế hoạch triển khai chính thức. Đừng thêm ngay includeSubDomains trừ khi các tên miền phụ liên quan đều đã phục vụ HTTPS ổn định.

Theo tài liệu HSTS của MDN , HSTS thông thường chỉ có hiệu lực sau khi trình duyệt thiết lập một kết nối an toàn đầu tiên và nhận header, nên vẫn có giới hạn ở lần truy cập đầu. Cơ chế preload có thể giảm hạn chế này nhưng cần đáp ứng thêm điều kiện.

HSTS bảo vệ phương thức kết nối. Nó không khôi phục website đã bị xâm nhập và không ngăn được tác hại từ script độc hại đã có quyền chạy trên trang.

WAF và bảo vệ máy chủ gốc giúp giảm nguy cơ website bị sửa đổi ra sao?

Một dạng “chiếm quyền” khác không xảy ra trên đường truyền: chính máy chủ trả về mã độc. Khi đó, HTTPS thậm chí còn chuyển nguyên vẹn mã này đến trình duyệt.

Các đường xâm nhập thường gặp gồm CMS có lỗ hổng, plugin chưa cập nhật, mật khẩu quản trị bị lộ, chức năng tải tệp lên thiếu an toàn và thông tin xác thực dùng để xuất bản bị lạm dụng. Trọng tâm bảo vệ lúc này chuyển sang điểm truy cập ứng dụng và quyền quản trị.

Chặn yêu cầu nguy hiểm ở biên, đồng thời sửa ứng dụng

Tường lửa ứng dụng web (WAF) có thể dùng quy tắc để nhận diện một số yêu cầu khai thác SQL injection, cross-site scripting, path traversal hoặc tải tệp lên bất thường, qua đó giảm cơ hội khai thác lỗ hổng. Tuy nhiên, WAF không bảo đảm phát hiện mọi biến thể và không thay thế việc sửa mã hay cập nhật thư viện phụ thuộc.

Nếu kẻ tấn công có thông tin đăng nhập quản trị hợp lệ và sửa trang chủ bằng thao tác bình thường, chỉ so khớp dấu hiệu tấn công có thể không phát hiện được. Phân quyền quản trị, bảo vệ đăng nhập và phê duyệt trước khi xuất bản vẫn rất quan trọng.

Trong bài về cách WAF, quản lý bot và chống DDoS phối hợp , CDN07 xem việc xử lý tấn công mạng, kiểm tra yêu cầu ứng dụng và nhận diện hành vi tự động hóa trong cùng một chuỗi truy cập. Để giảm nguy cơ chuyển hướng hay sửa nội dung trái phép, có thể xây dựng chính sách cho các đường dẫn rủi ro cao như đăng nhập quản trị, xuất bản nội dung và tải tệp lên, đồng thời giữ lối truy cập cần thiết cho hoạt động hợp lệ.

Chỉ cho phép truy cập dự kiến đến dịch vụ trên máy chủ gốc

Nếu máy chủ gốc luôn có thể truy cập trực tiếp từ Internet, kẻ tấn công có thể đi vòng qua CDN để vào trang quản trị hoặc khai thác lỗ hổng. Hãy giới hạn các cổng dịch vụ theo dải IP đầu ra thực tế của CDN, quy tắc kiểm soát truy cập và phương thức xác thực phù hợp.

Khi CDN dùng chung IP đầu ra, chỉ cho phép một nhóm IP chưa chắc chứng minh yêu cầu thuộc website của bạn. Việc có cần thêm xác thực yêu cầu đến máy chủ gốc hay không phải dựa trên khả năng nhà cung cấp và kiến trúc dịch vụ.

Cũng cần kiểm tra đường đi vòng qua IPv6, tên miền phụ cũ và bảng quản trị. Nếu chỉ giới hạn IPv4 trong khi bản ghi AAAA trỏ thẳng đến máy chủ gốc, phạm vi bảo vệ vẫn chưa đầy đủ. Khi đã gặp vấn đề lộ máy chủ gốc, bạn có thể tham khảo cách bảo vệ IP máy chủ gốc và kiểm tra đường đi vòng để điều tra tiếp.

Những biện pháp này giảm cơ hội đi vòng qua lớp bảo vệ và tiếp cận máy chủ gốc. Nếu ứng dụng đã bị sửa, vẫn phải khôi phục bản đáng tin cậy, vá đường xâm nhập và xử lý thông tin xác thực bị lộ.

CDN có trực tiếp phát hiện chuyển hướng do script bên thứ ba không?

Website có thể chuyển hướng bất thường dù không bị xâm nhập trực tiếp, chẳng hạn do script thống kê, quảng cáo, hỗ trợ khách hàng hoặc dịch vụ bên thứ ba khác.

Script được trình duyệt tải có khả năng thực thi tương ứng trên trang. Được cung cấp qua HTTPS không chứng minh nội dung script luôn an toàn; tài khoản bên thứ ba bị chiếm đoạt, tài nguyên bị thay thế hoặc logic script thay đổi đều có thể ảnh hưởng đến trang.

Dùng CSP để giới hạn nội dung trang được tải và thực thi

Content Security Policy (CSP) có thể giới hạn nguồn tài nguyên, điều kiện chạy script và một số hành vi trên trang. Để giảm nguy cơ ảnh hưởng chức năng hợp lệ khi triển khai, có thể bắt đầu ở chế độ chỉ báo cáo.

Ví dụ, header phản hồi dưới đây có thể dùng làm điểm khởi đầu để thử nghiệm, không phải chính sách cuối cùng phù hợp với mọi website:

Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'

Chính sách này lấy cùng nguồn gốc làm giới hạn mặc định cho tài nguyên, đồng thời đặt thêm ràng buộc với đối tượng nhúng, URL cơ sở và nơi gửi biểu mẫu. Vì dùng Report-Only, nó không thực sự chặn yêu cầu. Trước tiên có thể xem các vi phạm trong bảng điều khiển của trình duyệt; nếu cần thu thập tập trung, hãy cấu hình điểm nhận báo cáo.

Theo hướng dẫn triển khai CSP của MDN , đây là một cách thử nghiệm trước khi áp dụng chế độ chặn. Cần kiểm kê các thành phần bên thứ ba, thiết kế quy tắc nguồn, nonce hoặc hash khi cần, rồi kiểm tra tính năng đăng nhập, thanh toán và hỗ trợ khách hàng.

CSP không phải nút bật chung để “cấm mọi chuyển hướng”. Nếu chính script được cho phép có vấn đề, danh sách nguồn cho phép quá rộng vẫn có thể để lọt.

Xác minh tính toàn vẹn của tài nguyên có phiên bản cố định

Subresource Integrity (SRI) cho phép trang khai báo hash dự kiến của tài nguyên. Sau khi tải script hoặc stylesheet, trình duyệt đối chiếu hash và từ chối tải nếu không khớp.

Theo tài liệu SRI của MDN , khi dùng với tài nguyên khác nguồn gốc, máy chủ cung cấp tài nguyên phải hỗ trợ CORS đúng cách và cần cấu hình thuộc tính crossorigin tương ứng. MDN

SRI phù hợp với tài nguyên có phiên bản cố định, nội dung có thể dự đoán. Khi cập nhật tài nguyên, phải cập nhật hash theo. Nếu kẻ tấn công có thể sửa cả trang chính lẫn giá trị hash, SRI riêng lẻ không bảo đảm an toàn; quy trình xuất bản và bản thân trang vẫn cần được bảo vệ.

Website đã chuyển hướng bất thường: Nên điều tra theo thứ tự nào?

Trước tiên, ghi lại thời điểm xảy ra, URL đầy đủ, thiết bị, nhà mạng, việc truy cập có xuất phát từ kết quả tìm kiếm hay không và tên miền trước, sau khi chuyển hướng. Đừng chỉ lưu câu “website bị chiếm quyền”; chính những khác biệt đó có thể là điều kiện giúp tái hiện sự cố.

Các lệnh sau dùng trên terminal Linux hoặc macOS đã cài dig và curl. Cần thay tên miền và địa chỉ ví dụ. Chúng dùng để kiểm tra website của chính bạn, không tạo lưu lượng tấn công.

1. Đối chiếu DNS, đừng nhầm định tuyến CDN với DNS bị chiếm quyền

dig +short NS example.com
dig +short CNAME www.example.com
dig +short A www.example.com
dig +short AAAA www.example.com

Đối chiếu kết quả với cấu hình dự kiến tại nhà đăng ký tên miền, nền tảng DNS và bảng điều khiển CDN. Các mạng khác nhau trả về IP điểm biên khác nhau là chuyện thường; điều quan trọng là chuỗi phân giải vẫn dẫn đến dịch vụ được cho phép.

Nếu kết quả trên mạng cục bộ bất thường nhưng mạng khác bình thường, hãy kiểm tra bộ định tuyến, proxy và môi trường DNS cục bộ. Tuy nhiên, chỉ có hai kết quả khác nhau chưa chứng minh DNS bị chiếm quyền.

Nếu mọi khu vực đều phân giải đến cùng một đích không được cho phép, nên ưu tiên kiểm tra lịch sử đăng nhập tài khoản và thay đổi cấu hình thay vì liên tục đổi DNS trên máy tính.

2. Xác định phản hồi nào tạo ra chuyển hướng

Lệnh sau gửi yêu cầu GET để xem header phản hồi, bỏ phần nội dung và không tự theo chuyển hướng:

curl --noproxy '*' -sS \
  --connect-timeout 10 --max-time 20 \
  -D - -o /dev/null \
  https://www.example.com/

-D - in header phản hồi ra terminal, còn --noproxy '*' khiến yêu cầu này không dùng proxy của môi trường. Hãy chạy trong môi trường thử nghiệm được phép kết nối Internet trực tiếp.

Chú ý mã trạng thái và Location: nếu là 301, 302, 307 hoặc 308, hãy xác nhận địa chỉ đích có đúng dự kiến không. Kiểm tra từng bước chuyển trước khi truy cập địa chỉ tiếp theo; không nhập tài khoản quản trị hay thông tin xác thực khác trên trang chuyển hướng không rõ nguồn gốc.

Tài liệu chính thức của curl giải thích công dụng của các tham số này. Curl không chạy JavaScript trên trang như trình duyệt, nên “lệnh không chuyển hướng” không có nghĩa trang không chứa mã chuyển hướng độc hại.

Nếu trả về 200 nhưng trình duyệt rời trang sau khi tải xong, hãy mở công cụ dành cho nhà phát triển và lưu nhật ký mạng. Kiểm tra script khởi tạo điều hướng, nội dung trang và chuỗi yêu cầu. Cũng cần xem chuyển hướng làm mới trong HTML, tiện ích trình duyệt và Service Worker có thể ảnh hưởng đến truy cập.

3. So sánh phản hồi máy chủ gốc và CDN khi được phép

Nếu có quyền truy cập máy chủ gốc của mình, bạn có thể dùng môi trường thử nghiệm đã được cho phép để so sánh bằng cách đi vòng qua CDN:

curl --noproxy '*' -sS \
  --connect-timeout 10 --max-time 20 \
  --resolve 'www.example.com:443:192.0.2.10' \
  -D - -o /dev/null \
  https://www.example.com/

192.0.2.10 là địa chỉ ví dụ dùng trong tài liệu, cần thay bằng địa chỉ máy chủ gốc thực tế. Lệnh giữ tên miền trong URL để phục vụ Host, SNI và kiểm tra chứng chỉ.

Ví dụ giả định máy chủ gốc phục vụ HTTPS theo tên miền này. Nếu kết nối thực tế đến máy chủ gốc dùng tên khác hoặc chuỗi tin cậy riêng, hãy điều chỉnh phép thử theo cấu hình thật, thay vì thêm -k để bỏ qua kiểm tra. Cũng đừng mở toàn bộ máy chủ gốc ra Internet chỉ để so sánh.

Nếu máy chủ gốc bình thường nhưng qua CDN lại bất thường, hãy tập trung vào cache, quy tắc chuyển hướng, xử lý tại biên và thay đổi cấu hình. Nếu cả hai đều bất thường, tiếp tục kiểm tra ứng dụng, cấu hình máy chủ web và nội dung cơ sở dữ liệu.

Tuy nhiên, cần so sánh cùng đường dẫn và điều kiện kích hoạt càng giống nhau càng tốt. Một yêu cầu curl thông thường có thể không tái hiện được lỗi chỉ xảy ra trên điện thoại hoặc với Cookie nhất định.

4. Khắc phục nguồn gây lỗi trước, rồi xử lý nội dung còn trong cache

Sau khi xác nhận bị xâm nhập hoặc cấu hình bị sửa trái phép, hãy giữ lại nhật ký và mẫu nội dung bất thường cần thiết. Sau đó khôi phục cấu hình hoặc phiên bản xuất bản đáng tin cậy, thu hồi quy tắc lạ, xử lý tài khoản và token bị lộ, đồng thời vá đường xâm nhập ban đầu.

Khi thay thông tin xác thực, hãy thao tác từ thiết bị đáng tin cậy và kiểm tra email khôi phục cùng các phiên đăng nhập hiện có. Chỉ đổi một mật khẩu mà vẫn giữ API token đã lộ hoặc phiên đăng nhập bất thường có thể khiến sự cố tái diễn.

Sau khi xác nhận máy chủ gốc đã sạch, hãy xóa nội dung CDN bị ảnh hưởng khỏi cache. Nếu xóa cache trước khi sửa máy chủ gốc, các điểm biên có thể lưu lại trang độc hại một lần nữa. Trên thiết bị người dùng cũng có thể còn cache trình duyệt, chuyển hướng được lưu hoặc Service Worker; cần kiểm tra riêng.

Việc xác minh khôi phục phải bao gồm những thiết bị, mạng và nguồn truy cập từng gặp lỗi, chứ không chỉ trang chủ trên máy tính của quản trị viên.

Triển khai các biện pháp này thế nào khi dùng CDN07?

CDN chống DDoS của CDN07 cung cấp tăng tốc website và bảo vệ chống DDoS, với phương án điều chỉnh theo điểm biên, băng thông và chính sách bảo mật. Khi phòng ngừa chuyển hướng và chèn nội dung trái phép, cần cấu hình theo rủi ro thực tế thay vì chỉ nâng năng lực giảm thiểu lưu lượng tấn công.

Chẳng hạn, website nội dung cần quan tâm đến khu vực quản trị xuất bản và script bên thứ ba; website thương mại điện tử phải bảo vệ các đường dẫn đăng nhập, đơn hàng và thanh toán; nền tảng SaaS còn phải tính đến tên miền của từng khách hàng, API và quyền quản trị. Quy tắc bảo vệ phải phục vụ những điểm truy cập cụ thể này.

Khi triển khai, có thể chia công việc thành ba phần:

DNSSEC thường cần sự phối hợp giữa nền tảng DNS và nhà đăng ký tên miền; CSP, SRI liên quan đến cấu hình ứng dụng hoặc header phản hồi. Khi tích hợp, hãy xác nhận nền tảng hiện tại có cung cấp các khả năng đó không và ai chịu trách nhiệm vận hành. Không thể cho rằng mọi việc tự hoàn tất chỉ vì đã mua CDN chống DDoS.

Câu hỏi thường gặp

CDN chống DDoS có ngăn được 100% trường hợp website bị chiếm quyền không?

Không thể cam kết như vậy. CDN có thể góp phần bảo vệ điểm truy cập, đường truyền và yêu cầu ứng dụng, nhưng tài khoản tên miền, ứng dụng trên máy chủ gốc, script bên thứ ba và thiết bị người dùng vẫn có rủi ro riêng.

Website đã dùng HTTPS, sao vẫn chuyển sang trang quảng cáo?

HTTPS bảo vệ đường truyền chứ không bảo đảm nội dung trang an toàn. Nội dung độc hại có thể đến từ máy chủ gốc, cơ sở dữ liệu, script bên thứ ba, quy tắc CDN bị sửa hoặc môi trường trình duyệt cục bộ.

Chỉ điện thoại bị chuyển hướng, có phải nhà mạng can thiệp không?

Không thể kết luận ngay. Xử lý phía máy chủ và script đều có thể trả nội dung khác nhau theo thiết bị, mạng, nguồn truy cập hoặc phiên. Hãy đối chiếu trên nhiều thiết bị, mạng và lưu chuỗi chuyển hướng thực tế.

Sau khi dùng CDN, còn cần bật DNSSEC không?

Chúng giải quyết vấn đề khác nhau. CDN làm proxy và phân phối nội dung, còn DNSSEC giúp xác minh dữ liệu phân giải. Có thể dùng kết hợp nếu hệ thống DNS, tên miền hỗ trợ và bạn có khả năng duy trì cấu hình đúng.

Đổi CDN xong hết lỗi có chứng minh CDN cũ bị xâm nhập không?

Không. Việc chuyển đổi có thể đồng thời thay đổi cache, quy tắc, DNS và đường truy cập. Phải xem phản hồi cụ thể cùng lịch sử thay đổi mới xác định được nguyên nhân.

Đã sửa máy chủ gốc, sao một số người vẫn thấy trang độc hại?

Có thể nội dung còn trong cache CDN, cache trình duyệt, chuyển hướng được lưu hoặc Service Worker; cũng có thể đường xâm nhập ban đầu chưa được xử lý triệt để. Hãy so sánh phản hồi hiện tại của máy chủ gốc, điểm biên và yêu cầu thực tế trên thiết bị bị ảnh hưởng.

Ngăn website bị chuyển hướng hoặc sửa nội dung trái phép đòi hỏi DNS, đường truyền, cấu hình và nội dung đều đáng tin cậy. CDN chống DDoS có thể đóng vai trò quan trọng, nhưng mỗi lớp vẫn cần người chịu trách nhiệm vận hành rõ ràng.

Nếu chuẩn bị triển khai hoặc đang điều tra bất thường, bạn có thể gửi URL bị ảnh hưởng, thời điểm xảy ra, khu vực, nhà mạng và bản ghi phản hồi đã loại thông tin nhạy cảm qua kênh tư vấn kỹ thuật của CDN07 để đối chiếu DNS, quy tắc và kết nối máy chủ gốc. Trước khi gửi, hãy xóa Cookie, header Authorization, access token và các thông tin nhạy cảm khác để việc điều tra dựa trên bằng chứng cụ thể.