MTU và PMTUD khi dùng proxy: tìm lỗi treo khi gói tin lớn

MTU và PMTUD khi dùng proxy là nhóm lỗi khó chịu nhất trong chẩn đoán mạng, vì mọi thứ trông bình thường cho tới khi dữ liệu lớn lên. Request nhỏ vẫn trả về, nhưng tải tệp hoặc bắt tay TLS thì đứng im. ProxyVN đo thật trên máy lab Windows 10, đọc RFC và dựng một mô hình nhỏ để anh em phân biệt lỗi đường đi MTU với lỗi proxy thông thường.

MTU và PMTUD khi dùng proxy: lớp nào quyết định hành vi

MTU, MSS và vì sao con số 1500 xuất hiện khắp nơi

MTU là kích thước gói IP lớn nhất mà một đoạn mạng chuyển được trong một lần. Ethernet và Wi-Fi gia đình thường dùng 1500 byte. Khi trừ 20 byte tiêu đề IPv4 và 20 byte tiêu đề TCP, phần dữ liệu tối đa của một đoạn TCP còn 1460 byte, gọi là MSS.

Hai máy thỏa thuận MSS lúc mở kết nối, mỗi bên báo con số của mình trong gói SYN. Con số này chỉ phản ánh mạng ngay sát mỗi máy. Nó không biết gì về một đường hầm VPN, một đoạn PPPoE hay một tuyến cáp có MTU nhỏ hơn nằm ở giữa.

MSS chỉ là lời hứa của hai đầu, còn MTU thật của cả đường đi thì phải dò mới biết.

PMTUD hoạt động ra sao

PMTUD là cơ chế dò MTU của cả đường đi, mô tả trong RFC 1191 cho IPv4. Máy gửi đặt cờ DF, nghĩa là không cho router cắt nhỏ gói. Khi gặp một đoạn mạng hẹp hơn, router bỏ gói và gửi lại thông báo ICMP loại 3 mã 4, kèm MTU của chặng kế tiếp.

Máy gửi nhận thông báo đó, ghi MTU mới vào bộ nhớ đệm theo từng địa chỉ đích, rồi gửi lại với gói nhỏ hơn. Với IPv6, RFC 8201 dùng thông báo ICMPv6 Packet Too Big, và router IPv6 không bao giờ tự cắt gói. Cả hai đều dựa vào một điều kiện: thông báo ICMP phải về được tới máy gửi.

Proxy chia kết nối thành hai chặng

Hai chặng qua proxy

Khi đi qua proxy HTTP hoặc SOCKS5, ứng dụng không mở một kết nối TCP xuyên tới website. Nó mở một kết nối tới proxy, rồi proxy mở kết nối thứ hai tới website. Mỗi chặng có MSS riêng, có đường đi riêng và có bộ nhớ đệm MTU riêng.

Kể cả với đường hầm CONNECT cho HTTPS, proxy chỉ chuyển tiếp byte. Proxy đọc dữ liệu từ socket bên này rồi ghi sang socket bên kia, và nhân hệ điều hành của proxy tự đóng gói lại theo MSS của chặng hai. Lỗi MTU có thể nằm ở chặng anh em tới proxy hoặc ở chặng proxy tới website, và cách kiểm hai chặng khác nhau.

Khoanh vùng kết nối treo khi payload lớn với MTU và PMTUD khi dùng proxy

Dấu hiệu đặc trưng của MTU black hole

Gói nhỏ qua, gói lớn kẹt

MTU black hole là tình huống gói lớn bị bỏ ở giữa đường nhưng thông báo ICMP không về tới máy gửi. Nguyên nhân hay gặp là tường lửa chặn toàn bộ ICMP, hoặc một thiết bị không gửi thông báo. Máy gửi không biết phải giảm kích thước nên cứ gửi lại cùng gói lớn đó.

Dấu hiệu của black hole có hình dạng rất riêng. Bước nào chỉ cần gói nhỏ thì chạy, bước nào cần gói đầy MSS thì đứng:

• Mở kết nối TCP tới proxy thành công, vì gói SYN chỉ vài chục byte.
• Proxy trả HTTP/1.1 200 Connection established cho lệnh CONNECT, vì phản hồi này ngắn.
• Bắt tay TLS treo ngay sau Client Hello, vì chứng chỉ của máy chủ thường dài vài KB, phải chia thành các gói đầy 1500 byte.
• Trang API trả JSON nhỏ vẫn chạy, nhưng tải ảnh hoặc tệp lớn dừng ở một con số cố định rồi hết giờ.
• Gửi POST có thân lớn bị treo, còn GET không thân thì chạy.

