Nếu tỷ lệ chuyển đổi từ lưu lượng di động đột ngột giảm, và biểu mẫu đăng ký hoặc thanh toán trả về lỗi 403 cho khách hàng thực — thì có thể không phải là hacker mà là WAF của bạn. Tường lửa thấy hàng nghìn yêu cầu từ một địa chỉ IP của nhà mạng di động và coi đó là DDoS hoặc brute force. Thực tế, đằng sau địa chỉ IP này là hàng trăm hoặc hàng nghìn người bình thường — đó là công nghệ CGNAT. Chúng ta sẽ tìm hiểu cách phát hiện và khắc phục mà không tạo ra lỗ hổng cho các cuộc tấn công thực sự.
CGNAT là gì và tại sao nó tạo ra vấn đề
CGNAT (Carrier-Grade NAT) là công nghệ mà các nhà mạng di động sử dụng do thiếu địa chỉ IPv4. Thay vì cấp cho mỗi thuê bao một IP công cộng duy nhất, nhà mạng "giấu" hàng nghìn người dùng sau một hoặc vài địa chỉ chung. Đối với trang web, điều này có nghĩa là: từ một IP, lưu lượng đến từ hàng trăm người khác nhau cùng một lúc — các thiết bị khác nhau, trình duyệt khác nhau, hành vi khác nhau, nhưng cùng một địa chỉ bên ngoài.
Đối với một máy chủ web thông thường, đây không phải là vấn đề — nó chỉ xử lý các yêu cầu. Nhưng đối với các hệ thống bảo vệ, những hệ thống này coi số lượng yêu cầu trong một khoảng thời gian từ một IP là một sự bất thường. Hãy tưởng tượng: trong một phút, từ một địa chỉ, có 200 yêu cầu đến trang đăng nhập. Đối với WAF, đây là mẫu tấn công brute force hoặc scraping cổ điển. Thực tế, có thể đó là 150 khách hàng thực sự của một nhà mạng di động trong khu vực của bạn, những người chỉ đơn giản là mở trang web cùng một lúc sau khi có quảng cáo hoặc bài đăng trên mạng xã hội.
Vấn đề này đặc biệt nghiêm trọng ở các quốc gia có mật độ internet di động cao — các nhà mạng kết hợp một số lượng lớn thuê bao dưới một số lượng IP công cộng tối thiểu. Đó là lý do tại sao việc kiểm tra hành vi của trang web cần phải được thực hiện không phải từ một IP của trung tâm dữ liệu thông thường, mà chính xác từ proxy di động, những proxy thực sự đi qua cơ sở hạ tầng CGNAT của nhà mạng — chỉ như vậy mới có thể tái tạo lại bức tranh mà WAF thấy ở những người dùng thực.
Tại sao WAF coi CGNAT là mối đe dọa
Hầu hết các giải pháp WAF — Cloudflare, AWS WAF, Imperva, các mô-đun tích hợp của Nginx/ModSecurity — sử dụng rate-limiting theo địa chỉ IP như một cơ chế bảo vệ cơ bản chống lại bot và DDoS. Logic rất đơn giản: nếu từ một IP có nhiều hơn N yêu cầu trong T giây — chặn hoặc hiển thị captcha. Quy tắc này hoạt động rất tốt cho các cuộc tấn công cổ điển từ một thiết bị, nhưng hoàn toàn bị phá vỡ trên lưu lượng CGNAT.
Có một số kịch bản điển hình, nơi điều này xảy ra:
- Rate-limiting theo IP. Giới hạn "100 yêu cầu mỗi phút từ một IP" — là bình thường cho lưu lượng từ trung tâm dữ liệu, nhưng là thảm họa cho khu vực di động với một triệu thuê bao dưới một địa chỉ.
- Đánh giá hành vi. Nếu hệ thống tích lũy "danh tiếng" của IP dựa trên lịch sử yêu cầu, thì một người dùng "xấu" qua CGNAT có thể làm hỏng danh tiếng của địa chỉ cho hàng nghìn khách hàng trung thực tiếp theo.
- Heuristic địa lý. WAF đôi khi đánh dấu IP là đáng ngờ nếu thấy sự gia tăng hoạt động đột ngột, không phù hợp với "người dùng bình thường" — và hành vi của địa chỉ CGNAT chính xác là như vậy: tải cao vào giờ cao điểm của khán giả.
- Chặn theo ASN của nhà mạng. Một số quy tắc WAF chặn toàn bộ dải ASN của các nhà mạng di động, nếu trước đó có các cuộc tấn công từ những dải này — tất cả khách hàng của nhà mạng trong quốc gia đó đều bị ảnh hưởng.
Kết luận: càng nghiêm ngặt WAF được cấu hình "ngay từ đầu", thì khả năng cao hơn rằng nó sẽ chặn không phải bot, mà là khán giả di động thực của bạn — đặc biệt nếu doanh nghiệp hướng đến các quốc gia có internet di động phát triển và tỷ lệ lưu lượng CGNAT cao.
Điều này đe dọa doanh nghiệp như thế nào: mất khách hàng và tiền bạc
Vấn đề chặn CGNAT hiếm khi được nhìn thấy trong phân tích tiêu chuẩn. Google Analytics và Yandex.Metrica đơn giản không ghi nhận những người nhận lỗi 403 ở cấp độ WAF — những lượt truy cập như vậy thường thậm chí không đến được bộ đếm. Kết quả là, nhà tiếp thị thấy tỷ lệ chuyển đổi giảm, nhưng không hiểu nguyên nhân, và bắt đầu tối ưu hóa các sáng tạo và trang đích, trong khi vấn đề nằm ở cơ sở hạ tầng.
Hậu quả thực tế cho các phân khúc doanh nghiệp khác nhau:
- E-commerce. Khách hàng từ internet di động không thể hoàn tất đơn hàng — biểu mẫu thanh toán trả về lỗi, giỏ hàng bị mất. Thiệt hại trực tiếp trong doanh thu, đặc biệt rõ ràng sau khi khởi động quảng cáo trên TikTok Ads hoặc Facebook Ads, nơi lưu lượng chính là di động.
- SaaS và đăng ký. Người dùng cố gắng đăng ký hoặc đăng nhập vào tài khoản cá nhân, nhận captcha ở mỗi bước hoặc bị chặn — họ chuyển sang đối thủ cạnh tranh.
- Nội dung và quảng cáo. Lưu lượng quảng cáo từ các thiết bị di động thường "rơi" trên trang đích, ngân sách quảng cáo bị tiêu tốn, nhưng không có chuyển đổi — các thuật toán của các nền tảng quảng cáo diễn giải điều này là chất lượng khán giả thấp và tăng giá mỗi lần nhấp.
- Dịch vụ hỗ trợ. Số lượng yêu cầu "trang web của bạn không mở được", "tôi không thể đăng ký" tăng lên — trong khi bộ phận hỗ trợ không thấy vấn đề, vì họ truy cập từ máy tính để bàn qua Wi-Fi văn phòng mà không có CGNAT.
Điều khó chịu nhất là những chặn này khó chẩn đoán sau khi xảy ra, vì nhật ký WAF chỉ cho thấy một IP "đáng ngờ" với số lượng yêu cầu lớn, và quản trị viên thấy điều này như một xác nhận cho sự chính xác của việc chặn, chứ không phải là một phản ứng sai.
6 kiểm tra từ IP di động để tìm ra vấn đề
Để hiểu liệu WAF của bạn có chặn khách hàng di động trung thực hay không, cần tái tạo các điều kiện thực tế của CGNAT — tức là thử nghiệm trang web từ các IP di động thực của các nhà mạng và khu vực khác nhau. Dưới đây là danh sách kiểm tra thực tiễn gồm 6 kiểm tra.
Kiểm tra 1: Truy cập hàng loạt từ một IP di động
Thiết lập một số phiên song song qua cùng một IP di động (điều này là tự nhiên đối với proxy từ CGNAT của nhà mạng) và thực hiện 50-100 hành động thông thường — mở trang, thêm vào giỏ hàng, chuyển đổi giữa các phần. Nếu sau một ngưỡng nhất định bắt đầu xuất hiện captcha hoặc 403 — đó là tín hiệu đầu tiên về vấn đề.
Kiểm tra 2: Thay đổi User-Agent khi sử dụng một IP
Một địa chỉ CGNAT phục vụ các thiết bị khác nhau — iPhone, Android, các trình duyệt khác nhau. Khởi chạy các yêu cầu với các chuỗi User-Agent khác nhau qua một IP và kiểm tra xem liệu quy tắc WAF "biến đổi thiết bị đáng ngờ từ một địa chỉ" có được kích hoạt hay không.
Kiểm tra 3: Kiểm tra trên các biểu mẫu quan trọng
Đi qua toàn bộ hành trình của khách hàng — đăng ký, xác thực, hoàn tất đơn hàng, thanh toán — chính qua IP di động của nhà mạng. Thường thì WAF được cấu hình mạnh mẽ hơn trên các biểu mẫu nhập dữ liệu (đăng nhập, thanh toán), nơi mà nguy cơ brute force cao hơn, và đây là nơi đầu tiên mà khách hàng thực sự bị mất.
Kiểm tra 4: Kiểm tra từ các nhà mạng và khu vực khác nhau
Hành vi CGNAT khác nhau giữa các nhà mạng và ở các quốc gia khác nhau — có nơi một IP ẩn chứa 50 thuê bao, có nơi 5000. Thử nghiệm trang web từ các IP di động của một số nhà mạng trong các khu vực quan trọng đối với doanh nghiệp, để hiểu xem có đặc điểm khu vực nào trong việc chặn hay không.
Kiểm tra 5: Phân tích phản hồi của máy chủ theo mã và tiêu đề
Ghi lại không chỉ việc bị chặn, mà còn mã HTTP chính xác và tiêu đề phản hồi (ví dụ, cf-mitigated: challenge từ Cloudflare). Điều này sẽ giúp hiểu cơ chế bảo vệ nào đã được kích hoạt — rate-limit, phát hiện bot hoặc quy tắc địa lý.
Kiểm tra 6: Giám sát lâu dài danh tiếng IP
Lặp lại kiểm tra từ cùng một IP di động trong vài ngày. Nếu quyền truy cập xấu đi theo thời gian mà không có lý do rõ ràng từ phía bạn — có nghĩa là hệ thống đánh giá tích lũy đang "làm hỏng" danh tiếng của địa chỉ do hoạt động của các thuê bao khác qua cùng CGNAT, và đây là một vấn đề hệ thống, không phải là một vấn đề đơn lẻ.
Cần hiểu rằng:
Đối với những bài kiểm tra như vậy, cần phải có các IP di động thực, không phải địa chỉ từ trung tâm dữ liệu hoặc địa chỉ cư trú thông thường — chỉ có lưu lượng đi qua cơ sở hạ tầng của nhà mạng mới tái tạo chính xác mẫu CGNAT mà WAF của bạn thấy ở những người dùng thực.
Cách cấu hình WAF để không chặn khách hàng trung thực
Sau khi chẩn đoán, cần điều chỉnh các quy tắc bảo vệ sao cho không mất đi mức độ an toàn, nhưng ngừng chặn người dùng di động thực. Dưới đây là những phương pháp chính.
| Vấn đề | Giải pháp trong WAF |
|---|---|
| Rate-limit nghiêm ngặt theo IP | Tăng giới hạn cho các ASN nhà mạng di động đã biết hoặc chuyển sang giới hạn theo phiên/ cookie thay vì IP thuần túy |
| Đánh giá danh tiếng IP tích lũy | Giảm thời gian "bộ nhớ" danh tiếng cho các dải CGNAT, thêm whitelist cho các ASN nhà mạng đã biết |
| Chặn theo địa lý/ASN hoàn toàn | Thay thế việc chặn hoàn toàn bằng một thử thách nhẹ nhàng (kiểm tra JS) thay vì 403 |
| Captcha nghiêm ngặt trên các biểu mẫu đăng nhập | Bật captcha một cách thích ứng — chỉ khi có dấu hiệu thực sự của brute force (nhiều lần thử không thành công từ một tài khoản), chứ không chỉ dựa vào IP CGNAT |
Một thực tiễn tốt là duy trì danh sách riêng của các dải nhà mạng di động đã biết cho các khu vực quan trọng của bạn và cung cấp cho chúng các quy tắc riêng, nhẹ nhàng hơn so với lưu lượng internet thông thường. Điều này cần thời gian để cấu hình, nhưng giảm đáng kể số lượng chặn sai.
Công cụ để kiểm tra với proxy di động
Để kiểm tra định kỳ bảo mật của trang web, việc sử dụng sự kết hợp giữa trình duyệt chống phát hiện và proxy di động là rất tiện lợi. Các trình duyệt chống phát hiện (Dolphin Anty, AdsPower, Multilogin, GoLogin, Octo Browser) cho phép tạo ra các hồ sơ cách ly với các dấu vân tay thiết bị khác nhau, trong khi proxy di động cung cấp lưu lượng CGNAT thực từ các nhà mạng.
Phương pháp từng bước để kiểm tra:
- Tạo một số hồ sơ trong trình duyệt chống phát hiện với các tham số thiết bị khác nhau (User-Agent khác nhau, độ phân giải màn hình, múi giờ).
- Kết nối từng hồ sơ với proxy di động của khu vực và nhà mạng cần thiết — điều này sẽ cung cấp hành vi CGNAT thực tế.
- Thực hiện các kịch bản người dùng chính: đăng ký, đăng nhập, thêm vào giỏ hàng, thanh toán.
- Ghi lại tất cả các trường hợp captcha, 403 và các chặn khác, so sánh với cài đặt WAF.
- Lặp lại kiểm tra qua các proxy cư trú để so sánh — điều này sẽ giúp hiểu xem vấn đề có phải đặc thù cho lưu lượng di động hay không.
Để kiểm tra song song ở các khu vực khác nhau, proxy cư trú cũng rất hữu ích — chúng giúp đánh giá mức độ WAF có giống nhau cho lưu lượng từ nhà ở và CGNAT di động hay không. Nếu bạn dự định thực hiện các bài kiểm tra tải từ cơ sở hạ tầng máy chủ mà không gắn liền với nhà mạng, để kiểm tra kiểm soát mà không có hiệu ứng CGNAT, bạn có thể kết nối proxy từ trung tâm dữ liệu — chúng sẽ cung cấp một đường cơ bản sạch sẽ mà không có sự biến dạng, đặc trưng của các mạng di động.
Phương pháp toàn diện như vậy — IP di động, cư trú và trung tâm dữ liệu trong một bài kiểm tra — cung cấp bức tranh đầy đủ: bạn sẽ thấy chính xác nơi nào bảo vệ được kích hoạt và cho loại lưu lượng nào, chứ không phải đoán dựa trên các dấu hiệu gián tiếp trong nhật ký.
Câu hỏi thường gặp
Có thể loại bỏ hoàn toàn các dải CGNAT khỏi quy tắc WAF không?
Không nên — điều này sẽ giảm bảo vệ khỏi các cuộc tấn công thực sự, cũng có thể xảy ra qua các mạng di động. Đúng hơn là làm mềm các ngưỡng và chuyển sang thử thách nhẹ thay vì chặn nghiêm ngặt.
Phải làm những kiểm tra này bao lâu một lần?
Tối thiểu một lần mỗi tháng và chắc chắn sau bất kỳ thay đổi nào trong quy tắc WAF hoặc khi khởi động một chiến dịch quảng cáo mới cho khán giả di động.
Điều này có ảnh hưởng đến SEO không?
Có — nếu bot tìm kiếm hoặc người dùng thực từ các thiết bị di động nhận được lỗi 403, điều này làm tăng tỷ lệ thoát và có thể ảnh hưởng tiêu cực đến các chỉ số hành vi trong xếp hạng.
Kết luận
CGNAT không phải là mối đe dọa, mà là một đặc điểm của internet di động mà hầu như bất kỳ doanh nghiệp nào có khán giả di động cũng phải đối mặt. Vấn đề không nằm ở công nghệ mà ở chỗ các cài đặt tiêu chuẩn của WAF ban đầu không tính đến đặc điểm của nó và trừng phạt người dùng trung thực vì hành vi đặc trưng của các mạng di động thông thường. Sáu kiểm tra trong bài viết này sẽ giúp nhanh chóng chẩn đoán xem bạn có mất khách hàng do các chặn sai hay không, và việc điều chỉnh quy tắc WAF sẽ khôi phục tỷ lệ chuyển đổi mà không giảm mức độ bảo vệ.
Nếu bạn dự định thường xuyên kiểm tra hành vi của trang web và các phễu quảng cáo như cách mà khách hàng di động thực sự thấy, chúng tôi khuyên bạn nên sử dụng proxy di động — chúng cung cấp lưu lượng CGNAT thực từ các nhà mạng và cho phép phát hiện các chặn sai trước khi khách hàng của bạn phát hiện ra chúng.