Tcpdump kiểm tra kết nối proxy: lọc gói và đọc SYN retry

Tcpdump kiểm tra kết nối proxy là cách nhìn trực tiếp các gói TCP giữa máy chạy ứng dụng và proxy, để biết kết nối hỏng ở bước bắt tay, bước xác thực hay ở phía trang đích. Trên máy chủ Linux không có giao diện, tcpdump thường là công cụ duy nhất có sẵn để làm việc này. ProxyVN đo thời gian thật của ba ca kết nối tới proxy trên máy lab, rồi đặt từng ca cạnh dạng gói tin tcpdump sẽ in ra để anh em đọc được log khi gặp lỗi thật.

Tcpdump kiểm tra kết nối proxy: lớp nào quyết định hành vi

Một request qua proxy HTTP đi qua bốn bước: mở kết nối TCP tới proxy, gửi request hoặc lệnh CONNECT, proxy mở kết nối ra trang đích, rồi dữ liệu chảy hai chiều. Mỗi bước để lại dấu vết khác nhau trên dây mạng. Tcpdump nhìn thấy bước nào phụ thuộc vào chỗ anh em bắt gói.

Bắt ở máy client

Bắt gói trên máy chạy crawler hay ứng dụng cho thấy chặng client tới proxy. Anh em thấy gói SYN đi ra, phản hồi của proxy, lệnh CONNECT nếu là HTTPS, và mã phản hồi đầu tiên của proxy. Chặng proxy tới trang đích không nhìn thấy từ đây.

Đây là chỗ bắt gói hay dùng nhất, vì anh em luôn có quyền trên máy của mình. Với proxy thương mại, đây cũng là chỗ duy nhất có thể bắt.

Bắt ở máy proxy

Nếu tự dựng proxy, bắt gói trên máy proxy cho thấy cả hai chặng. Một request từ client vào và một kết nối từ proxy ra trang đích. So thời điểm hai chặng cho biết proxy mất bao lâu để xử lý và trang đích phản hồi chậm hay nhanh.

Tcpdump thấy gì và không thấy gì

Tcpdump thấy tiêu đề IP và TCP của mọi gói: địa chỉ, cổng, cờ TCP, số thứ tự, kích thước. Với HTTP thường, nó thấy cả nội dung request, kể cả header Proxy-Authorization chứa thông tin đăng nhập proxy. Với HTTPS, sau lệnh CONNECT, nội dung đã được mã hóa TLS, chỉ thấy tên miền trong trường SNI của gói đầu.

Tcpdump trả lời câu hỏi gói có đi và có về không, chứ không trả lời vì sao ứng dụng báo lỗi. Khi gói về đầy đủ mà ứng dụng vẫn lỗi, nguyên nhân nằm ở tầng trên như chứng chỉ, mã HTTP hay cấu hình thư viện.

Chặng nào nên bắt trước

Khi gặp lỗi, bắt ở máy client trước. Chặng này luôn trong tầm tay và trả lời câu hỏi đầu tiên: request có tới được proxy không. Phần lớn sự cố dừng ở đây, vì lỗi thường nằm ở cấu hình, tường lửa chiều ra hoặc thông tin xác thực.

Chỉ khi chặng client tới proxy sạch, tức là bắt tay xong và proxy trả mã lỗi về, mới cần nhìn chặng proxy tới trang đích. Với proxy tự dựng, bắt thêm trên máy proxy. Với proxy thương mại, gửi bằng chứng chặng đầu cho nhà cung cấp kèm thời điểm và địa chỉ đích.

Một cách khác khi không có quyền trên máy proxy là so với đường đi thẳng. Bắt gói khi gọi trang đích không qua proxy từ cùng máy. Nếu đi thẳng ổn mà qua proxy lỗi, chặng proxy tới trang đích là nghi phạm.

Khác gì Wireshark

Bài Wireshark proxy hướng dẫn phân tích gói bằng giao diện đồ họa. Tcpdump là công cụ dòng lệnh, chạy trên máy chủ từ xa qua SSH, ghi ra tệp pcap. Tệp đó có thể chép về máy có Wireshark để xem kỹ. Bài này đi vào phần dòng lệnh: bắt, lọc và đọc nhanh ngay trên máy chủ.