Request nhỏ chạy, dữ liệu lớn treo, không có thông báo lỗi nào quay về: đó là chữ ký quen thuộc của MTU black hole.

Một lỗi khác hiếm khi cho đúng hình dạng này. Proxy sai mật khẩu trả 407 ngay. Proxy chết thì lỗi ngay từ bước mở kết nối. Website chặn thì trả mã HTTP hoặc cắt kết nối bằng RST.

Vì sao đổi proxy có khi hết lỗi, có khi không

Đổi sang proxy khác nghĩa là đổi chặng hai sang một tuyến khác, và đôi khi đổi cả chặng một. Nếu tuyến cũ có thiết bị chặn ICMP, tuyến mới có thể không có. Anh em sẽ thấy lỗi biến mất nhưng không biết vì sao.

Ngược lại, nếu điểm hẹp nằm ngay trên mạng của anh em, ví dụ một VPN công ty hoặc modem PPPoE, thì đổi proxy nào cũng treo. Không nên hứa đổi proxy sẽ làm mạng nhanh hơn hay sửa được MTU, vì proxy không điều khiển được đường đi trước nó. Phải đo để biết điểm hẹp nằm ở đâu.

Những nguồn làm MTU nhỏ hơn 1500

Đường đi nhỏ hơn 1500 thường do một lớp đóng gói thêm tiêu đề. Mỗi lớp lấy đi vài chục byte của gói:

• PPPoE trên đường cáp quang gia đình tốn 8 byte, MTU thường còn 1492.
• Các VPN như WireGuard, OpenVPN hay IPsec thêm tiêu đề riêng, MTU bên trong đường hầm thường quanh 1400 đến 1420.
• Mạng di động và một số tuyến quốc tế có thể dùng giá trị nhỏ hơn tùy nhà mạng.
• IPv6 có giá trị sàn 1280 byte, mọi đường IPv6 phải chuyển được gói cỡ này.

Bài Cloudflare viết về PMTUD trong thực tế mô tả cách các mạng lớn phải xử lý khi thông báo ICMP bị mất. Bài đó là góc nhìn của nhà vận hành mạng, còn phần dưới là cách kiểm từ máy của anh em.

Thiết kế lab và phép đo cho MTU và PMTUD khi dùng proxy

Máy lab, phiên bản và giới hạn

Lab chạy ngày 29/10/2026 trên Windows 10, card Wi-Fi MTU 1500, Python 3.12.10, curl 8.21.0 bản Git for Windows và curl 8.13.0 có sẵn trong Windows. Máy không có Linux hay WSL nên không dựng được network namespace với MTU khác nhau như brief đề xuất.

Lab gồm hai phần tách bạch. Phần một là phép đo thật trên đường mạng thật: ping có cờ DF, bảng MTU theo đích của Windows và cấu hình TCP. Phần hai là một mô hình tính toán nhỏ để minh họa ba kịch bản, ghi rõ là mô hình, không phải gói tin thật.

Vì sao proxy chạy trên máy lab không tái hiện được lỗi MTU

Nhiều anh em dựng proxy thử trên chính máy mình rồi không thấy lỗi MTU, và kết luận lỗi không có thật. Lệnh sau giải thích lý do:

netsh interface ipv4 show subinterfaces
 
   MTU  MediaSenseState   Bytes In  Bytes Out  Interface
------  ---------------  ---------  ---------  -------------
4294967295                1          0    1909198  Loopback Pseudo-Interface 1
  1500                1  35070713740  16310177885  Wi-Fi

Giao diện loopback có MTU cực lớn, và bảng MTU theo đích ghi 65535 cho 127.0.0.1. Mọi kết nối từ máy tới proxy chạy trên 127.0.0.1 đều không bao giờ chạm giới hạn 1500. Muốn tái hiện lỗi MTU phải có một chặng mạng thật hoặc một máy ảo có giao diện MTU nhỏ, proxy cục bộ không đủ.

Kết quả kỳ vọng trước khi đo

Trước khi chạy, ghi ra kết quả mong đợi để biết phép đo có nói lên điều gì. Với đường Ethernet chuẩn, ping có cờ DF với 1472 byte dữ liệu phải thành công, vì 1472 cộng 8 byte ICMP và 20 byte IP bằng đúng 1500.

