Nload và Iftop kiểm tra lưu lượng proxy trên Linux

Nload và Iftop kiểm tra lưu lượng proxy ở hai mức: tổng nhịp truyền trên interface và các cặp đầu kết nối đang hoạt động. ProxyVN cùng anh em chọn đúng interface, đọc đơn vị, lọc một nhóm lưu lượng và đối chiếu socket với tiến trình để tìm hướng điều tra, thay vì coi mọi đợt tăng băng thông là lỗi của proxy.

Nload và Iftop kiểm tra lưu lượng proxy theo câu hỏi

Một máy vận hành proxy có thể chậm vì đường truyền bận, một tiến trình dùng nhiều tài nguyên hoặc website đích phản hồi lâu. Hai công cụ mạng không tự xác định nguyên nhân của mọi tình huống đó. nload giúp nhìn tổng lưu lượng theo interface, còn iftop giúp quan sát theo cặp host trong phạm vi gói tin nó đếm. Kết quả là bằng chứng để chọn bước điều tra tiếp theo.

Trang dự án nload mô tả giao diện theo dõi nhịp nhận và gửi theo thời gian thực. Công cụ không trình bày danh sách tiến trình tiêu thụ mạng như một trình quản lý tác vụ. Vì vậy, thấy đường truyền tăng trong nload chưa đủ để gọi tên ứng dụng gây ra. Cần ghép thêm thông tin kết nối và ngữ cảnh tác vụ trên host.

Tách quan sát hiện tại với lịch sử dung lượng

Lịch sử theo ngày hoặc tháng trả lời đã truyền bao nhiêu trong kỳ. Quan sát hiện tại trả lời lúc này có những luồng nào và nhịp truyền ra sao. Bài viết tập trung vào điều tra trong một cửa sổ ngắn trên Linux host do anh em quản lý. Nó không thay thế hệ thống lưu lịch sử hoặc dashboard tính phí của một nhà cung cấp proxy thương mại.

Tình huống minh họa là một proxy thử trên VPS có interface ens3, một client lab và một website thử. Những tên hoặc địa chỉ trong lệnh phải thay bằng môi trường được phép. Bài không công bố số đo từ máy khách hàng, không đưa benchmark tốc độ và không giả định người thuê proxy có quyền xem máy chủ của bên cung cấp. Phạm vi quan sát nằm trên host đang chạy công cụ.

Chọn mục tiêu trước khi mở màn hình

Nếu câu hỏi là tổng interface có đang bận hơn lúc bình thường hay không, bắt đầu với nload. Nếu cần biết nhóm đầu kết nối nào đóng góp nhiều, dùng iftop với interface và bộ lọc rõ. Nếu cần tìm tiến trình sở hữu socket, đối chiếu bằng công cụ hệ điều hành. Mỗi câu hỏi cần nguồn phù hợp; mở nhiều terminal chưa làm kết luận chính xác hơn nếu chúng đo khác phạm vi.

Khi chuẩn bị một tác vụ có IP đường ra riêng, anh em có thể tham khảo mua proxy và xác nhận hạn mức phù hợp; việc chọn dịch vụ vẫn cần dựa trên yêu cầu tác vụ, không chỉ một ảnh tốc độ tức thời.

Nload và Iftop kiểm tra lưu lượng proxy từ interface

Sai interface có thể tạo một màn hình gần như trống trong khi ứng dụng vẫn truyền dữ liệu. Một host có interface vật lý, bridge, tunnel và các veth của container cần được đọc theo sơ đồ đường đi. Đừng chọn interface đầu tiên xuất hiện chỉ vì tên quen thuộc. Xác định ứng dụng chạy trong namespace nào và lưu lượng rời host qua đâu trước khi thu số liệu.

Kiểm kê mạng bằng thao tác chỉ đọc

Trên Linux, các lệnh sau giúp xem interface và bộ đếm cơ bản. Chúng không thay đổi tuyến hoặc cấu hình proxy. Tên ens3 chỉ là ví dụ cần thay theo host thực tế. Tài liệu thống kê mạng của Linux kernel giải thích phạm vi những bộ đếm interface được các công cụ sử dụng hoặc đối chiếu.