Bắt gói bằng dòng lệnh trên máy chủ, lọc host và port, tách SYN retry với kết nối thành công khi tcpdump kiểm tra kết nối proxy

Phần này đi qua các lệnh cần nhớ và cách đọc một dòng đầu ra. Cú pháp lấy theo trang man tcpdump và trang man pcap-filter, đọc ngày 29/10/2026.

Lệnh bắt cơ bản

sudo tcpdump -i any -nn host 203.0.113.50 and port 8080

Tùy chọn -i any bắt trên mọi giao diện mạng. Tùy chọn -nn tắt phân giải tên máy và tên cổng, giúp đầu ra hiện số thật và không sinh thêm truy vấn DNS làm nhiễu. Biểu thức host và port giới hạn chỉ các gói tới hoặc từ proxy.

Thay 203.0.113.50 và 8080 bằng địa chỉ và cổng proxy thật. Nếu proxy cấu hình bằng tên miền, hãy phân giải ra địa chỉ trước, vì tcpdump lọc theo địa chỉ IP.

Chọn giao diện bắt

Trên máy có nhiều giao diện mạng, như máy chủ có Docker, VPN hay nhiều card mạng, gói tới proxy có thể đi qua giao diện mà anh em không ngờ. Tùy chọn -i any gom tất cả, an toàn khi chưa biết. Khi đã biết, dùng tên giao diện cụ thể để giảm nhiễu.

Lệnh tcpdump -D liệt kê các giao diện có thể bắt. Với container Docker, gói từ container ra ngoài đi qua giao diện cầu docker0 trước rồi mới tới giao diện vật lý, địa chỉ nguồn đổi sau bước NAT. Bắt ở docker0 thấy địa chỉ container, bắt ở giao diện vật lý thấy địa chỉ máy chủ.

Ghi ra tệp và giới hạn kích thước

sudo tcpdump -i any -nn -s 128 -c 2000 -w proxy.pcap host 203.0.113.50 and port 8080
tcpdump -nn -r proxy.pcap

Tùy chọn -w ghi gói thô ra tệp thay vì in ra màn hình. Tùy chọn -c dừng sau 2.000 gói, tránh tệp phình ra khi quên tắt. Tùy chọn -s 128 chỉ giữ 128 byte đầu của mỗi gói, đủ cho tiêu đề IP và TCP, cắt phần lớn nội dung. Mặc định tcpdump giữ tới 262.144 byte mỗi gói.

Giới hạn kích thước gói không chỉ để tiết kiệm. Nó giảm lượng dữ liệu nhạy cảm nằm trong tệp, như header xác thực proxy hay cookie. Với chẩn đoán kết nối, phần lớn trường hợp không cần nội dung.

Khi bắt lâu, dùng -C để cắt tệp theo dung lượng hoặc -G để cắt theo thời gian, kết hợp -W để giới hạn số tệp giữ lại. Ba tùy chọn này giữ đĩa không bị đầy khi để tcpdump chạy qua đêm chờ lỗi.

Lọc theo cờ TCP

sudo tcpdump -i any -nn 'host 203.0.113.50 and tcp[tcpflags] & (tcp-syn|tcp-rst) != 0'

Biểu thức này chỉ in gói có cờ SYN hoặc RST, tức là các gói mở và từ chối kết nối. Khi crawler gửi hàng nghìn request, lọc như vậy bỏ đi toàn bộ gói dữ liệu, chỉ còn lại các lần thử kết nối và các lần bị từ chối.

Đọc một dòng đầu ra

14:02:11.120345 IP 10.0.0.5.51234 > 203.0.113.50.8080: Flags [S], seq 1849021, win 64240, length 0

Cột đầu là thời điểm. Sau chữ IP là địa chỉ và cổng nguồn, dấu lớn hơn, rồi địa chỉ và cổng đích. Phần Flags là cờ TCP. Dòng trên là gói SYN từ client cổng 51234 tới proxy cổng 8080.

Bảng: Đọc một dòng đầu ra