Ping 1473 byte phải thất bại. Nếu đường đi hẹp hơn, con số lớn nhất thành công sẽ nhỏ hơn 1472, và hiệu số cho biết lớp đóng gói nào đang lấy bớt byte.

Tái lập luồng thành công và lỗi có kiểm soát của MTU và PMTUD khi dùng proxy

Đo MTU đường đi bằng ping có cờ DF

Đo MTU bằng ping DF

Trên Windows, lệnh ping có tham số -f để đặt cờ DF và -l để chọn số byte dữ liệu. Lab chạy với hai máy chủ DNS công cộng:

ping -n 1 -f -l 1472 1.1.1.1
Reply from 1.1.1.1: bytes=1472 time=47ms TTL=50
 
ping -n 1 -f -l 1473 1.1.1.1
Packet needs to be fragmented but DF set.
 
ping -n 1 -f -l 1472 8.8.8.8
Reply from 8.8.8.8: bytes=1472 time=36ms TTL=113

Một đoạn Python nhỏ chạy tìm kiếm nhị phân từ 1200 tới 1600 cho kết quả 1472 với cả hai đích. Nghĩa là MTU đường đi bằng 1500, không có lớp đóng gói nào ở giữa.

Dòng Packet needs to be fragmented but DF set khi gửi 1473 byte do chính Windows in ra. Gói chưa rời máy, vì card mạng biết MTU của mình là 1500. Nếu điểm hẹp nằm ở router xa hơn, thông báo sẽ đến từ router đó, hoặc không có thông báo nào nếu ICMP bị chặn.

Đoạn mã dò MTU tự động

Đoạn dưới chạy được trên Windows có Python, gọi lệnh ping của hệ thống rồi thu hẹp khoảng tìm kiếm. Thay địa chỉ bằng IP của proxy nếu proxy trả lời ping:

import subprocess, sys
 
def ping_df(host, size):
    out = subprocess.run(["ping", "-n", "1", "-f", "-l", str(size), "-w", "1500", host],
                         capture_output=True, text=True, errors="replace").stdout
    return "bytes=" in out
 
def path_mtu(host, lo=1200, hi=1600):
    while lo < hi:
        mid = (lo + hi + 1) // 2
        if ping_df(host, mid):
            lo = mid
        else:
            hi = mid - 1
    return lo + 28   # 20 byte IPv4 + 8 byte ICMP
 
for h in sys.argv[1:]:
    print(h, "MTU duong di:", path_mtu(h))

Đoạn mã giả định đích có trả lời ping. Nhiều proxy thương mại chặn ICMP echo, khi đó mọi lần ping đều thất bại và hàm trả 1228, một con số vô nghĩa. Gặp trường hợp này thì chuyển sang phép thử bằng dữ liệu HTTP ở phần dưới.

Bảng MTU theo đích của Windows

Windows lưu MTU đã học được cho từng địa chỉ đích. Lệnh sau đọc bảng đó, không cần quyền quản trị:

netsh interface ipv4 show destinationcache
 
PMTU Destination Address      Next Hop Address
---- -----------------------  ----------------
1500 1.1.1.1                  192.168.0.1
1500 8.8.8.8                  192.168.0.1
65535 127.0.0.1               127.0.0.1

Nếu PMTUD từng chạy đúng với IP của proxy, bảng sẽ ghi con số nhỏ hơn 1500 cho IP đó. Nếu bảng vẫn ghi 1500 mà kết nối tới proxy treo khi tải lớn, rất có thể thông báo ICMP chưa từng về. Tài liệu netsh interface liệt kê các lệnh con khác cho IPv4 và IPv6.

Mô hình ba kịch bản: PMTUD chạy, black hole và kẹp MSS

Vì không dựng được namespace, lab dùng một mô hình tính toán rời rạc. Đường đi có MTU 1400, máy gửi bắt đầu với MSS 1460, thời gian chờ gửi lại bắt đầu ở 1 giây và nhân đôi mỗi lần. Mô hình in ra:

pmtud        900B: XONG sau 0.05s
pmtud      65536B: XONG sau 2.50s
    t=0.00s goi 1500B > MTU 1400: router gui ICMP Fragmentation Needed, MTU=1400
