
Trả lời nhanh: Dấu hiệu điển hình: lưu lượng vào tăng đột biến không theo quy luật, máy chủ web hết luồng xử lý trong khi CPU chưa cao, rất nhiều kết nối từ dải địa chỉ lạ, và website chậm hoặc không phản hồi dù tài nguyên chưa cạn. Xử lý theo thứ tự: xác nhận đúng là tấn công chứ không phải quá tải thường, bật lớp lọc trước máy chủ, chặn theo dải hoặc theo quốc gia nếu cần, giới hạn tốc độ truy cập, rồi báo nhà cung cấp để họ lọc từ phía mạng.
Website đột nhiên không vào được, bạn nghĩ ngay tới bị tấn công. Nhưng rất nhiều trường hợp hoá ra là quá tải bình thường hoặc một con bot thu thập dữ liệu quá tay. Phân biệt được thì mới xử lý đúng.
- Trước hết xác nhận đúng là tấn công, đừng đoán, vì cách xử lý hoàn toàn khác nhau.
- Kiểm tra bằng ss, netstat và log của máy chủ web để nhìn số kết nối và nguồn.
- Lớp lọc đặt trước máy chủ là biện pháp hiệu quả nhất với tấn công tầng ứng dụng.
- Phòng ngừa quan trọng hơn chữa cháy: giấu IP gốc, giới hạn tốc độ, chuẩn bị sẵn kịch bản.
Xác nhận có đúng là tấn công không
Chạy các lệnh sau để nhìn bức tranh thật:
# đếm số kết nối theo địa chỉ nguồn
ss -tn state established | awk '{print $4}' | cut -d: -f1 | sort | uniq -c | sort -rn | head -20
# xem tổng số kết nối đang mở
ss -s
# xem log truy cập gần nhất
tail -n 200 /var/log/nginx/access.logBa dấu hiệu nghiêng về tấn công: một vài địa chỉ chiếm số kết nối bất thường, các yêu cầu lặp lại y hệt nhau vào cùng một đường dẫn, và lưu lượng tăng vọt mà không có chiến dịch quảng cáo hay bài viết nào lan truyền.
Ngược lại, nếu lưu lượng tăng dần theo giờ và trải đều trên nhiều trang khác nhau thì nhiều khả năng đó là khách thật, vấn đề nằm ở chỗ máy chủ không đủ sức.
Xử lý khi đang bị tấn công
- Bật lớp lọc trước máy chủ. Đây là biện pháp mạnh nhất và nhanh nhất với tấn công tầng ứng dụng, vì lưu lượng xấu bị chặn trước khi chạm tới máy của bạn.
- Giới hạn tốc độ. Cấu hình giới hạn số yêu cầu mỗi giây cho mỗi địa chỉ ở tầng máy chủ web.
- Chặn có chọn lọc. Nếu tấn công tập trung từ vài dải địa chỉ, chặn tạm các dải đó. Cẩn thận đừng chặn nhầm khách thật.
- Tăng tài nguyên tạm thời. Không giải quyết gốc rễ nhưng giúp cầm cự trong lúc xử lý.
- Báo nhà cung cấp. Họ nhìn được lưu lượng ở tầng mạng và lọc được những thứ bạn không lọc được từ bên trong máy ảo.
Phòng ngừa quan trọng hơn chữa cháy
- Giấu địa chỉ IP gốc. Nếu đã dùng lớp lọc phía trước, đừng để lộ IP thật qua bản ghi DNS cũ, qua email gửi đi hay qua trang lỗi.
- Chỉ mở cổng thật sự cần. Đóng hết phần còn lại bằng tường lửa.
- Bật giới hạn tốc độ ngay từ đầu, đừng đợi tới lúc bị tấn công mới cấu hình.
- Có bản backup gần nhất. Một số cuộc tấn công đi kèm nỗ lực xâm nhập, khả năng khôi phục nhanh là tuyến phòng thủ cuối.
- Chuẩn bị sẵn kịch bản. Biết trước gọi ai, bật gì, chặn ở đâu giúp rút ngắn thời gian gián đoạn từ vài giờ xuống vài phút.
Câu hỏi thường gặp
Làm sao biết VPS đang bị DDoS hay chỉ quá tải?
Tấn công thường có lưu lượng tăng đột ngột, tập trung vào một đường dẫn và đến từ số ít nguồn lặp lại. Quá tải do khách thật thì tăng dần và trải đều trên nhiều trang.
Chặn theo quốc gia có nên không?
Chỉ nên khi bạn chắc chắn không có khách hàng ở khu vực đó. Đây là biện pháp thô, dễ chặn nhầm người dùng thật.
Nhà cung cấp có chống DDoS giúp không?
Nhiều nơi có lọc ở tầng mạng cho các dạng tấn công lớn. Với tấn công tầng ứng dụng thì cần thêm lớp lọc phía trước và cấu hình từ phía bạn. Nên hỏi rõ phạm vi hỗ trợ trước khi mua.
Bị tấn công có mất dữ liệu không?
Thường là không, tấn công từ chối dịch vụ nhằm làm gián đoạn chứ không nhằm lấy dữ liệu. Nhưng nó có thể là màn che cho nỗ lực xâm nhập, nên sau sự cố cần rà lại nhật ký hệ thống.
Bài viết liên quan
- Tailscale + Docker: sidecar đưa container vào tailnet
- Tailscale là gì? Mạng riêng nối mọi thiết bị của bạn
- Backup VPS hằng ngày bằng restic + Backblaze B2: rẻ, tự động
- DevOps thuê ngoài vs hire in-house: so sánh 2026
- Drizzle ORM + Postgres VPS: stack siêu nhanh cho prototype
- Cursor vs Claude Code 2026: IDE hay terminal, chọn gì?