Cờ trong tcpdump	Ý nghĩa	Gặp khi
[S]	SYN	Client mở kết nối
[S.]	SYN kèm ACK	Proxy đồng ý mở kết nối
[.]	ACK	Xác nhận dữ liệu
[P.]	PUSH kèm ACK	Gói có dữ liệu như request HTTP
[F.]	FIN kèm ACK	Một bên đóng kết nối
[R] hoặc [R.]	RST	Từ chối hoặc hủy kết nối

Ba mẫu bắt tay cần nhận ra

Ba mẫu bắt tay

Kết nối thành công có ba gói đầu: [S] đi, [S.] về, [.] đi. Sau đó là gói [P.] chứa request và gói [P.] chứa phản hồi.

Kết nối bị từ chối có [S] đi rồi [R.] về ngay. Proxy hoặc máy đích không có gì lắng nghe ở cổng đó, hoặc tường lửa trả RST.

Kết nối không có phản hồi có [S] đi, không có gì về, rồi [S] đi lại sau một khoảng, lặp vài lần với khoảng cách tăng dần. Đây là SYN retry: gói bị chặn trên đường hoặc proxy không nhận được.

Thiết kế lab tcpdump kiểm tra kết nối proxy: phiên bản và phép đo

Máy lab của ProxyVN là Windows 10, tài khoản không có quyền quản trị. Bắt gói trên Windows cần trình điều khiển như Npcap hoặc công cụ pktmon chạy với quyền quản trị, nên lab không bắt được gói thật. Đây là giới hạn chính của bài.

Phần đã chạy thật

Lab chạy script Python 3.12.10 đo thời gian ba ca kết nối từ chính máy lab. Ca một tới một proxy giả lập ở 127.0.0.1 cổng 9561, nhận lệnh CONNECT và trả 200. Ca hai tới cổng 9562 không có gì lắng nghe. Ca ba tới 192.0.2.1 cổng 8080, địa chỉ dành cho tài liệu, không có máy nào trả lời.

Mỗi ca ghi kết quả và thời gian từ lúc gọi connect tới lúc có kết quả. Ca ba được chạy thêm một lần với timeout 5 giây đặt trong mã để so với timeout mặc định của hệ điều hành.

Phần chưa chạy

Các lệnh tcpdump trong bài chưa được ProxyVN chạy, vì máy lab không có tcpdump và không có quyền bắt gói. Các dòng đầu ra tcpdump trong bài là mẫu dựng theo định dạng của trang man và theo thời gian đo được, ghi rõ là mẫu. Anh em chạy trên máy Linux thật sẽ thấy số thứ tự, kích thước cửa sổ và tùy chọn TCP khác.

Vì sao chọn ba ca này

Ba ca tương ứng ba kết quả khác nhau của bước bắt tay TCP: thành công, bị từ chối và không có phản hồi. Mọi lỗi kết nối tới proxy đều rơi vào một trong ba nhóm này, trước khi tới các lỗi tầng HTTP như 407 hay 502.

Địa chỉ 192.0.2.1 thuộc dải TEST-NET-1 theo RFC 5737, không được định tuyến trên Internet. Gói SYN gửi tới đó sẽ không bao giờ có trả lời, mô phỏng đúng tình huống proxy bị tường lửa chặn im lặng hoặc địa chỉ proxy sai.

Proxy giả lập ở ca một chỉ trả dòng 200 cho lệnh CONNECT rồi đóng. Nó không mở kết nối ra ngoài. Mục đích là đo bước bắt tay và phản hồi đầu, không đo chặng ra trang đích.

Kết quả kỳ vọng

Ca một thành công gần như tức thì. Ca hai bị từ chối nhanh. Ca ba hết thời gian sau vài chục giây do hệ điều hành thử gửi lại SYN nhiều lần.

Tái lập ca thành công và ca lỗi có kiểm soát khi tcpdump kiểm tra kết nối proxy

Phần này đưa số đo thật, sau đó là dạng gói tin tương ứng mà tcpdump sẽ in khi chạy trên máy có quyền bắt gói.

Số đo thật trên máy lab

2 giây và 21 giây

Bảng: Số đo thật trên máy lab