blackhole    900B: XONG sau 0.05s
blackhole  65536B: TREO, nhan 0B roi het gio 30s
    t=0.00s goi 1500B bi bo im lang, cho RTO 1s (lan 1)
    t=1.00s goi 1500B bi bo im lang, cho RTO 2s (lan 2)
    t=3.00s goi 1500B bi bo im lang, cho RTO 4s (lan 3)
    t=7.00s goi 1500B bi bo im lang, cho RTO 8s (lan 4)
clamp        900B: XONG sau 0.05s
clamp      65536B: XONG sau 2.45s

Mô hình chỉ minh họa logic, không đo thời gian thật. Điều nó cho thấy là dữ liệu nhỏ hơn MTU chạy ở cả ba kịch bản. Chỉ black hole làm dữ liệu lớn treo, và thời gian chờ tăng theo cấp số nhân nên ứng dụng thường hết giờ trước khi kịp hồi phục.

Đọc log và gói tin để tách MTU và PMTUD khi dùng proxy khỏi lỗi gần giống

Dùng curl -w để chia nhỏ thời gian

curl có tham số -w in các mốc thời gian của một lần chạy, tài liệu ở trang hướng dẫn curl. Với proxy, ba mốc đáng xem là thời điểm nối xong TCP tới proxy, thời điểm xong TLS và số byte đã tải:

curl -s -o NUL -x http://user:pass@203.0.113.10:8080 --max-time 30 ^
  -w "connect=%{time_connect} tls=%{time_appconnect} size=%{size_download} code=%{http_code}\n" ^
  https://example.com/

Thay user, pass và địa chỉ bằng thông tin proxy của anh em, giữ nguyên phần còn lại. Bài định dạng proxy hướng dẫn chuyển từ dạng ip:port:user:pass sang URL cho curl.

Đọc kết quả theo cặp. Nếu connect có số nhỏ mà tls bằng 0 sau khi hết giờ, kết nối treo trong bắt tay TLS. Nếu tls có số mà size dừng ở một con số cố định qua nhiều lần chạy, phần thân bị treo giữa chừng. Cả hai đều khớp hình dạng black hole.

Phép thử nhỏ và lớn trên cùng proxy

Phép thử mạnh nhất là chạy hai request qua cùng một proxy, chỉ khác kích thước dữ liệu. Một request lấy trang vài trăm byte, một request lấy tệp vài trăm KB từ cùng máy chủ. Lặp mỗi request năm lần để loại trừ nghẽn tạm thời.

Kết quả có ba khả năng. Cả hai đều chạy thì MTU không phải vấn đề. Cả hai đều lỗi thì lỗi nằm ở chỗ khác, như tài khoản, chặn IP hay proxy quá tải. Chỉ request lớn lỗi, lặp lại đều đặn, thì MTU đường đi là nghi phạm số một.

Đọc gói tin khi có quyền quản trị

Có quyền quản trị thì bắt gói tin sẽ cho câu trả lời rõ nhất. Windows có pktmon dựng sẵn, Wireshark dùng tiện hơn. Lab không chạy bước này vì tài khoản không có quyền quản trị, phần dưới là các dấu hiệu theo tài liệu giao thức:

• Gói TCP dài 1514 byte trên dây, tức 1500 byte IP, được gửi lại nhiều lần với cùng số thứ tự.
• Không có gói ICMP loại 3 mã 4 nào quay về, hoặc với IPv6 là không có ICMPv6 loại 2.
• Phía nhận gửi ACK lặp lại cho cùng một số thứ tự, vì gói đầy MSS không bao giờ tới.
• Gói nhỏ hơn, như ACK hay dữ liệu cuối tệp, vẫn qua bình thường.

Nếu thấy ICMP loại 3 mã 4 quay về mà máy vẫn gửi gói lớn, vấn đề nằm ở máy, ví dụ phần mềm bảo mật đang bỏ ICMP trước khi tới nhân hệ điều hành.

Bảng phân biệt các lỗi gần giống

Bảng dưới gom những lỗi hay bị nhầm với MTU. Cột cuối là phép thử ngắn nhất để loại trừ từng lỗi:

Bảng: Bảng phân biệt các lỗi gần giống

