Conntrack khi vận hành proxy: đọc bảng, giới hạn và NAT

Conntrack khi vận hành proxy là phần ít người nhìn tới cho đến khi gateway Linux bắt đầu rớt gói mà proxy vẫn báo chạy bình thường. Bảng theo dõi kết nối của kernel giữ một dòng cho mỗi luồng đi qua máy, kể cả luồng đã đóng. ProxyVN dựng bộ dữ liệu 2.000 entry theo đúng định dạng conntrack -L, đọc lại bằng script và tính sức chứa của bảng để anh em biết khi nào cần lo và cần chỉnh chỗ nào.

Conntrack khi vận hành proxy: lớp nào quyết định hành vi

Câu hỏi đầu tiên là bảng conntrack nằm ở đâu trong đường đi của một request qua proxy. Nhiều người nhìn số kết nối trong log Squid hay HAProxy rồi kết luận máy còn rảnh. Số đó chỉ là phiên ở tầng ứng dụng, còn kernel đếm theo cách khác.

Bảng conntrack là gì

Netfilter, phần lọc gói của nhân Linux, có một mô-đun tên nf_conntrack. Mô-đun này ghi lại mỗi luồng mạng đi qua máy dưới dạng một bộ địa chỉ nguồn, địa chỉ đích, cổng nguồn, cổng đích và giao thức. Mỗi luồng có một dòng, gọi là entry.

Mỗi entry lưu hai chiều: chiều gốc và chiều trả lời. Chiều gốc là gói đầu tiên đi ra, chiều trả lời là gói phản hồi mà kernel đang chờ. Khi máy làm NAT, hai chiều này khác nhau, và chính sự khác nhau đó cho biết kernel đã đổi địa chỉ thế nào.

Entry có đồng hồ đếm ngược. Hết thời gian mà không có gói mới, kernel xóa entry. Thời gian này phụ thuộc giao thức và trạng thái, ví dụ luồng TCP đã thiết lập được giữ rất lâu, còn luồng UDP chỉ vài chục giây.

Ba vị trí hay gặp trong hệ thống proxy

Vị trí thứ nhất là máy chạy proxy forward như Squid, Tinyproxy hay 3proxy. Mỗi client kết nối vào tạo một entry, mỗi kết nối proxy mở ra trang đích tạo thêm một entry. Một request qua proxy vì vậy để lại ít nhất hai dòng trong bảng của máy proxy.

Vị trí thứ hai là gateway làm SNAT cho cả cụm crawler, thường gặp ở nút Kubernetes hoặc máy NAT trước dải máy ảo. Mọi pod đi ra ngoài đều phải qua bảng này. Đây là chỗ bảng đầy nhanh nhất, vì nó gánh kết nối của hàng chục tiến trình cùng lúc.

Vị trí thứ ba là router gia đình hoặc router văn phòng. Router cũng chạy Linux và cũng có conntrack, chỉ là bảng nhỏ hơn nhiều. Bài proxy Apple TV có nhắc lệnh conntrack -L để xem kết nối trên router, còn bài này đi vào chuyện sức chứa và vòng đời của bảng.

Vì sao số phiên ứng dụng khác số entry

Squid đếm phiên đang mở. Kernel đếm luồng chưa hết hạn. Khi một kết nối TCP đóng, Squid quên nó ngay, nhưng kernel vẫn giữ entry ở trạng thái TIME_WAIT thêm 120 giây theo mặc định.

Một proxy chỉ có 50 phiên đang mở vẫn có thể giữ hàng chục nghìn entry trong bảng. Lý do là các kết nối ngắn đã đóng nhưng chưa hết hạn. Nếu chỉ nhìn bảng điều khiển của proxy, anh em sẽ không thấy gì bất thường cho tới khi kernel bắt đầu bỏ gói.

Ranh giới với các bài đã có

Bài CGNAT giải thích NAT phía nhà mạng. Bài NAT type nói về loại NAT trong game và gọi thoại. Bài này chỉ xét bảng conntrack trên máy Linux anh em tự quản: proxy tự dựng, gateway của cụm crawler và cách đọc số liệu của nó.

Đọc bảng conntrack khi vận hành proxy: giới hạn bảng và mapping NAT

Đọc một dòng conntrack -L