Ca	Đích	Kết quả	Thời gian
Proxy sống	127.0.0.1:9561	HTTP/1.1 200 Connection established	0,000 giây
Cổng đóng	127.0.0.1:9562	ConnectionRefusedError, mã 10061	2,037 giây
Không phản hồi	192.0.2.1:8080	TimeoutError, mã 10060	21,042 giây
Không phản hồi, timeout 5 giây	192.0.2.1:8080	TimeoutError	5,000 giây

Ca cổng đóng mất hơn 2 giây dù là localhost. Windows có hành vi thử lại SYN cả khi nhận RST, nên lỗi từ chối kết nối không về ngay. Trên Linux, cùng ca này trả lỗi gần như tức thì.

Ca không phản hồi mất 21 giây trước khi Windows bỏ cuộc. Con số này khớp với mặc định Windows gửi SYN lần đầu rồi thử lại hai lần với khoảng chờ tăng gấp đôi. Đặt timeout 5 giây trong mã thì ứng dụng dừng ở đúng 5 giây.

Mẫu đầu ra ca thành công

Mẫu dưới đây dựng theo định dạng tcpdump cho ca một, không phải bản bắt thật:

10.0.0.5.51234 > 203.0.113.50.8080: Flags [S], length 0
203.0.113.50.8080 > 10.0.0.5.51234: Flags [S.], length 0
10.0.0.5.51234 > 203.0.113.50.8080: Flags [.], length 0
10.0.0.5.51234 > 203.0.113.50.8080: Flags [P.], length 66
203.0.113.50.8080 > 10.0.0.5.51234: Flags [P.], length 39

Ba dòng đầu là bắt tay. Dòng bốn là lệnh CONNECT dài 66 byte, đúng độ dài chuỗi lệnh lab gửi. Dòng năm là phản hồi 39 byte "HTTP/1.1 200 Connection established" kèm hai cặp xuống dòng. Sau đó, nếu là HTTPS, các gói tiếp theo là TLS.

Mẫu đầu ra ca cổng đóng

10.0.0.5.51240 > 203.0.113.50.8080: Flags [S], length 0
203.0.113.50.8080 > 10.0.0.5.51240: Flags [R.], length 0

Chỉ hai gói. Máy proxy còn sống và trả lời, nhưng không có dịch vụ ở cổng đó. Nguyên nhân thường gặp: sai cổng proxy, dịch vụ proxy đã dừng, hoặc tường lửa cấu hình trả RST.

Trên client Windows, sẽ thấy cặp [S] và [R.] lặp lại thêm vài lần trong khoảng 2 giây, khớp với thời gian đo được.

Mẫu đầu ra ca không phản hồi

14:05:00.000 10.0.0.5.51250 > 192.0.2.1.8080: Flags [S], length 0
14:05:03.000 10.0.0.5.51250 > 192.0.2.1.8080: Flags [S], length 0
14:05:09.000 10.0.0.5.51250 > 192.0.2.1.8080: Flags [S], length 0

Ba gói SYN cùng cổng nguồn, cách nhau 3 rồi 6 giây, không có gói nào về. Với Windows, sau gói thứ ba hệ điều hành chờ thêm 12 giây rồi báo lỗi, tổng khoảng 21 giây như số đo.

Trên Linux, số lần và khoảng thử lại do tham số tcp_syn_retries quyết định. Tài liệu IP sysctl của nhân Linux ghi mặc định là 6 lần thử lại, với các bản nhân mới có thêm tcp_syn_linear_timeouts thì tổng thời gian tới lúc bỏ cuộc là 131 giây. Bản nhân cũ hơn dùng khoảng chờ tăng gấp đôi từ đầu, tổng thời gian khác.

Cùng một proxy chết, ứng dụng trên Windows báo lỗi sau 21 giây, trên Linux có thể sau hơn hai phút. Nếu ứng dụng không tự đặt timeout, thời gian treo phụ thuộc hệ điều hành.

Đọc log, gói tin và response để phân biệt nguyên nhân khi tcpdump kiểm tra kết nối proxy

Tcpdump cho thấy gói, log ứng dụng cho thấy lỗi. Đặt hai thứ cạnh nhau theo thời điểm là cách nhanh nhất để biết lỗi ở đâu.

Bảng đối chiếu

Đối chiếu gói và lỗi

Bảng: Bảng đối chiếu