Hiện tượng	MTU black hole	Lỗi khác hay bị nhầm	Phép thử phân biệt
Treo sau Client Hello	Có, vì chứng chỉ lớn	Website chặn vân tay TLS	Website chặn thường trả alert hoặc RST ngay
Lỗi ngay khi kết nối	Không	Proxy chết, sai cổng	curl báo lỗi trước khi có connect
HTTP 407	Không	Sai tài khoản proxy	Có mã phản hồi nghĩa là đường đi vẫn thông
Connection reset	Hiếm	Tường lửa, proxy cắt	Xem gói RST trong bắt gói tin
Tải dừng ở byte cố định	Có	Giới hạn băng thông	Giới hạn băng thông làm chậm, không dừng hẳn

Hai bài lỗi ERR_CONNECTION_CLOSED và lỗi curl 56 đi sâu vào nhóm lỗi đóng kết nối. Bài này chỉ giữ phần liên quan tới kích thước gói.

Lỗi curl 56 và curl 28 nói gì về MTU

curl trả mã 28 khi hết thời gian, và đây là mã hay gặp nhất khi có black hole, vì kết nối không bị cắt mà chỉ đứng. Mã 56 nghĩa là lỗi khi nhận dữ liệu, thường do kết nối bị cắt bằng RST. Một số thiết bị trung gian phát hiện gói lớn quá lâu rồi đóng kết nối, khi đó anh em có thể thấy mã 56 thay vì 28.

Vì vậy mã lỗi chỉ là gợi ý. Quyết định cuối cùng phải dựa trên phép thử nhỏ và lớn, cộng với kết quả ping DF hoặc bắt gói tin.

Cách xử lý MTU và PMTUD khi dùng proxy theo bằng chứng

Khi điểm hẹp nằm trên mạng của anh em

Nếu ping DF tới nhiều đích đều chỉ đạt dưới 1472, điểm hẹp nằm gần máy anh em. Cách xử lý đúng là giảm MTU của giao diện mạng cho khớp, để máy tự gửi gói nhỏ ngay từ đầu. Trên Windows, lệnh cần quyền quản trị, và lab không chạy:

netsh interface ipv4 set subinterface "Wi-Fi" mtu=1400 store=active
netsh interface ipv4 show subinterfaces

Tham số store=active làm thay đổi mất sau khi khởi động lại, phù hợp để thử. Khi đã chắc giá trị đúng mới bỏ tham số này. Chọn MTU bằng kết quả ping lớn nhất cộng 28, không chọn số tròn theo cảm tính.

Khi điểm hẹp nằm sau proxy

Nếu đường từ anh em tới proxy cho ping 1472 bình thường, mà tải lớn qua proxy vẫn treo, điểm hẹp có thể nằm giữa proxy và website. Anh em không chỉnh được chặng này từ máy mình. Việc nên làm là gom bằng chứng gửi nhà cung cấp proxy:

• Kết quả ping DF tới IP proxy, nếu proxy trả lời ping.
• Kết quả curl -w cho request nhỏ và request lớn, mỗi loại năm lần.
• Tên miền đích, giờ thử và IP proxy đã dùng.
• Kết quả cùng phép thử khi đi thẳng không qua proxy, để so sánh.

Nhà vận hành proxy có thể bật kẹp MSS trên máy chủ, ví dụ quy tắc TCPMSS của iptables. Kẹp MSS sửa con số MSS trong gói SYN đi qua, để hai đầu không bao giờ gửi gói lớn hơn đường đi chịu được.

PLPMTUD, cách dò không cần ICMP

RFC 4821 mô tả PLPMTUD, cách tầng TCP tự dò MTU bằng gói thăm dò mà không cần ICMP. Khi gói thăm dò lớn bị mất mà gói nhỏ qua được, máy gửi tự hạ kích thước. RFC 8899 mở rộng ý tưởng này cho giao thức chạy trên UDP như QUIC.

Linux có tùy chọn tcp_mtu_probing cho TCP, còn Windows có khóa registry EnablePMTUBHDetect cho phát hiện black hole. Trên máy lab, lệnh reg query vào khóa Tcpip\Parameters không trả dòng nào chứa MTU hay BH, tức máy đang dùng mặc định của hệ điều hành. Bài không khuyên tự sửa registry khi chưa có bằng chứng.

Proxy SOCKS5, UDP và HTTP/3

Với proxy SOCKS5, kết nối TCP vẫn chia hai chặng như proxy HTTP. Với UDP qua SOCKS5, mỗi gói UDP được bọc thêm tiêu đề SOCKS nên dữ liệu thật trong mỗi gói còn nhỏ hơn. HTTP/3 chạy trên QUIC, và QUIC cấm cắt nhỏ gói IP, nên nó tự dò MTU theo RFC 8899.