Phần này đi qua ba thứ cần đọc được trước khi chẩn đoán: một dòng conntrack -L nói gì, các tham số sysctl nào giới hạn bảng, và dấu hiệu nào cho thấy bảng đã đầy. Số mặc định lấy theo tài liệu sysctl nf_conntrack của nhân Linux, đọc ngày 29/10/2026.

Giải nghĩa một dòng conntrack -L

Dưới đây là một dòng trong bộ dữ liệu lab. Địa chỉ dùng dải dành cho tài liệu theo RFC 5737, không phải máy thật.

tcp      6 44 TIME_WAIT src=10.20.0.33 dst=203.0.113.50 sport=59897 dport=8080 src=203.0.113.50 dst=198.51.100.7 sport=8080 dport=20001 [ASSURED] mark=0 use=1

Cột đầu là giao thức, số 6 là mã giao thức TCP. Số 44 là số giây còn lại trước khi entry bị xóa. TIME_WAIT là trạng thái TCP mà conntrack đang theo dõi.

Bộ src, dst, sport, dport đầu tiên là chiều gốc: pod 10.20.0.33 mở kết nối từ cổng 59897 tới proxy 203.0.113.50 cổng 8080. Bộ thứ hai là chiều trả lời: proxy trả về địa chỉ 198.51.100.7 cổng 20001. Địa chỉ đích ở chiều trả lời khác địa chỉ nguồn ở chiều gốc, nghĩa là gateway đã làm SNAT.

Cờ ASSURED cho biết luồng đã có lưu lượng hai chiều, kernel ưu tiên giữ entry này khi bảng chật. Cờ UNREPLIED thì ngược lại, nghĩa là gói đi ra chưa nhận được trả lời. Nhiều UNREPLIED tới cùng một đích thường là đích không phản hồi hoặc bị chặn.

Đọc mapping NAT từ hai chiều của entry

Với gateway SNAT, cặp dport ở chiều trả lời chính là cổng mà gateway cấp cho luồng đó trên địa chỉ công khai. Trong ví dụ, cổng 20001 trên 198.51.100.7 đại diện cho cổng 59897 của pod 10.20.0.33. Khi gói trả lời tới cổng 20001, kernel tra bảng để biết phải chuyển về pod nào.

Điều này có hệ quả thực tế. Mỗi bộ địa chỉ đích, cổng đích và giao thức chỉ dùng được một lượng cổng nguồn có hạn trên một địa chỉ công khai. Nếu cả cụm crawler cùng đi tới một proxy duy nhất, mọi entry dùng chung đích, nên số cổng SNAT khả dụng trở thành giới hạn thứ hai bên cạnh kích thước bảng.

Lệnh conntrack có bộ lọc riêng cho NAT. Theo trang man conntrack(8), tùy chọn -n lọc entry có SNAT, -g lọc DNAT và -j lọc cả hai. Kết hợp với -p tcp và --dport 8080 là ra đúng các luồng đi tới cổng proxy.

Các tham số giới hạn bảng

Bảng: Các tham số giới hạn bảng

Tham số sysctl	Mặc định theo tài liệu	Ý nghĩa
nf_conntrack_max	Bằng nf_conntrack_buckets	Số entry tối đa
nf_conntrack_count	Chỉ đọc	Số entry hiện có
nf_conntrack_buckets	Bộ nhớ chia 16384, từ 1024 tới 262144	Kích thước bảng băm
nf_conntrack_tcp_timeout_established	432000 giây (5 ngày)	Luồng TCP đã thiết lập
nf_conntrack_tcp_timeout_time_wait	120 giây	Luồng TCP đã đóng
nf_conntrack_tcp_timeout_fin_wait	120 giây	Đang đóng
nf_conntrack_udp_timeout	30 giây	UDP một chiều
nf_conntrack_udp_timeout_stream	120 giây	UDP đã có hai chiều

Đường dẫn đầy đủ trên máy là /proc/sys/net/netfilter/ cộng tên tham số. Hai số đầu là cặp cần theo dõi thường xuyên nhất: count chia max cho biết bảng đang đầy bao nhiêu phần trăm.

Tài liệu nhân ghi thêm một chi tiết hay bị bỏ qua. Mỗi entry được thêm vào bảng băm hai lần, một lần cho chiều gốc và một lần cho chiều trả lời. Vì vậy khi nf_conntrack_max bằng số bucket, bảng đầy sẽ có chuỗi băm trung bình dài 2, không phải 1.

Dấu hiệu bảng đã đầy