ip -brief address
ip -s link show dev ens3

Ghi tên interface cùng vị trí đo vào biên bản. Nếu chạy công cụ bên trong container, kết quả có thể chỉ phản ánh mạng của container thay vì toàn host. Nếu dùng namespace riêng, một lệnh trên host có thể không hiển thị cùng socket. Những khác biệt này cần được ghi nhận trước khi kết luận ứng dụng không tạo kết nối hoặc công cụ không hoạt động.

Ranh giới interface cần rõ

Chọn một ranh giới để tránh đếm nhiều lần

Proxy có thể nhận phản hồi từ website rồi gửi tiếp cho client. Khi cả hai chặng đi qua cùng interface, tổng nhận và gửi có quan hệ với cả hai hướng của luồng chuyển tiếp. Nếu cộng thêm interface tunnel và bridge, cùng dữ liệu còn có thể được quan sát ở nhiều lớp. Không dùng tổng cộng mọi giao diện làm số nội dung khách hàng thực sự tải xuống.

Đối với điều tra sự cố, thường hữu ích hơn khi chọn một điểm chính và thêm một điểm đối chiếu có mục đích. Chẳng hạn, interface ngoài để nhìn mức bận của đường ra, còn log ứng dụng để biết tác vụ nào đang chạy. Nếu hai số không khớp, trước tiên kiểm tra phạm vi và thời gian. Một khác biệt chưa được giải thích không tự chứng minh có lưu lượng lạ.

Xác định chiều từ góc nhìn công cụ

Incoming và outgoing là hướng tương đối với điểm quan sát đã chọn, không phải tên cố định cho tải xuống hay tải lên của người dùng. Khi chuyển từ interface ngoài sang tunnel, cách diễn giải có thể khác. Anh em nên vẽ một request và một response qua proxy để gắn nhãn hướng. Sơ đồ nhỏ này giúp tránh đảo chiều khi gửi báo cáo cho đội mạng hoặc nhà cung cấp.

Nload và Iftop kiểm tra lưu lượng proxy bằng nload

nload phù hợp để xem nhịp truyền thay đổi khi tác vụ bắt đầu, đạt trạng thái ổn định rồi kết thúc. Manual nload trong gói Debian mô tả cách chọn interface, đơn vị và cửa sổ hiển thị. Cần đối chiếu --help trên bản cài, vì một nguồn mã phát triển có thể chứa tùy chọn chưa có trong gói của hệ thống đang dùng.

Dùng đơn vị có ghi nhãn

Ví dụ sau chọn ens3, dùng đơn vị byte cho tốc độ và tổng theo cách tùy chọn nload quy định. Chữ hoa và chữ thường trong tùy chọn đơn vị có ý nghĩa khác nhau. Khi chụp kết quả, giữ phần nhãn đơn vị để người khác không hiểu một giá trị byte mỗi giây thành bit mỗi giây. Không quy đổi từ ảnh đã cắt mất nhãn nếu chưa biết cấu hình gốc.

nload -u M -U M ens3

Quan sát mức nền trước khi bắt đầu tác vụ thử, ghi thời điểm bắt đầu và kết thúc rồi dừng bằng q hoặc Ctrl+C. Không cần giảm khoảng làm mới tới mức rất ngắn để tạo cảm giác đo chính xác hơn. Cửa sổ hiển thị, cách lấy mẫu và biến động thật của mạng cần được hiểu cùng nhau. Một số nhảy nhanh không có nghĩa ứng dụng đã truyền thêm nội dung hữu ích.

Đọc Current, Average và tổng theo đúng khoảng

Giá trị hiện tại mô tả nhịp của cửa sổ tính tương ứng, còn trung bình và tổng phụ thuộc cách công cụ thu thập trong phiên chạy. Chúng không tự trở thành lịch sử tháng của máy. Nếu tắt rồi mở lại công cụ, cần biết phần dữ liệu nào đã được bắt đầu lại theo thiết kế. Không ghép hai ảnh chụp rời thành một chuỗi liên tục mà không ghi khoảng trống.