Phần lớn công cụ crawl vẫn dùng HTTP/1.1 hoặc HTTP/2 trên TCP qua proxy. Nếu anh em dùng thư viện có HTTP/3, nhớ rằng lỗi MTU của UDP biểu hiện khác, thường là kết nối QUIC thất bại rồi trình duyệt tự quay về TCP.

Giới hạn suy luận khi chẩn đoán MTU và PMTUD khi dùng proxy

Ping thành công chưa chứng minh TCP qua proxy chạy

Ping DF đo đường từ máy tới một IP, bằng giao thức ICMP. Đường tới proxy cho ping 1472 không chứng minh chặng proxy tới website cũng 1500. Một số thiết bị còn xử lý ICMP và TCP theo đường khác nhau.

Ngược lại, ping thất bại cũng chưa chứng minh MTU nhỏ, vì nhiều máy chủ chặn ICMP echo. Luôn ghép kết quả ping với phép thử nhỏ và lớn bằng HTTP.

Mô hình chỉ minh họa, không thay cho đo thật

Mô hình ba kịch bản ở trên giả định thời gian chờ nhân đôi bắt đầu từ 1 giây. Hệ điều hành thật dùng giá trị và giới hạn khác, và có thể bật phát hiện black hole để hạ MSS sau vài lần thất bại. Con số 2,50 giây hay 30 giây trong mô hình không phải số đo.

Điều mô hình giữ đúng là thứ tự sự kiện: dữ liệu nhỏ qua, dữ liệu lớn mắc kẹt, không có lỗi rõ ràng nào báo về. Đó là hình dạng anh em cần tìm trong log thật.

Thay đổi chỉ áp dụng một phía

Hạ MTU trên máy anh em chỉ sửa chiều gửi đi từ máy. Chiều dữ liệu từ proxy về máy được điều khiển bằng MSS mà máy báo trong gói SYN. Vì MSS tính từ MTU của giao diện, hạ MTU giao diện cũng làm máy báo MSS nhỏ hơn, nên thường sửa được cả hai chiều trên chặng một.

Chặng hai giữa proxy và website thì không chịu ảnh hưởng của bất kỳ thiết lập nào trên máy anh em. Hạ MTU trên máy không sửa được black hole nằm sau proxy.

Đừng đổ hết cho MTU

MTU black hole có thật nhưng không phổ biến bằng lỗi tài khoản, lỗi định dạng URL hay website chặn IP. Trước khi đào sâu, chạy lại các kiểm tra cơ bản: thông tin đăng nhập, biến no_proxy có vô tình bỏ qua proxy không, và proxy có đang hoạt động không.

Chỉ khi các phép thử cơ bản đều qua, và triệu chứng đúng hình dạng nhỏ chạy lớn treo, mới chuyển sang quy trình đo MTU. Cách làm này tiết kiệm thời gian hơn đoán mò rồi đổi hết cấu hình.

Một thói quen tốt là ghi lại thứ tự đã kiểm vào phiếu sự cố. Người xử lý sau đọc phiếu sẽ biết bước nào đã loại trừ, không phải chạy lại từ đầu. Với đội có nhiều người trực, phiếu này còn giúp tránh hai người cùng sửa cấu hình mạng một lúc.

Checklist MTU và PMTUD khi dùng proxy cho đội vận hành

Trước khi kết luận

Checklist MTU khi dùng proxy

Danh sách dưới dùng được cho cả crawler, trình duyệt tự động và công cụ dòng lệnh. Đi theo thứ tự, dừng ở bước đầu tiên cho kết quả bất thường:

• Xác nhận proxy chạy với một request nhỏ, có mã HTTP trả về.
• Chạy request nhỏ và request lớn qua cùng proxy, mỗi loại năm lần, ghi curl -w.
• Chạy cùng hai request khi không qua proxy để so sánh.
• Ping DF tới IP proxy và một IP công cộng, ghi con số lớn nhất thành công.
• Đọc bảng destinationcache để xem Windows đã học MTU nào cho IP proxy.
• Nếu có quyền quản trị, bắt gói tin để tìm gói 1514 byte gửi lại và ICMP còn thiếu.

Sau khi đã tìm được điểm hẹp