Gói thấy trong tcpdump	Lỗi trong ứng dụng	Nguyên nhân hay gặp
[S], [R.]	Connection refused	Sai cổng, proxy dừng
[S] lặp lại, không có gì về	Connection timed out	Tường lửa chặn, sai địa chỉ, proxy không tới được
Bắt tay xong, [P.] về chứa 407	Proxy Authentication Required	Sai user hoặc mật khẩu proxy
Bắt tay xong, [P.] về chứa 502 hoặc 504	Bad Gateway, Gateway Timeout	Proxy không tới được trang đích
CONNECT xong 200, sau đó [R.]	SSL error hoặc reset	Lỗi TLS với trang đích, bị chặn theo SNI
Không có gói nào	Lỗi ngay, không timeout	Lỗi DNS, lỗi cấu hình, hết cổng nguồn

Dòng cuối quan trọng. Nếu ứng dụng báo lỗi mà tcpdump không thấy gói SYN nào tới proxy, lỗi xảy ra trước khi mở kết nối. Nguyên nhân có thể là tên miền proxy không phân giải được, chuỗi proxy sai định dạng, hoặc hệ điều hành không cấp được cổng.

Bài ERR_CONNECTION_TIMED_OUT và ERR_CONNECTION_REFUSED đi sâu vào hai lỗi ở hai dòng đầu từ phía trình duyệt.

Đọc mã phản hồi của proxy trong gói

Với proxy HTTP, phản hồi đầu tiên của proxy là văn bản thường. Dùng -A để in nội dung gói dạng chữ:

sudo tcpdump -i any -nn -A -s 256 'host 203.0.113.50 and port 8080 and tcp[tcpflags] & tcp-push != 0'

Lệnh này chỉ in gói có dữ liệu, kèm 256 byte đầu ở dạng chữ. Dòng đầu phản hồi như HTTP/1.1 407 hay HTTP/1.1 200 Connection established sẽ hiện rõ. Cẩn thận: gói request cũng hiện ra, kèm header Proxy-Authorization ở dạng base64, giải mã ra được mật khẩu.

Đếm nhanh từ tệp pcap

Khi tệp pcap lớn, không cần đọc từng dòng. Đếm số gói SYN và số gói SYN kèm ACK trong cùng khoảng thời gian cho tỷ lệ kết nối thành công. Nếu SYN nhiều hơn hẳn SYN kèm ACK, nhiều lần thử kết nối không được trả lời.

Lệnh tcpdump -r kèm biểu lọc cờ rồi đếm dòng bằng wc -l là đủ cho việc này. Đếm thêm số gói RST để biết bao nhiêu kết nối bị từ chối hoặc hủy. Ba con số này thường đủ để biết sự cố thuộc nhóm nào trước khi đi vào chi tiết.

Với nhiều proxy cùng lúc, lọc theo từng địa chỉ proxy rồi đếm riêng. Proxy có tỷ lệ SYN không được trả lời cao là proxy đang có vấn đề, loại khỏi bể trong lúc chờ xử lý.

Đo thời gian giữa các bước

Tùy chọn -tttt in ngày giờ đầy đủ, -ttttt in khoảng cách so với gói đầu. So thời điểm gói SYN với gói [S.] cho biết độ trễ mạng tới proxy. So thời điểm gói CONNECT với phản hồi 200 cho biết proxy mất bao lâu để mở kết nối ra trang đích.

Nếu bắt tay nhanh mà phản hồi CONNECT chậm vài giây, mạng tới proxy ổn, phần chậm nằm ở chặng proxy tới trang đích. Bài proxy bị chậm có cách xử lý theo từng chặng.

Khi proxy dùng IPv6

Nếu tên miền proxy có cả bản ghi IPv4 và IPv6, ứng dụng có thể kết nối bằng IPv6 trong khi anh em lọc theo địa chỉ IPv4 và không thấy gói nào. Bộ lọc host nhận cả địa chỉ IPv6. Khi không chắc, lọc theo cổng proxy trước để xem kết nối đi bằng giao thức nào.