Khi count chạm max, kernel không tạo được entry mới. Gói mở kết nối mới bị bỏ, và dmesg in dòng có chữ "nf_conntrack: table full, dropping packet". Trước khi bỏ, kernel thử xóa sớm một entry chưa có cờ ASSURED để lấy chỗ.

Từ phía ứng dụng, dấu hiệu là kết nối mới bị treo ở bước bắt tay rồi hết thời gian chờ, trong khi kết nối cũ vẫn chạy. Crawler báo timeout rải rác, tỷ lệ lỗi tăng theo tải chứ không theo trang đích. Proxy vẫn sống, ping vẫn được, nên rất dễ đổ lỗi sai cho proxy hoặc trang đích.

Lệnh conntrack -S in thống kê theo từng CPU, trong đó các trường drop, early_drop và insert_failed là thứ cần nhìn. Drop tăng dần theo thời gian là bằng chứng rõ nhất cho chuyện bảng đầy.

Thiết kế lab conntrack khi vận hành proxy: dữ liệu, phiên bản và phép đo

Máy dựng bài là Windows 10, không có nhân Linux và không có quyền tạo network namespace. ProxyVN vì vậy không đo trên kernel thật. Phần lab là một bộ dữ liệu theo đúng định dạng đầu ra conntrack -L, cộng script đọc lại và mô hình tính trạng thái ổn định.

Vì sao dùng bộ dữ liệu thay cho kernel thật

Định dạng dòng lấy theo hướng dẫn sử dụng conntrack-tools và trang man. Kịch bản giả lập một gateway SNAT địa chỉ 198.51.100.7, phía sau có 31 pod trong dải 10.20.0.10 tới 10.20.0.40, tất cả đi tới một proxy 203.0.113.50 cổng 8080.

Cách làm này có giới hạn rõ ràng. Nó kiểm được parser, cách đếm và phép tính sức chứa. Nó không kiểm được hành vi thật của kernel như lúc nào bỏ gói hay lúc nào xóa sớm. Phần nào là hành vi kernel, bài ghi rõ là lấy theo tài liệu.

Phân bố trạng thái trong bộ dữ liệu

Bộ dữ liệu có 2.000 entry gồm 1.800 luồng TCP tới proxy và 200 luồng UDP tới máy DNS 192.0.2.53 cổng 53. Tỷ lệ trạng thái TCP được chọn để giống một crawler mở kết nối mới cho mỗi request: phần lớn là TIME_WAIT.

Seed ngẫu nhiên cố định là 263, nên chạy lại script sẽ ra đúng bộ dữ liệu cũ. Thời gian còn lại của mỗi entry nằm trong khoảng mặc định của trạng thái đó: ESTABLISHED tới 432.000 giây, TIME_WAIT tới 120 giây, UDP tới 30 giây.

Phép đo và kết quả kỳ vọng

Script đo năm thứ: số entry theo trạng thái, số entry theo đích, ba pod tạo nhiều entry nhất, số entry có SNAT và số entry UNREPLIED. Sau đó nó so tổng số entry với một giới hạn giả định 2.048 để mô phỏng ca bảng nhỏ trên router hoặc máy ảo ít RAM.

Kết quả kỳ vọng trước khi chạy: TIME_WAIT chiếm khoảng 70% luồng TCP, mọi entry đều có SNAT vì đều đi qua gateway, và bảng 2.048 gần đầy. Nếu kết quả lệch, nghĩa là parser đọc sai cột.

Phiên bản công cụ

Script chạy bằng Python 3.12.10 trên Windows 10, chỉ dùng thư viện chuẩn. Phần mô hình sức chứa là công thức đơn giản: số entry ổn định bằng tốc độ mở kết nối mới nhân với tổng thời gian một luồng nằm trong bảng.

Tái lập conntrack khi vận hành proxy: luồng bình thường và ca bảng đầy

Bảng đầy 97,7%

Phần này chạy script trên bộ dữ liệu, đọc kết quả, rồi đặt nó vào ca giới hạn có kiểm soát để thấy bảng đầy nhanh tới mức nào.

Script đọc đầu ra conntrack -L

import re, collections
KV = re.compile(r"(\w+)=([^\s]+)")
 
def parse(line):
    p = line.split()
    proto = p[0]
    state = p[3] if proto == "tcp" else ""
    kv = KV.findall(line)
    orig, reply = dict(kv[:4]), dict(kv[4:8])
    return {"proto": proto, "timeout": int(p[2]), "state": state,
            "orig": orig, "reply": reply,
            "unreplied": "[UNREPLIED]" in line,
            "snat": reply.get("dst") != orig.get("src")}
 