Nếu điểm hẹp ở chặng một, hạ MTU giao diện bằng store=active, thử lại, rồi mới lưu cố định. Nếu điểm hẹp ở chặng hai, gửi gói bằng chứng cho nhà cung cấp proxy và chờ họ xử lý trên máy chủ. Nếu dùng VPN cùng lúc với proxy, thử tắt VPN để xem lớp đóng gói nào đang lấy bớt byte.

Ghi lại kết quả vào tài liệu vận hành, kèm ngày đo và IP. MTU đường đi có thể đổi khi nhà mạng đổi tuyến, nên một kết quả cũ không còn đúng mãi.

Với hệ thống chạy lâu dài, nên đưa phép thử nhỏ và lớn vào bộ kiểm tra định kỳ. Một tác vụ chạy mỗi giờ, tải một tệp cố định qua từng proxy và ghi thời gian, sẽ báo sớm khi một tuyến bắt đầu có black hole. Cảnh báo dựa trên tỷ lệ hết giờ của tệp lớn hữu ích hơn cảnh báo dựa trên tỷ lệ lỗi chung, vì lỗi MTU dễ bị lẫn trong các lỗi khác.

Chọn proxy cho tác vụ nhạy với gói lớn

Tác vụ tải tệp lớn hay gửi POST có thân lớn sẽ lộ lỗi MTU sớm hơn tác vụ chỉ đọc trang nhỏ. Với nhóm tác vụ này, nên chạy phép thử nhỏ và lớn ngay khi nhận proxy mới. Nếu cần một bộ IP để thử, anh em có thể mua proxy datacenter Việt Nam hoặc dân cư tĩnh của ProxyVN, có HTTP và SOCKS5 kèm tài khoản riêng. Sau đó đo theo quy trình trên trước khi đưa vào chạy thật.

ProxyVN giữ mạng kết nối ổn định và hỗ trợ kỹ thuật 24/24. Khi báo lỗi treo khi tải lớn, gửi kèm kết quả curl -w và ping DF sẽ giúp đội hỗ trợ khoanh vùng nhanh hơn nhiều so với mô tả chung chung.

Câu hỏi thường gặp về MTU và PMTUD khi dùng proxy

Có nên hạ MTU xuống thật thấp cho an toàn không?

Không nên. MTU thấp làm mỗi gói chở ít dữ liệu hơn, tốn thêm tiêu đề và thêm gói, nên tốc độ giảm trên mọi kết nối. Chỉ hạ tới đúng con số đo được, không hạ thêm theo cảm tính.

Proxy datacenter có ít lỗi MTU hơn proxy dân cư không?

Bài không có số liệu để so sánh. MTU phụ thuộc vào tuyến mạng cụ thể giữa các máy, không phụ thuộc vào loại proxy. Cách đúng là đo trên chính proxy anh em dùng.

Vì sao trình duyệt chạy mà script Python lại treo?

Trình duyệt hiện đại có thể dùng HTTP/3 trên QUIC, tự dò MTU, hoặc dùng kết nối đã mở sẵn. Script Python thường mở kết nối TCP mới mỗi lần. Hai đường khác nhau có thể cho kết quả khác nhau trên cùng proxy, nên so sánh bằng cùng một công cụ.

MTU có liên quan tới vân tay TCP không?

Có một phần. MSS nằm trong gói SYN, và website có thể dùng nó cùng các trường khác để đoán hệ điều hành hoặc loại kết nối. Bài TCP fingerprint giải thích cơ chế này. Nhưng với proxy HTTP, website chỉ thấy gói SYN của máy proxy, không thấy MSS của máy anh em.

Lỗi ERR_CONNECTION_RESET có phải do MTU không?

Thường là không. RESET nghĩa là có một bên chủ động cắt kết nối, còn black hole làm kết nối đứng im. Bài lỗi ERR_CONNECTION_RESET liệt kê các nguyên nhân phổ biến hơn của lỗi này.

MTU và PMTUD khi dùng proxy: điều cần nhớ

MTU và PMTUD khi dùng proxy chỉ đáng nghi khi request nhỏ chạy còn dữ liệu lớn treo lặp lại. Đo bằng ping DF, đọc bảng destinationcache, chạy cặp request nhỏ và lớn với curl -w, rồi xác định điểm hẹp nằm trước hay sau proxy. Cần proxy ổn định để kiểm tra MTU và PMTUD khi dùng proxy, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.