Các đỉnh ở hai thời điểm khác nhau cũng không nên cộng thành một đỉnh tổng giả. Nếu muốn biết tình trạng của một tác vụ, giữ cùng cửa sổ quan sát và đối chiếu thời gian của log ứng dụng. Một lần nhìn thấy TX tăng rồi vài giây sau RX tăng không đủ để báo hai hướng cùng đạt đỉnh tại một thời điểm. Độ chính xác của diễn giải quan trọng hơn số chữ số hiển thị.

Dùng nhiều interface khi có câu hỏi cụ thể

nload có chế độ hiển thị nhiều thiết bị, nhưng việc nhìn nhiều cột không thay thế thiết kế điểm đo. Nếu đang so interface tunnel và interface ngoài, ghi rõ vì sao cần so và phần overhead nào có thể khác. Đừng lấy hai con số không cùng ranh giới rồi kết luận một bên làm mất lưu lượng. Khi chưa có yêu cầu phân tích hai lớp, giữ màn hình đơn giản sẽ dễ đọc hơn.

Tổng nhịp truyền trong nload

Nload và Iftop kiểm tra lưu lượng proxy bằng iftop

Manual iftop do Debian phân phối mô tả bảng lưu lượng theo cặp host trên interface được chọn. Công cụ cần quyền phù hợp để quan sát gói tin. Trong host được quản lý, chỉ mở phiên theo dõi cho mục đích đã xác định. Không mặc định việc có quyền SSH nghĩa là được thu hoặc chia sẻ mọi thông tin mạng của những người dùng khác trên máy.

Bắt đầu với địa chỉ và cổng dạng số

Ví dụ sau tắt phân giải tên host và tên dịch vụ, đồng thời bật hiển thị cổng. Cách này giúp giữ đầu kết nối rõ ràng và tránh những truy vấn phân giải tên do chính công cụ tạo ra. Nó không giải mã HTTPS và không cho biết URL bên trong một kết nối mã hóa. Địa chỉ nhìn thấy là đầu mạng ở điểm đo, có thể là proxy upstream hoặc CDN thay vì origin cuối.

sudo iftop -i ens3 -n -N -P

Quan sát các cặp liên quan tới tác vụ lab và những cửa sổ trung bình hiển thị. Giữ nhãn thời gian của từng cột khi ghi kết quả. Một cặp đứng đầu trong cửa sổ ngắn có thể không đứng đầu trong cửa sổ dài hơn. Không nên gọi một host là nguồn gây nghẽn chỉ vì nó xuất hiện đầu bảng trong một lần nhìn, đặc biệt khi tổng đường truyền vẫn thấp hơn nhiều so với giới hạn thực tế.

Chạy cửa sổ văn bản có thời gian giới hạn

Nếu bản iftop đang cài hỗ trợ các tùy chọn dưới, có thể lấy một bản quan sát ngắn để đưa vào hồ sơ sự cố. Lệnh chỉ là hướng dẫn cho môi trường được phép, không phải kết quả đã chạy trên VPS của ProxyVN. Số hai mươi giây và mười dòng là giới hạn minh họa do người viết chọn để giữ phạm vi thu gọn, không phải ngưỡng chuẩn áp dụng cho mọi sự cố.

sudo iftop -i ens3 -n -N -P -t -s 20 -L 10

Đầu ra nên được kiểm tra và che địa chỉ nội bộ hoặc thông tin nhận dạng trước khi chia sẻ. Không cần xuất toàn bộ lưu lượng của host để hỏi về một kết nối thử. Khi số dòng bị giới hạn, ghi điều đó trong biên bản để người đọc không tưởng danh sách đầy đủ. Những dòng không xuất hiện có thể nằm dưới giới hạn hiển thị, không đồng nghĩa chúng không tồn tại.

Bộ lọc thay đổi tập dữ liệu đang đếm