E = [parse(l) for l in open("ct.txt") if l.strip()]
print(collections.Counter(e["state"] or e["proto"] for e in E))
print(collections.Counter(e["orig"]["src"] for e in E).most_common(3))
print("SNAT:", sum(e["snat"] for e in E), "UNREPLIED:", sum(e["unreplied"] for e in E))

Trên máy Linux thật, anh em lấy tệp đầu vào bằng lệnh conntrack -L cộng chuyển hướng ra tệp, chạy với quyền root. Script chỉ đọc tệp, không gọi kernel, nên chạy được trên máy khác sau khi chép tệp về.

Cách xác định SNAT trong script dựa đúng vào nhận xét ở trên: nếu địa chỉ đích ở chiều trả lời khác địa chỉ nguồn ở chiều gốc thì kernel đã đổi địa chỉ. Cách này không phân biệt SNAT với masquerade, vì cả hai đều đổi nguồn.

Kết quả trên 2.000 entry

Bảng: Kết quả trên 2.000 entry

Chỉ số	Giá trị
Tổng entry	2.000
TIME_WAIT	1.265
ESTABLISHED	356
SYN_SENT	91
CLOSE_WAIT	48
FIN_WAIT	40
UDP tới DNS	200
Entry có SNAT	2.000
Entry UNREPLIED	91
Tỷ lệ TIME_WAIT trong TCP	70,3%
Mức đầy nếu max là 2.048	97,7%

Đích 203.0.113.50 cổng 8080 chiếm 1.800 entry, máy DNS chiếm 200. Ba pod tạo nhiều entry nhất là 10.20.0.28 với 74 entry, 10.20.0.39 và 10.20.0.36 cùng 69 entry.

Số UNREPLIED khớp đúng số SYN_SENT là 91, vì trong bộ dữ liệu chỉ luồng chưa được trả lời mới mang cờ này. Trên máy thật, nếu UNREPLIED tăng nhanh tới cùng một địa chỉ proxy, nên kiểm proxy đó còn nhận kết nối hay không trước khi nghĩ tới bảng.

Ca giới hạn có kiểm soát

Giả sử bảng chỉ cho 2.048 entry, mức thường gặp trên router nhỏ hoặc máy ảo rất ít bộ nhớ. Bộ dữ liệu 2.000 entry đã chiếm 97,7%. Chỉ cần thêm 48 kết nối mới trong cùng khoảng thời gian, kernel sẽ phải xóa sớm hoặc bỏ gói.

Điều đáng chú ý là 1.265 trong số đó là luồng đã đóng. Crawler không còn dùng chúng, proxy không còn thấy chúng, nhưng chúng vẫn giữ chỗ thêm tối đa 120 giây. Nếu chỉ nhìn số kết nối đang mở là 356, anh em sẽ nghĩ bảng còn trống hơn 80%.

Mô hình trạng thái ổn định

Khi tải đều, số entry gần bằng tốc độ mở kết nối mới nhân với thời gian một luồng sống trong bảng. Thời gian sống gồm phần luồng đang dùng và phần nằm chờ ở TIME_WAIT.

Bảng: Mô hình trạng thái ổn định

Kịch bản	Tốc độ mở mới	Thời gian dùng	TIME_WAIT	Entry ổn định
Mỗi request một kết nối	200/giây	2 giây	120 giây	24.400
Như trên, hạ TIME_WAIT	200/giây	2 giây	30 giây	6.400
Giữ kết nối, mở lại ít	5/giây	60 giây	120 giây	900

Ba dòng cho thấy hai đòn bẩy. Hạ thời gian TIME_WAIT trong conntrack giảm bảng gần bốn lần. Giữ kết nối để mở mới ít đi giảm bảng hơn hai mươi lần. Đòn bẩy thứ hai nằm ở mã crawler, không cần đụng kernel.

Mô hình này bỏ qua entry UDP, entry DNS và kết nối phía proxy mở ra trang đích. Trên máy chạy proxy, mỗi request còn tạo thêm entry chiều ra, nên con số thật thường gấp đôi.

Đọc log, gói tin và response để tách lỗi conntrack khi vận hành proxy

Tách lỗi trước và sau proxy