Tcpdump in gói IPv6 với chữ IP6 ở đầu dòng thay cho IP. Địa chỉ và cổng ngăn cách bằng dấu chấm như IPv4, nên địa chỉ IPv6 dài sẽ khó đọc hơn. Đây cũng là ca hay gặp khi proxy chỉ cho phép IPv4 mà máy client ưu tiên IPv6.

Nhận ra RST giữa chừng

RST xuất hiện sau khi đã truyền dữ liệu nghĩa là một bên hủy kết nối đột ngột. Nếu RST đến từ phía proxy ngay sau gói TLS đầu tiên của client, thường là proxy hoặc thiết bị trên đường chặn theo tên miền trong SNI. Nếu RST đến sau một lúc truyền, có thể là proxy hết thời gian chờ hoặc giới hạn kết nối.

Xử lý theo bằng chứng, giới hạn suy luận và checklist khi tcpdump kiểm tra kết nối proxy

Checklist tcpdump

Khi đã đọc được gói, cách xử lý đi theo mẫu thấy được. Phần này gom các bước xử lý và lưu ý an toàn khi bắt gói trên máy thật.

Xử lý theo mẫu gói

Thấy [S], [R.]: kiểm cổng proxy trong cấu hình ứng dụng, kiểm dịch vụ proxy còn chạy. Với proxy thương mại, đối chiếu cổng với trang quản lý. Bài định dạng proxy giúp tách đúng địa chỉ và cổng từ chuỗi nhà cung cấp gửi.

Thấy SYN lặp lại: kiểm tường lửa chiều ra trên máy client, kiểm proxy có giới hạn IP được phép kết nối không. Nhiều proxy chỉ cho IP đã đăng ký, IP lạ bị bỏ gói thay vì trả RST, nên ứng dụng thấy timeout.

Thấy 407 trong gói: sửa thông tin xác thực, chú ý ký tự đặc biệt trong mật khẩu cần mã hóa khi đặt vào URL. Bài sửa lỗi 407 có chi tiết.

Không thấy gói nào: quay lại phần cấu hình ứng dụng và DNS, không cần nhìn mạng nữa.

Đặt timeout trong ứng dụng

Số đo lab cho thấy không đặt timeout thì thời gian treo do hệ điều hành quyết định, 21 giây trên Windows và có thể hơn hai phút trên Linux. Crawler nên đặt timeout kết nối ngắn, ví dụ 5 tới 10 giây, tách với timeout đọc dài hơn.

Với requests, truyền timeout dạng cặp số: số đầu cho kết nối, số sau cho đọc. Với curl, dùng --connect-timeout. Khi timeout kết nối ngắn, crawler chuyển sang proxy khác nhanh thay vì chờ SYN retry hết lượt.

Bắt gói chờ lỗi chập chờn

Lỗi chỉ xảy ra vài lần mỗi giờ khó bắt bằng tay. Cách làm là để tcpdump chạy nền với bộ lọc chặt, cắt tệp theo giờ bằng -G, giữ số tệp giới hạn bằng -W. Khi ứng dụng ghi lỗi, ghi lại thời điểm, rồi mở đúng tệp của giờ đó.

Bộ lọc chỉ lấy cờ SYN, RST và FIN giữ tệp nhỏ dù chạy nhiều ngày. Phần lớn lỗi kết nối chỉ cần các gói này. Khi cần nội dung phản hồi của proxy, chạy thêm một lần bắt ngắn có -A trong khung giờ hay lỗi.

An toàn khi bắt gói

Tệp pcap có thể chứa mật khẩu proxy, cookie và nội dung request HTTP thường. Giữ tệp trong thư mục chỉ chủ máy đọc được, xóa sau khi chẩn đoán xong, không gửi qua kênh chat công khai.

Dùng -s nhỏ khi chỉ cần tiêu đề. Dùng -Z để tcpdump bỏ quyền root sau khi mở giao diện. Chỉ bắt trên máy và mạng anh em được phép quản lý.

Gửi bằng chứng cho nhà cung cấp proxy

Khi lỗi nằm phía proxy thương mại, một đoạn đầu ra tcpdump ngắn có giá trị hơn nhiều so với câu "proxy không chạy". Gửi kèm thời điểm theo múi giờ rõ ràng, địa chỉ IP thoát của máy client, địa chỉ và cổng proxy, cùng mẫu gói thấy được như SYN lặp hay RST.