Với một địa chỉ lab cụ thể, có thể dùng -f cùng biểu thức bộ lọc được phiên bản hỗ trợ. Ví dụ host 192.0.2.10 là địa chỉ tài liệu cần thay bằng đầu thử thật. Khi đã lọc, tổng hiển thị cần được đọc trong phạm vi lọc tương ứng. Không so nó trực tiếp với tổng interface từ nload rồi kết luận công cụ làm mất một phần dữ liệu.

sudo iftop -i ens3 -n -N -P -t -s 20 \
  -f 'host 192.0.2.10'

Nếu cần cú pháp phức tạp hơn, đọc manual bộ lọc của gói đang dùng và kiểm tra trước trong lab. Thay bộ lọc khi đang chạy có thể khiến phần hiển thị vẫn phản ánh cửa sổ dữ liệu trước đó một thời gian. Dừng và mở một lần thu mới có phạm vi rõ thường dễ diễn giải hơn trong bài kiểm tra ngắn. Ghi nguyên biểu thức lọc đã dùng cùng kết quả.

Nload và Iftop kiểm tra lưu lượng proxy cùng tiến trình

iftop nhóm theo đầu kết nối, không phải bảng gán mọi byte cho một PID. Muốn biết tiến trình sở hữu socket, cần nguồn hệ điều hành tương ứng. Manual ss của iproute2 mô tả cách xem socket cùng thông tin tiến trình theo quyền. Kết quả giúp liên kết ngữ cảnh, nhưng không tự cung cấp lịch sử dung lượng theo PID của toàn cửa sổ trước đó.

Đối chiếu socket tại cùng thời điểm

Lệnh minh họa xem các socket TCP cùng thông tin tiến trình khi được quyền. Chạy gần thời điểm quan sát iftop rồi đối chiếu địa chỉ, cổng và namespace phù hợp. Một kết nối ngắn có thể đóng trước khi lệnh chạy, nên không xuất hiện trong ss không chứng minh nó chưa từng tồn tại. Nếu cần điều tra các luồng rất ngắn, phải thiết kế cách thu dữ liệu phù hợp thay vì chỉ chụp một thời điểm.

sudo ss -tnp

Khi socket thuộc tiến trình proxy, đó mới chỉ là tên thành phần chuyển tiếp. Muốn biết tài khoản hay request bên trong, cần log ở lớp proxy với chính sách dữ liệu thích hợp. Nhiều người dùng có thể dùng chung một tiến trình hoặc một kết nối upstream. Đừng suy ra một PID tương ứng một khách hàng, và cũng đừng gán mọi byte của tiến trình cho tác vụ duy nhất đang được điều tra.

Cặp host khác tiến trình

Ghép với log ứng dụng có mã tương quan

Nếu ứng dụng do mình quản lý, ghi thời điểm tác vụ, request ID và endpoint đã che dữ liệu nhạy cảm. Đối chiếu chúng với đợt tăng lưu lượng để tạo giả thuyết có cơ sở hơn. Các kết nối mã hóa hoặc được tái sử dụng vẫn có thể mang nhiều request. Vì vậy, một cặp host trong iftop chưa đủ để tính chi phí từng API call nếu thiếu dữ liệu ở lớp ứng dụng.

Không quy hành vi từ địa chỉ đơn lẻ

Một địa chỉ có thể thuộc dịch vụ CDN, proxy upstream hoặc hạ tầng dùng chung. Nhìn nó đứng đầu bảng không cho biết tác vụ có hợp lệ hay không. Hãy đối chiếu lịch công việc, cấu hình ứng dụng và quyền truy cập. Nếu thấy kết nối không giải thích được, giữ bằng chứng và chuyển người phụ trách điều tra; không tắt tiến trình sản xuất chỉ từ một lần quan sát chưa xác nhận.

Nload và Iftop kiểm tra lưu lượng proxy khi số liệu lệch

Hai công cụ có thể hiển thị số khác nhau vì tập dữ liệu, đơn vị, cửa sổ và cách quan sát không giống nhau. Mục tiêu là giải thích sai khác, không ép hai màn hình trùng từng chữ số. Trước khi nghi công cụ lỗi, ghi cấu hình đầy đủ và đảm bảo đang nhìn cùng interface trong cùng thời điểm. Bỏ qua một trong các điều kiện này sẽ làm phép so không còn cùng phạm vi.