Lỗi bảng đầy dễ lẫn với ba lỗi khác có triệu chứng giống: proxy hết luồng xử lý, cạn cổng nguồn và trang đích chặn. Phần này xếp các dấu hiệu cạnh nhau để anh em loại trừ từng thứ.

Lệnh cần chạy trên máy Linux

cat /proc/sys/net/netfilter/nf_conntrack_count
cat /proc/sys/net/netfilter/nf_conntrack_max
conntrack -S
conntrack -L -p tcp --dport 8080 2>/dev/null | awk '{print $4}' | sort | uniq -c
conntrack -L -n 2>/dev/null | wc -l
dmesg -T | grep -i conntrack | tail

Hai lệnh cat cho tỷ lệ đầy. Lệnh -S cho bộ đếm drop và early_drop. Lệnh -L có lọc cổng 8080 đếm theo trạng thái, giống bảng kết quả lab. Lệnh -L -n đếm entry có SNAT. Dòng dmesg cho biết kernel đã từng bỏ gói hay chưa.

Các lệnh này chưa được ProxyVN chạy trên kernel thật trong bài. Cú pháp lấy theo trang man conntrack(8), đầu ra mẫu là bộ dữ liệu lab.

Bảng phân biệt nguyên nhân

Bảng: Bảng phân biệt nguyên nhân

Dấu hiệu	Bảng conntrack đầy	Proxy hết luồng	Cạn cổng nguồn	Trang đích chặn
dmesg có "table full"	Có	Không	Không	Không
conntrack -S drop tăng	Có	Không	Không	Không
Lỗi khi mở kết nối mới	Timeout ở bước bắt tay	Kết nối được nhưng chờ lâu	Lỗi địa chỉ không khả dụng	Kết nối được, nhận 403 hoặc 429
Ảnh hưởng	Mọi đích qua máy đó	Mọi request qua proxy	Chỉ một cặp nguồn và đích	Chỉ một trang
Log proxy	Không thấy request mới	Thấy request xếp hàng	Không thấy request	Thấy mã lỗi từ đích

Dòng cuối là cách nhanh nhất để khoanh vùng. Nếu request không tới được proxy, lỗi nằm trước proxy. Nếu request tới proxy mà proxy không mở được ra ngoài, lỗi nằm trên máy proxy. Nếu proxy mở được và nhận mã lỗi, vấn đề ở phía trang đích.

Gói tin cho thấy gì

Chạy tcpdump trên gateway khi bảng đầy, anh em sẽ thấy gói SYN từ pod đi vào nhưng không thấy gói SYN tương ứng đi ra phía ngoài. Gói bị bỏ ngay ở netfilter, trước khi tới bước NAT. Client gửi lại SYN theo chu kỳ của nó rồi hết thời gian chờ.

Ngược lại, nếu thấy SYN đi ra nhưng không có SYN-ACK quay về, lỗi nằm ngoài gateway: proxy chết, tường lửa phía proxy chặn hoặc đường truyền có vấn đề. Entry trường hợp này mang cờ UNREPLIED, đúng như 91 entry SYN_SENT trong lab.

Response từ proxy và từ trang đích

Bảng conntrack đầy không bao giờ sinh ra mã HTTP. Nếu crawler nhận được 502, 503 hay 504, kết nối tới proxy đã thành công và lỗi nằm ở bước sau. Bài lỗi 504 Gateway Timeout và 502 Bad Gateway giải thích các mã đó.

Khi đã có mã HTTP, anh em không cần nhìn conntrack nữa. Conntrack chỉ là nghi phạm khi lỗi xảy ra trước cả lúc có response, tức là ở mức timeout kết nối hoặc kết nối bị từ chối.

Xử lý conntrack khi vận hành proxy theo bằng chứng và checklist

Checklist conntrack

Khi đã có bằng chứng bảng đầy, có ba nhóm cách xử lý: giảm số entry tạo ra, giảm thời gian mỗi entry nằm trong bảng và tăng sức chứa. Thứ tự này có chủ ý, vì tăng sức chứa là cách dễ làm nhất nhưng chỉ đẩy giới hạn ra xa.

Giảm số kết nối mới từ phía crawler

Đây là đòn bẩy lớn nhất trong mô hình. Crawler dùng requests nên tạo một Session và dùng lại cho mọi request tới cùng proxy. Với aiohttp, dùng một ClientSession cho cả lô thay vì tạo mới mỗi lần.