Trước khi gửi, cắt bỏ mọi gói có nội dung, chỉ giữ dòng tiêu đề. Không gửi tệp pcap đầy đủ vì có thể chứa header xác thực. Đầu ra dạng chữ của lệnh tcpdump -nn -r với bộ lọc cờ SYN và RST thường là đủ để bộ phận kỹ thuật đối chiếu với log phía họ.

Nếu nhà cung cấp xác nhận không thấy kết nối tới từ IP của anh em trong cùng khoảng thời gian, gói bị chặn ở đâu đó trên đường. Thủ phạm có thể là tường lửa của nhà mạng hoặc mạng nội bộ.

Giới hạn suy luận của bài

ProxyVN không bắt được gói thật trong bài vì máy lab không có quyền quản trị. Thời gian ba ca là số đo thật trên Windows 10. Các dòng tcpdump là mẫu dựng theo định dạng trang man và thời gian đo được, chưa đối chiếu với bản bắt thật. Phần Linux lấy theo tài liệu nhân ngày 29/10/2026.

Khoảng thử lại SYN trên Windows có thể khác giữa các phiên bản và bị chỉnh qua registry. Con số 21 giây chỉ đúng cho máy lab.

Checklist tcpdump kiểm tra kết nối proxy

• Phân giải tên proxy ra địa chỉ IP trước khi lọc.
• Dùng -nn để tránh nhiễu DNS trong đầu ra.
• Lọc theo host và port của proxy.
• Ghi ra tệp với -w, giới hạn -c và -s.
• Lọc cờ SYN và RST khi tải lớn.
• Đặt đầu ra cạnh log ứng dụng theo thời điểm.
• Xác định mẫu: thành công, RST, SYN lặp hay không có gói.
• Xóa tệp pcap sau khi xong.

Khi cần một proxy ổn định để so sánh với proxy đang lỗi, ProxyVN có proxy dân cư tĩnh, datacenter, 4G và proxy xoay qua HTTP hoặc SOCKS5. Anh em có thể mua proxy Việt Nam tại trang chủ ProxyVN rồi bắt gói cả hai để thấy khác biệt ở bước nào.

Câu hỏi thường gặp về tcpdump kiểm tra kết nối proxy

Có cần quyền root để chạy tcpdump không?

Cần quyền bắt gói, thường là root hoặc quyền CAP_NET_RAW. Đọc tệp pcap đã có bằng -r thì không cần.

Proxy SOCKS5 có đọc được bằng tcpdump không?

Được ở mức gói. Bắt tay SOCKS5 là dữ liệu nhị phân ngắn, không phải văn bản như HTTP. Dùng -X để in dạng hex, hoặc chép tệp về Wireshark để giải mã giao thức SOCKS.

Bắt bao lâu là đủ?

Với lỗi xảy ra mỗi request, vài giây là đủ. Với lỗi chập chờn, để chạy cho tới khi lỗi xảy ra ít nhất hai lần, để so được hai lần lỗi với nhau và với các lần thành công.

Tcpdump có làm chậm proxy không?

Bắt gói tốn CPU và đĩa, nhất là khi tải cao và không giới hạn kích thước. Lọc chặt và đặt -s nhỏ giúp giảm ảnh hưởng.

Có thấy được URL HTTPS qua proxy không?

Chỉ thấy tên miền trong lệnh CONNECT và trong SNI. Đường dẫn và nội dung đã mã hóa.

Chạy tcpdump trong container được không?

Được nếu container có quyền bắt gói. Nhiều khi tiện hơn là bắt trên máy chủ, lọc theo địa chỉ của container.

Tcpdump kiểm tra kết nối proxy và những điều cần nhớ

Tcpdump kiểm tra kết nối proxy cho biết gói có đi và có về hay không ở từng bước. Lab đo thật: proxy sống trả 200 tức thì, cổng đóng bị từ chối sau 2 giây, địa chỉ chết treo 21 giây trên Windows. Lọc theo host, port và cờ SYN, đặt cạnh log ứng dụng, rồi xử lý theo mẫu gói. Cần proxy ổn định để đối chứng khi dùng tcpdump kiểm tra kết nối proxy, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.