Kiểm tra đơn vị trước tiên

iftop mặc định và nload theo tùy chọn có thể dùng cách hiển thị bit hoặc byte khác nhau. Một thay đổi đơn vị có thể tạo cảm giác tốc độ lệch lớn dù phản ánh cùng nhịp dữ liệu. Khi báo cáo, ghi cả đơn vị và lựa chọn hiển thị. Không dùng ký hiệu M chung cho những bảng mà người đọc không biết đang nói tới tốc độ hay dung lượng.

Tiếp theo xem các cửa sổ trung bình. Một công cụ đang phản ánh khoảng ngắn có thể còn thấy đỉnh vừa xuất hiện, trong khi trung bình dài chưa tăng nhiều. Nếu cần đối chiếu, chọn cửa sổ phù hợp hoặc thu dữ liệu có thời gian rõ để phân tích sau. Chụp hai màn hình cách nhau nhiều giây trong lúc tải biến động không tạo thành một phép so chính xác.

Xem phạm vi gói tin và bộ lọc

iftop đếm lưu lượng theo phạm vi mà nó quan sát cùng bộ lọc đang dùng, còn thống kê interface có định nghĩa rộng hoặc khác tùy nguồn. Những loại gói không nằm trong tập iftop đếm sẽ không tự xuất hiện chỉ vì tổng kernel tăng. Không coi đây là lỗi thất thoát trước khi đọc manual và xác định phần nào có thể so. Từng nguồn cần được giữ đúng ý nghĩa của nó.

Nếu dùng bộ lọc host, port hoặc mạng, ghi rõ đó là tổng của nhóm đã lọc. Một proxy có cổng nhận client và nhiều cổng upstream có thể không được bao phủ bởi bộ lọc chỉ nhìn cổng listener. Đội vận hành cần biết đang kiểm tra chặng vào hay chặng ra. Thiếu thông tin này, một phần lưu lượng bình thường có thể bị gọi nhầm là traffic ngoài dự kiến.

Kiểm tra tài nguyên của chính phép quan sát

Quan sát gói tin có chi phí và yêu cầu quyền khác với đọc bộ đếm tổng. Trên host bận, giữ phiên thu có giới hạn và theo dõi khả năng công cụ xử lý theo môi trường. Không bật thêm nhiều phiên capture không cần thiết chỉ để có nhiều ảnh. Nếu cần đo lâu dài, chọn hệ thống giám sát phù hợp thay vì để một terminal tương tác trở thành nguồn duy nhất cho lịch sử vận hành.

Nload và Iftop kiểm tra lưu lượng proxy bằng phép thử nhỏ

Một phép thử ngắn có đối chứng giúp hiểu quan hệ giữa tác vụ và số đo. Chuẩn bị client cùng đích lab, chọn số request hữu hạn và payload đã biết phạm vi. Quan sát mức nền, chạy tác vụ rồi dừng, ghi thời gian để đối chiếu. Không cần tạo tải lớn hoặc dùng website bên ngoài chưa cho phép để kiểm tra những nguyên tắc đọc công cụ cơ bản.

Giữ điều kiện trước và sau

Trước thử, ghi interface, phiên bản công cụ, đơn vị và bộ lọc. Trong lúc thử, giữ những tác vụ khác ổn định theo khả năng kiểm soát. Sau thử, xem mức lưu lượng trở về ra sao và giữ log ứng dụng tương ứng. Nếu cùng lúc có bản sao lưu hoặc cập nhật image, ghi đó là yếu tố ảnh hưởng. Không gán mọi phần tăng vào tác vụ chỉ vì chúng xảy ra cùng khoảng.

Nếu muốn xem ảnh hưởng của một cấu hình proxy, thay đúng cấu hình đó trong đợt thứ hai và giữ tập request như cũ. Chạy lại không nhất thiết cho cùng số đo do mạng và cache có trạng thái. Kết luận nên nêu điều kiện và xu hướng quan sát, không công bố một hệ số tốc độ cố định từ hai ảnh terminal. Những số đo có mục đích rõ sẽ giúp quyết định bước kiểm tra tiếp theo.