Bài 1 proxy chạy được bao nhiêu luồng bàn về số luồng hợp lý cho một proxy. Từ góc nhìn conntrack, mười luồng giữ kết nối lâu nhẹ hơn nhiều so với hai luồng mở kết nối mới mỗi giây.

Phía proxy cũng nên giữ kết nối với trang đích. Squid, HAProxy và Nginx đều có tùy chọn giữ kết nối ra ngoài, giúp giảm entry chiều ra trên máy proxy.

Giảm thời gian TIME_WAIT trong conntrack

Tham số nf_conntrack_tcp_timeout_time_wait mặc định 120 giây. Hạ xuống 30 giây làm bảng nhỏ đi khoảng bốn lần trong kịch bản mỗi request một kết nối.

sysctl -w net.netfilter.nf_conntrack_tcp_timeout_time_wait=30
echo "net.netfilter.nf_conntrack_tcp_timeout_time_wait = 30" > /etc/sysctl.d/90-conntrack.conf

Cần phân biệt tham số này với trạng thái TIME_WAIT của socket. Hạ thời gian trong conntrack không làm socket trên máy đóng nhanh hơn. Nó chỉ làm kernel quên luồng sớm hơn, nên nếu có gói trễ của luồng cũ tới sau đó, gói sẽ được coi là luồng mới hoặc không hợp lệ.

Nhiều hướng dẫn trên mạng còn đề nghị hạ nf_conntrack_tcp_timeout_established từ 5 ngày xuống vài giờ. Cách này giải phóng entry của kết nối bị bỏ rơi, nhưng cũng có thể cắt kết nối dài đang rảnh như WebSocket hay kết nối giữ lâu tới proxy. Hãy đo trước rồi mới hạ.

Tăng sức chứa bảng

sysctl -w net.netfilter.nf_conntrack_max=262144
echo 65536 > /sys/module/nf_conntrack/parameters/hashsize

Khi tăng max, nên tăng số bucket theo để giữ chuỗi băm ngắn. Tài liệu ghi nf_conntrack_buckets chỉ ghi được ở network namespace ban đầu, nên trong container anh em có thể đọc được nhưng không đổi được. Với Kubernetes, kube-proxy cũng đặt giá trị này theo số nhân CPU khi khởi động.

Mỗi entry tốn bộ nhớ kernel. Tăng max lên rất cao trên máy ít RAM có thể đổi lỗi bỏ gói thành lỗi thiếu bộ nhớ. Con số an toàn phụ thuộc máy, nên tăng từng bậc và theo dõi bộ nhớ slab.

Bỏ theo dõi cho luồng không cần NAT

Luồng không cần NAT và không cần tường lửa có trạng thái có thể bỏ qua conntrack bằng quy tắc notrack trong bảng raw. Cách này hay dùng cho DNS cục bộ hoặc lưu lượng nội bộ khối lượng lớn. Với luồng đi qua SNAT tới proxy thì không bỏ được, vì NAT cần entry để biết đường trả về.

Đưa số liệu conntrack vào giám sát

Chạy lệnh tay chỉ hữu ích khi đã có sự cố. Để thấy bảng đầy dần trước khi bỏ gói, cần ghi count và max theo thời gian. Node exporter của Prometheus có bộ thu conntrack đọc hai tệp này và xuất ra hai chỉ số node_nf_conntrack_entries và node_nf_conntrack_entries_limit.

Bài giám sát proxy bằng Prometheus và Grafana hướng dẫn dựng bảng điều khiển cho proxy. Anh em chỉ cần thêm một biểu đồ tỷ lệ entries chia limit và một cảnh báo khi tỷ lệ vượt 0,8 trong năm phút liên tục. Ngưỡng 80% để lại đủ chỗ cho đợt tải đột ngột.

Bộ đếm drop không có trong bộ thu mặc định của mọi phiên bản exporter. Nếu thiếu, một script nhỏ chạy conntrack -S mỗi phút, cộng trường drop của các CPU rồi ghi ra tệp văn bản cho bộ thu textfile là đủ. Biểu đồ drop nên nằm ngay dưới biểu đồ tỷ lệ đầy, vì hai đường này đi cùng nhau.

Khi cần biết tiến trình nào tạo nhiều kết nối, lệnh conntrack -E -e NEW in sự kiện tạo entry theo thời gian thực. Chạy trong một phút rồi đếm theo địa chỉ nguồn là ra danh sách pod hay máy mở kết nối nhiều nhất, giống bảng ba pod đứng đầu trong lab. Lệnh này tốn CPU khi tải cao, chỉ nên chạy ngắn.

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

ProxyVN không chạy kernel Linux thật trong bài này. Số đếm theo trạng thái là của bộ dữ liệu có chủ đích, không phải của một gateway đang chạy. Hành vi bỏ gói, xóa sớm và giá trị mặc định lấy theo tài liệu nhân ngày 29/10/2026, các bản kernel khác nhau và bản phân phối khác nhau có thể đặt mặc định khác.

Mô hình trạng thái ổn định giả định tải đều. Tải theo đợt sẽ tạo đỉnh cao hơn trung bình. Khi lập kế hoạch sức chứa, nên lấy tốc độ mở mới ở giờ cao điểm chứ không lấy trung bình ngày.

Checklist conntrack khi vận hành proxy

• Đo count và max mỗi phút, cảnh báo khi vượt 80%.
• Theo dõi bộ đếm drop và early_drop trong conntrack -S.
• Đếm entry theo trạng thái, nếu TIME_WAIT trên 60% thì xem lại việc giữ kết nối.
• Đếm entry theo pod hoặc theo máy nguồn để tìm tiến trình mở kết nối nhiều nhất.
• Giữ kết nối ở crawler và ở proxy trước khi chỉnh kernel.
• Nếu hạ timeout, ghi lại giá trị cũ và lý do vào tệp sysctl.d.
• Tăng max kèm tăng bucket, theo dõi bộ nhớ sau khi tăng.
• Đọc dmesg sau mỗi đợt crawl lớn.

Nếu đang chọn proxy cho cụm crawler chạy trên gateway Linux, nên ưu tiên gói cho phép giữ kết nối lâu và ổn định IP để crawler dùng lại được. ProxyVN có proxy dân cư tĩnh, datacenter, 4G và proxy xoay qua HTTP hoặc SOCKS5; anh em có thể mua proxy tại trang chủ ProxyVN rồi đo lại số entry trước và sau khi đổi cách giữ kết nối.

Câu hỏi thường gặp về conntrack khi vận hành proxy

Máy chạy proxy không bật NAT thì có conntrack không?

Có, nếu mô-đun nf_conntrack được nạp. Mô-đun thường được nạp khi máy có quy tắc tường lửa theo trạng thái, khi Docker hoặc Kubernetes chạy, hoặc khi có quy tắc NAT bất kỳ. Kiểm bằng cách xem tệp nf_conntrack_count có tồn tại không.

Proxy SOCKS5 có tạo entry khác proxy HTTP không?

Không khác về bản chất. Cả hai đều là kết nối TCP từ client tới proxy và từ proxy ra đích. Riêng SOCKS5 có lệnh UDP ASSOCIATE, nếu dùng thì sinh thêm entry UDP.

Hạ TIME_WAIT trong conntrack có gây lỗi không?

Rủi ro chính là gói trễ của luồng cũ bị hiểu sai. Với crawler gọi HTTP qua proxy, rủi ro này thấp. Với giao thức nhạy cảm thứ tự gói, cần thử trên môi trường phụ trước.

Vì sao conntrack -L chạy rất chậm trên máy bận?

Lệnh phải đọc toàn bộ bảng qua netlink. Bảng vài trăm nghìn entry có thể mất nhiều giây và tốn CPU. Khi chỉ cần con số, dùng conntrack -C hoặc đọc nf_conntrack_count.

Xóa entry bằng conntrack -D có an toàn không?

Xóa entry của luồng đang chạy làm luồng đó mất đường trả về qua NAT. Lệnh -F xóa toàn bộ bảng còn nguy hiểm hơn. Chỉ dùng khi đã biết chính xác luồng nào và chấp nhận cắt nó.

Conntrack khi vận hành proxy và những điều cần nhớ

Conntrack khi vận hành proxy đếm luồng theo vòng đời kernel, không theo số phiên của Squid hay HAProxy. Trong lab, 1.265 trên 1.800 luồng TCP đã đóng mà vẫn giữ chỗ. Đo count và drop trước, giữ kết nối ở crawler, rồi mới hạ timeout hay tăng max. Cần proxy ổn định để crawler giữ kết nối lâu khi theo dõi conntrack khi vận hành proxy, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.