Lưu kết quả mà không tạo benchmark giả

Một hồ sơ nhỏ có thể gồm lệnh, thời gian, đầu ra đã làm sạch và mô tả tác vụ. Nếu chỉ kiểm tra cú pháp hoặc đối chiếu manual, hãy ghi đúng mức đó. Bài này không kèm số đo nload hoặc iftop từ một VPS thật. Mọi dữ liệu dùng để kiểm tra bộ xử lý log sau này phải được đánh dấu fixture để không biến thành hình minh họa kết quả thương mại.

Tổng interface, bảng cặp host và danh sách socket trả lời ba câu hỏi khác nhau; ghép đúng thời điểm và phạm vi mới giúp tìm nguyên nhân.

Nload và Iftop kiểm tra lưu lượng proxy trước khi kết luận

Một kết luận tốt chỉ ra phần bằng chứng đã có và phần cần bổ sung. Nếu tổng interface tăng, iftop cho thấy một cặp host liên quan và log xác nhận tác vụ đang truyền, anh em đã có hướng điều tra rõ hơn. Nhưng muốn gọi đó là nghẽn, còn cần giới hạn đường truyền, hàng đợi, lỗi hoặc tác động lên tác vụ. Lưu lượng nhiều không tự đồng nghĩa hệ thống đang hoạt động sai.

Gói bằng chứng có phạm vi

Gửi báo cáo đủ để người khác kiểm tra

Gói hỗ trợ nên nêu máy đo, interface, múi giờ, đơn vị, khoảng quan sát và lệnh đã dùng. Thêm các đầu kết nối liên quan đã che theo chính sách dữ liệu cùng request ID nếu có. Không gửi credentials proxy hoặc toàn bộ danh sách kết nối của host khi chưa cần. Bằng chứng có phạm vi giúp đội hỗ trợ đặt câu hỏi tiếp theo thay vì phải đoán từ một ảnh đã cắt mất nhãn.

Sau khi sửa, chạy lại tình huống ban đầu và xác nhận một tác vụ bình thường không bị ảnh hưởng. Nếu chỉ đóng một tác vụ gây tải, ghi rõ đó là hành động giảm tải chứ chưa phải sửa nguyên nhân gốc. Nếu thay cấu hình, lưu phiên bản và cách quay lại. Những phân biệt này giúp lần sự cố sau có thể đối chiếu, thay vì lặp lại toàn bộ quá trình quan sát từ đầu.

Tính cả kết nối dùng để quan sát

Nếu đang mở terminal qua SSH, chính phiên quản trị cũng tạo lưu lượng trên interface. Việc liên tục xuất bảng dài hoặc truyền tệp log về máy có thể làm số đo thay đổi trong lúc thu thập. Với một phép thử nhỏ, ghi nhận kết nối quản trị và tránh tải những tệp lớn cùng thời điểm. Không tự loại mọi lưu lượng SSH khỏi mọi báo cáo, vì mục tiêu tổng interface vẫn có thể cần giữ nó; chỉ chọn bộ lọc khi đang trả lời câu hỏi hẹp hơn.

Dừng ở đúng phạm vi công cụ

Nguồn được kiểm tra ngày 26/10/2026 gồm tài liệu dự án, manual gói phân phối và công cụ socket của Linux. Khả năng tùy chọn còn cần đối chiếu bản cài trên host. Bài không xác nhận hiệu năng một dịch vụ proxy hoặc khả năng giải mã lưu lượng HTTPS. Mục tiêu là một quy trình điều tra có thể thực hiện trong môi trường được quyền và diễn giải số liệu theo đúng tầng.

Nload và Iftop kiểm tra lưu lượng proxy hiệu quả khi anh em chọn đúng interface, đơn vị và cửa sổ quan sát. Hãy ghép thêm socket cùng log ứng dụng trước khi quy nguyên nhân. Trao đổi cùng Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam để xác định nhu cầu đường truyền khi dùng Nload và Iftop kiểm tra lưu lượng proxy.