Kiểm Tra Tốc Độ Proxy: Hướng Dẫn Thực Tế cho Năm 2026

Proxy của bạn đã vượt qua kiểm tra. Nó đã trả về một địa chỉ IP. Nó thậm chí đã tải một trang.

Rồi tự động hóa của bạn bắt đầu thất bại.

Khoảng cách đó là nơi mà hầu hết các bài kiểm tra tốc độ proxy gặp sai lầm. Một yêu cầu thành công duy nhất không cho bạn biết nhiều về việc liệu một proxy có thể sống sót qua các quy trình đăng nhập, tải trang lặp đi lặp lại, yêu cầu nặng về phương tiện, hoặc các mẫu duyệt web giống như ứng dụng di động hay không. Điều này càng rõ ràng hơn với các proxy di động, nơi mà việc xoay vòng, điều kiện sóng, và việc sử dụng chung có thể thay đổi hình dạng của lưu lượng từ phút này sang phút khác.

Nếu bạn đang thực hiện việc tạo tài khoản, khởi động, kiểm tra quảng cáo, QA địa lý, hoặc quy trình làm việc trên mạng xã hội, bạn không cần một con số tốc độ hào nhoáng. Bạn cần một phương pháp kiểm tra cho thấy liệu một proxy có giữ được khả năng sử dụng khi nhiệm vụ trở nên thực tế hay không.

Tại sao bài kiểm tra tốc độ proxy của bạn có thể sai

Vẫn còn phổ biến để kiểm tra proxy như thể đó là một câu hỏi nhị phân. Hoạt động hoặc không hoạt động. Cách suy nghĩ đó đã lỗi thời.

Kiểm tra proxy hiện đại đã chuyển từ một kiểm tra kết nối đơn giản sang một quy trình đo lường rộng hơn bao gồm thời gian tải trang, kiểm tra ẩn danh, và kiểm tra theo lô. Điểm lớn hơn là về mặt hoạt động. Các nhóm cần các phép đo lặp lại cho thời gian hoạt động, thời gian phản hồi, và tỷ lệ lỗi, không phải một thành công may mắn trên một công cụ kiểm tra công khai, như đã đề cập trong tổng quan về quy trình kiểm tra proxy trực tuyến này.

Biểu tượng kiểm tra màu xanh không phải là kết quả hiệu suất

Một proxy có thể vượt qua một bài kiểm tra cơ bản và vẫn không tốt cho sản xuất. Điều đó xảy ra thường xuyên với:

• Các nhiệm vụ nặng về đăng nhập nơi mà kết nối TCP ban đầu hoạt động, nhưng các yêu cầu sau đó chậm lại đủ để kích hoạt các lần thử lại hoặc kiểm tra hành vi nghi ngờ.
• Các điểm cuối di động xoay vòng nơi một yêu cầu rơi vào một lộ trình sạch và yêu cầu tiếp theo đi theo một con đường khác với độ trễ khác nhau.
• Các cổng chia sẻ nơi lưu lượng của người dùng khác thay đổi trải nghiệm của bạn mà không có cảnh báo.
• QA nhạy cảm với địa lý nơi mà trang đích có thể truy cập, nhưng các tài sản trang, kịch bản, hoặc các cuộc gọi API tải không nhất quán qua lộ trình.

Nếu bài kiểm tra của bạn kết thúc sau "yêu cầu thành công," bạn chỉ xác nhận rằng proxy không chết trong một khoảnh khắc.

Quy tắc thực tiễn: Nếu ứng dụng của bạn thực hiện nhiều hơn một yêu cầu cho mỗi hành động của người dùng, bài kiểm tra tốc độ proxy với một yêu cầu là quá nông.

Các proxy di động làm cho các bài kiểm tra yếu trông tốt hơn so với thực tế

Các proxy di động thường khoan dung hơn từ góc độ tin cậy trên các nền tảng xã hội, nhưng điều đó không có nghĩa là chúng sẽ hoạt động như cơ sở hạ tầng có dây. Một lộ trình di động tốt có thể trông chậm hơn trong một bài kiểm tra chung trong khi vẫn mang lại kết quả tốt hơn cho nền tảng so với một lộ trình nhanh hơn, ít đáng tin cậy hơn.

Sự phân biệt đó quan trọng trong các quy trình làm việc kiểu Instagram. Câu hỏi không chỉ là tốc độ mà byte di chuyển. Câu hỏi chính là liệu phiên làm việc có hoàn thành một cách sạch sẽ, liệu các chuyển tiếp trang có giữ ổn định, và liệu proxy có giữ cho nền tảng không gia tăng ma sát.

Mục tiêu kiểm tra sai tạo ra sự tự tin giả

Nhiều bài kiểm tra proxy nhắm vào một điểm cuối chung mà không liên quan gì đến khối lượng công việc thực tế. Điều đó tạo ra các con số, nhưng không phải là các con số đủ để ra quyết định.

Một bài kiểm tra hữu ích phản ánh đích đến và hành vi:

• Vùng giống nhau như nền tảng mục tiêu hoặc trang đích
• Giao thức giống nhau mà ứng dụng của bạn sử dụng
• Mẫu yêu cầu giống nhau mà tự động hóa của bạn tạo ra
• Thời gian phiên giống nhau mà bạn mong đợi trong sản xuất

Khi các nhóm coi QA proxy như một kỷ luật liên tục thay vì một kiểm tra một lần, họ ngừng hỏi "proxy này có sống không?" và bắt đầu hỏi "proxy này có phù hợp với công việc này không?"

Đó là sự khác biệt giữa một danh sách proxy và một hệ thống proxy.

Chọn các chỉ số hiệu suất chính của bạn

Trước khi thực hiện bài kiểm tra tốc độ proxy, hãy xác định "đủ nhanh" có nghĩa là gì đối với khối lượng công việc của bạn. Người dùng thường nhảy ngay vào tốc độ tải xuống vì nó dễ hiểu. Đối với việc tự động hóa và sử dụng proxy di động, điều đó thường không phải là nút thắt chính.

Độ trễ cho các hành động tương tác

Độ trễ là khoảng thời gian trước khi bên từ xa bắt đầu phản hồi. Trong thực tế, nó thường là tín hiệu rõ ràng nhất cho công việc tương tác.

Nếu bạn đang mở các nguồn cấp dữ liệu, bước qua thiết lập tài khoản, kiểm tra trước quảng cáo, hoặc thực hiện tự động hóa trình duyệt với nhiều yêu cầu nhỏ, độ trễ cao sẽ tích lũy nhanh. Một chuyến đi chậm có vẻ vô hại. Một quy trình tải trang đầy đủ có thể chứa nhiều chuyến đi như vậy.

Sử dụng độ trễ như một chỉ số chính khi nhiệm vụ có mật độ yêu cầu dày đặc hơn là nặng về băng thông.

Phù hợp tốt cho kiểm tra ưu tiên độ trễ:

• Khởi động tài khoản: Các hành động tuần tự bị phá vỡ khi mỗi bước chờ quá lâu.
• Mô phỏng duyệt xã hội: Tải nguồn cấp dữ liệu phụ thuộc vào nhiều cuộc gọi nhỏ, không phải một chuyển giao lớn.
• Kiểm tra QA địa lý: Bạn muốn lộ trình cảm thấy đủ ổn định để kiểm tra hành vi trang, không chỉ lấy HTML.

Thông lượng cho công việc nặng về tải trọng

Thông lượng đo lường lượng dữ liệu mà proxy có thể truyền tải theo thời gian. Điều đó quan trọng, nhưng chủ yếu khi kích thước tải trọng là vấn đề.

Nếu bạn đang xác thực các trang nặng về phương tiện, thu thập các thân phản hồi lớn, hoặc di chuyển nhiều tài sản qua lộ trình, thông lượng thấp sẽ trở nên rõ ràng. Tuy nhiên, đối với nhiều nhiệm vụ trên mạng xã hội, thông lượng là thứ yếu so với tính nhất quán.

Một proxy với thông lượng khiêm tốn vẫn có thể hoạt động tốt cho tự động hóa dựa trên phiên nếu các phản hồi của nó ổn định và thiết lập kết nối của nó sạch sẽ.

Thời gian kết nối và tỷ lệ thành công cho thực tế

Hầu hết các bài kiểm tra nghiêm túc nên ưu tiên các khía cạnh như kết nối đáng tin cậy và các chuỗi yêu cầu hoàn chỉnh. Tốc độ thô không cho bạn biết liệu proxy có kết nối đáng tin cậy hay hoàn thành các chuỗi yêu cầu đầy đủ mà không bị ngắt quãng.

Một khung thực tiễn:

Kiểm tra cho chế độ thất bại mà bạn thực sự quan tâm. Nếu các yêu cầu bị chặn làm bạn đau hơn các trang chậm, hãy làm cho tỷ lệ thành công trở thành chỉ số chính.

Khớp chỉ số với nhiệm vụ

Đừng đối xử với mọi quy trình làm việc giống nhau. Một bài kiểm tra proxy sạch bắt đầu với khối lượng công việc.

• Đối với tự động hóa trình duyệt: ưu tiên độ trễ, thời gian kết nối, và thành công lặp lại.
• Đối với việc lấy nội dung hàng loạt: ưu tiên thông lượng và hành vi thời gian chờ.
• Đối với các hoạt động tài khoản trên các proxy di động: ưu tiên tính ổn định của phiên và liệu lộ trình có giữ được khả năng sử dụng qua các hành động thực tế lặp lại hay không.
• Đối với xác minh quảng cáo và kiểm tra địa lý: ưu tiên hoàn thành trang, tải tài sản, và tính nhất quán qua nhiều lần chạy.

Bài kiểm tra tốc độ proxy mạnh nhất không phải là bài kiểm tra có nhiều cột nhất. Nó là bài kiểm tra mà ánh xạ trực tiếp đến nhiệm vụ bạn cần giữ cho sống.

Các phương pháp dòng lệnh thực tiễn cho kiểm tra chính xác

Một proxy có thể trông ổn trong một công cụ kiểm tra trình duyệt và vẫn thất bại trong công việc mà bạn quan tâm nhất. Điều đó xảy ra thường xuyên với các proxy di động. Một cú nhấp nhanh trên một URL kiểm tra không nói lên nhiều về việc liệu một lộ trình 4G có giữ được khả năng sử dụng qua các hành động Instagram lặp lại, sống sót qua một vòng xoay, hoặc giữ vững khi nhiều công nhân chia sẻ cùng một cổng.

Bắt đầu với curl và ghi lại các trường đúng

curl là bước đầu tiên đúng đắn vì nó phơi bày các thời gian quan trọng và giữ cho bài kiểm tra dễ lặp lại.

Sử dụng một lệnh như thế này:

curl -x http://USER:PASS@PROXY_HOST:PROXY_PORT \
  -s -o /dev/null \
  --connect-timeout 15 \
  -w 'code=%{http_code} connect=%{time_connect} starttransfer=%{time_starttransfer} total=%{time_total} size=%{size_download} speed=%{speed_download}\n' \
  https://TARGET_URL

Các trường này trả lời các câu hỏi khác nhau:

• time_connect cho thấy tốc độ bắt tay của proxy.
• time_starttransfer cho thấy thời gian chờ của máy chủ cộng với bất kỳ độ trễ nào do tuyến đường gây ra.
• time_total cho thấy tổng chi phí yêu cầu.
• speed_download cung cấp một cái nhìn tổng quát về hiệu suất chuyển giao cho phản hồi đó.
• http_code cho thấy liệu yêu cầu có hoàn thành theo cách sử dụng được hay không.

Đối với SOCKS5, hãy chuyển đổi cờ proxy:

curl --proxy socks5h://USER:PASS@PROXY_HOST:PROXY_PORT \
  -s -o /dev/null \
  --connect-timeout 15 \
  -w 'code=%{http_code} connect=%{time_connect} total=%{time_total} speed=%{speed_download}\n' \
  https://TARGET_URL

Thời gian kết nối 15 giây là một điểm khởi đầu hợp lý cho các nhóm proxy hỗn hợp. Nó đủ lâu để bắt được các bắt tay di động chậm mà không để các tuyến đường chết lãng phí quá nhiều thời gian thử nghiệm. Hãy siết chặt nó sau nếu các công việc sản xuất của bạn thất bại nhanh hơn.

Chạy các yêu cầu lặp lại thay vì các yêu cầu đơn lẻ

Một yêu cầu gần như không chứng minh được gì. Mười yêu cầu bắt đầu cho thấy hành vi.

for i in $(seq 1 10); do
  curl -x http://USER:PASS@PROXY_HOST:PROXY_PORT \
    -s -o /dev/null \
    --connect-timeout 15 \
    -w 'run='$i' code=%{http_code} connect=%{time_connect} total=%{time_total} speed=%{speed_download}\n' \
    https://TARGET_URL
done

Đọc tập hợp chạy như một nhà điều hành, không phải như một biểu đồ chuẩn.

• Các thời gian kết nối có giữ trong cùng một dải không?
• Có một vài yêu cầu bị treo gần thời gian hết hạn không?
• Các mã trạng thái có đảo ngược trong suốt chuỗi không?
• Hiệu suất có giảm sau khi xoay vòng hoặc sau một vài lần truy cập từ cùng một cổng không?

Các mẫu đó quan trọng hơn trên các proxy di động so với kết quả đơn lẻ nhanh nhất. Một cổng LTE chia sẻ có thể đăng một thời gian mạnh và vẫn tạo ra tỷ lệ thành công yếu khi một người dùng khác tải cùng một cổng. Một proxy di động cá nhân thường trông kém ấn tượng hơn về thông lượng thô, nhưng nó thường cung cấp tính lặp lại sạch hơn, điều này giữ cho các quy trình tài khoản sống động.

Thêm độ đồng thời một cách cẩn thận

Tải thay đổi câu chuyện nhanh chóng. Một proxy xử lý một yêu cầu một cách sạch sẽ có thể trở nên không ổn định khi bạn đẩy lưu lượng song song qua nó.

Một mẫu shell đơn giản:

seq 5 | xargs -I{} -P 5 sh -c '
curl -x http://USER:PASS@PROXY_HOST:PROXY_PORT \
  -s -o /dev/null \
  --connect-timeout 15 \
  -w "job={} code=%{http_code} connect=%{time_connect} total=%{time_total} speed=%{speed_download}\n" \
  https://TARGET_URL
'

Rồi tăng độ song song:

seq 10 | xargs -I{} -P 10 sh -c '
curl -x http://USER:PASS@PROXY_HOST:PROXY_PORT \
  -s -o /dev/null \
  --connect-timeout 15 \
  -w "job={} code=%{http_code} connect=%{time_connect} total=%{time_total} speed=%{speed_download}\n" \
  https://TARGET_URL
'

Bắt đầu thấp và tăng dần. Điều đó phản ánh sản xuất tốt hơn là nhảy thẳng vào một bài kiểm tra căng thẳng.

Đối với các proxy di động, kết quả độ đồng thời cần có ngữ cảnh. Nếu bạn sử dụng một cổng 4G cá nhân cho mỗi công nhân tự động hóa, tải song song nặng trên một proxy duy nhất là không thực tế và bài kiểm tra có thể gây hiểu lầm cho bạn. Nếu bạn mua quyền truy cập di động chia sẻ và phân phối nhiều phiên qua cùng một lối thoát, việc kiểm tra độ đồng thời rất quan trọng vì sự cạnh tranh là một phần của sản phẩm.

Nếu quy trình Instagram của bạn chạy một phiên mỗi cổng, hãy kiểm tra một phiên mỗi cổng. Nếu trình thu thập dữ liệu của bạn phân phối qua các lối thoát di động chia sẻ, hãy kiểm tra theo cách tương tự.

Kiểm tra đường dẫn yêu cầu thực tế, không chỉ một URL tĩnh

Một yêu cầu GET đơn giản hữu ích cho việc đo thời gian. Nó không đủ cho các quy trình làm việc cần đăng nhập, theo dõi chuyển hướng, tải API hoặc tái sử dụng cookie.

Đẩy các công việc dòng lệnh thực tế của bạn qua đường dẫn proxy khi có thể. Kiểm tra cùng các tiêu đề, cùng hành vi phiên, và cùng độ dài chuỗi mà công nhân của bạn sử dụng trong sản xuất. Đối với các proxy di động, các bài kiểm tra như vậy phơi bày các tuyến đường yếu. Proxy có thể trả về trạng thái sạch trên một trang mục tiêu đơn giản nhưng thất bại khi nền tảng yêu cầu nhiều yêu cầu liên kết từ cùng một phiên.

Sự khác biệt đó là phổ biến trên các nền tảng xã hội. Một tuyến đường có tốc độ thô trung bình vẫn có thể vượt trội hơn một tuyến nhanh hơn nếu nó hoàn thành nhiều hành động thực mà không cần đặt lại, trang thách thức, hoặc phiên bị ngắt.

Sử dụng kiểm tra kiểu iperf chỉ cho một câu hỏi hẹp

Các bài kiểm tra băng thông cấp thấp trả lời một câu hỏi hẹp. Đường truyền có bị hạn chế không?

Điều đó có thể giúp trong quá trình khắc phục sự cố, đặc biệt nếu tải lên hoặc tải xuống rõ ràng bị tắc nghẽn. Nó không cho bạn biết liệu một proxy di động xoay vòng có giữ cùng một phiên đủ lâu cho các hành động tài khoản hay không, liệu một cổng chia sẻ có giảm chất lượng dưới lưu lượng hàng xóm hay không, hoặc liệu tuyến đường có được tin cậy bởi đích hay không.

Đối với các hoạt động proxy, thời gian lớp ứng dụng và thành công lặp lại thường cung cấp tín hiệu tốt hơn so với băng thông thô.

Giải thích Kết quả Kiểm tra Tốc độ Proxy Di động

Một proxy di động có thể thua mọi so sánh tốc độ thô và vẫn hoàn thành công việc.

Điều đó xảy ra thường xuyên với tự động hóa Instagram. Một proxy 4G hoặc LTE có thể cho thấy độ trễ cao hơn và thông lượng thấp hơn so với một tuyến đường trung tâm dữ liệu, nhưng vẫn hoàn thành nhiều lần đăng nhập hơn, giữ phiên lâu hơn, và kích hoạt ít điểm kiểm tra hơn. Nếu bài kiểm tra chỉ đo tốc độ, nó bỏ lỡ phần ảnh hưởng đến đầu ra.

Đọc kết quả di động như các khoảng hoạt động

Các số liệu một lần chạy là tín hiệu yếu trên các mạng di động. Lưu lượng của nhà mạng thay đổi. Điều kiện sóng thay đổi. Các cổng chia sẻ nhận tiếng ồn từ người dùng khác. Việc xoay vòng có thể đặt lại đường dẫn giữa cửa sổ mẫu của bạn.

Sử dụng các lần chạy lặp lại và tìm kiếm một khoảng sử dụng được, không phải một kết quả hoàn hảo.

Một kết quả proxy di động khỏe mạnh thường trông như thế này:

• Độ trễ giữ trong một dải qua nhiều lần chạy, ngay cả khi số chính xác di chuyển xung quanh
• Thời gian đến byte đầu tiên giữ đủ dự đoán cho quy trình làm việc mục tiêu
• Các lỗi tập trung quanh các sự kiện xoay vòng thay vì xuất hiện ngẫu nhiên
• Các cổng cá nhân cho thấy độ biến thiên chặt chẽ hơn so với các cổng chia sẻ dưới cùng một bài kiểm tra

Đối với các proxy di động, độ biến thiên quan trọng như tốc độ. Một tuyến đường dao động giữa chấp nhận được và không sử dụng được sẽ phá vỡ các hành động tài khoản theo cách mà một điểm số trung bình ẩn giấu.

Xoay vòng thay đổi cách bạn đánh giá proxy

Xoay vòng ảnh hưởng đến nhiều hơn là độ tươi của IP. Nó thay đổi ý nghĩa của một kết quả thời gian.

Nếu bạn kiểm tra qua một xoay vòng cưỡng bức hoặc một thay đổi nhà mạng theo lịch, bạn đang đo lường hai trạng thái cùng một lúc. Điều đó làm cho trung bình gần như vô dụng cho công việc dựa trên phiên. Chia dữ liệu thành các cửa sổ trước và sau khi xoay vòng, sau đó so sánh từng cửa sổ riêng biệt.

Sử dụng bảng này như một cách đọc thực tế:

Đối với công việc Instagram, tôi quan tâm nhiều hơn đến việc liệu proxy có thể hoàn thành một lần đăng nhập, tải hồ sơ, và một vài yêu cầu tiếp theo trên cùng một phiên hơn là liệu nó có giảm vài trăm mili giây so với một lần lấy tĩnh.

Cổng chia sẻ so với cổng cá nhân

Các cổng di động chia sẻ và cá nhân không nên được đánh giá theo cùng một tiêu chuẩn.

Các cổng chia sẻ là tốt cho các kiểm tra chi phí thấp, lấy mẫu hồ bơi rộng, và các tác vụ dùng một lần. Chúng cũng mang nhiều biến thiên hơn. Lưu lượng của khách hàng khác có thể ảnh hưởng đến thời gian bắt tay, thời gian phản hồi, và liệu tuyến đường của bạn có trông ổn định trong một chuỗi ngắn hay không.

Các cổng cá nhân thường có điểm chuẩn rõ ràng hơn vì ít biến số thay đổi cùng một lúc. Điều đó làm cho chúng dễ dàng hơn để đánh giá cho việc tạo tài khoản, khởi động, kiểm tra hộp thư đến, hoặc bất kỳ quy trình nào trên Instagram mà phiên làm việc phải tồn tại qua nhiều yêu cầu liên kết.

Một nhà cung cấp trong danh mục này, Evoproxy, cung cấp cả cổng di động chia sẻ và cá nhân với hành vi xoay vòng có thể cấu hình cho các trường hợp sử dụng IP di động của Pháp. Sự phân chia đó rất hữu ích trong quá trình thử nghiệm vì nó cho phép bạn đo lường giá của sự nhất quán trực tiếp thay vì đoán.

Một cổng cá nhân chậm hơn thường tạo ra tỷ lệ hoàn thành hành động tốt hơn so với một cổng chia sẻ nhanh hơn. Trong sản xuất, tỷ lệ hoàn thành mới là điều quan trọng.

Ánh xạ dữ liệu tốc độ tới thành công hành động

Độ trễ thô, tốc độ tải xuống và ping là các chỉ số hỗ trợ. Chỉ số quyết định là liệu proxy có hoàn thành công việc hay không.

Đối với các proxy di động, kết hợp dữ liệu thời gian với dữ liệu kết quả từ nhiệm vụ mục tiêu:

• Tỷ lệ hoàn thành đăng nhập
• Tần suất điểm kiểm tra hoặc thách thức
• Tỷ lệ thành công qua một chuỗi hành động ngắn
• Sự tồn tại của phiên sau khi xoay vòng
• Số lần thử lại cần thiết để hoàn thành công việc

Một ví dụ đơn giản làm rõ sự đánh đổi. Giả sử một proxy trung bình có thời gian phản hồi nhanh hơn nhưng làm mất phiên trong yêu cầu thứ hai hoặc thứ ba. Một proxy khác chậm hơn, nhưng nó hoàn thành đăng nhập, tải nguồn cấp và các hành động hồ sơ mà không bị gián đoạn. Proxy thứ hai là con đường tốt hơn cho tự động hóa Instagram, mặc dù biểu đồ tốc độ trông tệ hơn.

Đọc các bài kiểm tra proxy di động giống như bạn đọc các hệ thống sản xuất. Ưu tiên con đường hoàn thành quy trình làm việc một cách nhất quán, tồn tại hành vi xoay vòng bình thường và thất bại theo những cách có thể dự đoán mà bạn có thể xử lý.

Cách tự động hóa việc giám sát hiệu suất proxy của bạn

Một bài kiểm tra tốc độ proxy một lần giúp trong việc lựa chọn. Giám sát giúp trong hoạt động.

Bạn muốn một công việc đơn giản đọc danh sách proxy, truy cập một mục tiêu phù hợp với khối lượng công việc thực tế của bạn, và ghi kết quả vào một tệp CSV mà bạn có thể kiểm tra sau. Giữ cho nó nhàm chán. Các kịch bản nhàm chán tồn tại lâu hơn.

Một mẫu Bash thực tiễn

Sử dụng một tệp proxy ở định dạng tiêu chuẩn mà nhóm của bạn có thể duy trì. Sau đó lặp qua chúng và ghi lại thời gian cùng trạng thái.

#!/usr/bin/env bash

TARGET_URL="https://TARGET_URL"
PROXY_LIST="proxies.txt"
OUTPUT_FILE="proxy_results.csv"
TIMEOUT=15

if [ ! -f "$OUTPUT_FILE" ]; then
  echo "timestamp,proxy,http_code,time_connect,time_starttransfer,time_total,size_download,speed_download" > "$OUTPUT_FILE"
fi

while IFS= read -r PROXY; do
  [ -z "$PROXY" ] && continue

  TIMESTAMP=$(date -u +"%Y-%m-%dT%H:%M:%SZ")

  RESULT=$(curl -x "$PROXY" \
    -s -o /dev/null \
    --connect-timeout "$TIMEOUT" \
    -w "%{http_code},%{time_connect},%{time_starttransfer},%{time_total},%{size_download},%{speed_download}" \
    "$TARGET_URL")

  echo "$TIMESTAMP,$PROXY,$RESULT" >> "$OUTPUT_FILE"
done < "$PROXY_LIST"

Một vài ghi chú thực tiễn:

• Giữ cho mục tiêu liên quan: kiểm tra trang hoặc điểm cuối giống như nhiệm vụ sản xuất của bạn.
• Ghi lại thời gian theo UTC: điều này giúp dễ dàng hơn trong việc xem xét xu hướng và so sánh sự cố.
• Bảo tồn các lần chạy thất bại: các hàng trống hoặc xấu vẫn cho bạn biết điều gì đó.

Thêm logic lô nhẹ

Đối với các proxy di động, một lần chạy không đủ. Chạy kịch bản nhiều lần theo lịch trình và so sánh các khoảng thời gian. Bạn muốn xem liệu một proxy có hành xử khác nhau vào những thời điểm khác nhau hoặc xung quanh các khoảng thời gian xoay vòng đã lên kế hoạch hay không.

Các bổ sung hữu ích bao gồm:

• Nhóm mục tiêu riêng biệt: một tệp cho các trang đăng nhập, một cho các trang nội dung, một cho các điểm cuối theo kiểu API.
• Gán nhãn các loại proxy: thêm một cột cho chia sẻ, cá nhân, xoay vòng hoặc dính.
• Bộ lọc thất bại đơn giản: đánh dấu các hàng có mã trạng thái xấu hoặc tổng thời gian gần thời gian chờ.
• Tóm tắt lăn: tính toán các số trung vị và số lần thất bại ngoại tuyến nếu cần.

Theo dõi những gì ứng dụng của bạn thực sự trải nghiệm

Nếu tự động hóa của bạn mở năm trang theo chuỗi, đừng chỉ đo một yêu cầu. Bọc kịch bản để nó thực hiện một chuỗi ngắn và ghi lại liệu chuỗi có hoàn thành hay không. Điều đó thường làm nổi bật các vấn đề vận hành nhanh hơn so với các phép đo tốc độ tổng hợp đơn thuần.

Một thiết lập giám sát mạnh mẽ trả lời các câu hỏi đơn giản nhanh chóng:

• Proxy nào trở nên chậm hơn?
• Proxy nào bắt đầu thất bại?
• URL mục tiêu nào phơi bày vấn đề trước tiên?
• Vấn đề có liên quan đến một loại proxy hay một điểm đến nào không?

Các câu trả lời đó quan trọng hơn một con số băng thông đơn lẻ.

Các cạm bẫy phổ biến và cách tránh chúng

Hầu hết các quyết định sai lầm về proxy đến từ thiết kế thử nghiệm kém, không phải từ các proxy kém. Bản chuẩn tự nó tạo ra sự thiên lệch, và sau đó các nhóm mua hoặc loại bỏ các tuyến đường dựa trên tiếng ồn.

Các sai lầm làm sai lệch kết quả

• Thử nghiệm từ một máy tính cục bộ yếu: máy tính xách tay, Wi-Fi hoặc kết nối văn phòng của bạn có thể là nút thắt cổ chai. Nếu máy chủ khách không ổn định, proxy sẽ bị đổ lỗi cho vấn đề của người khác.
• Sử dụng một điểm đến không liên quan: một proxy có thể hoạt động theo một cách đối với một điểm cuối nhẹ gần đó và theo cách khác đối với ngăn xếp mục tiêu thực tế.
• Trộn lẫn các giao thức một cách cẩu thả: nếu ứng dụng của bạn sử dụng một giao thức proxy và bản chuẩn của bạn sử dụng một giao thức khác, bạn không đang đo lường cùng một con đường.
• Dựa vào một lần chạy: một yêu cầu sạch có thể che giấu sự không ổn định của tuyến đường, ảnh hưởng của xoay vòng, hoặc sự thất bại không liên tục.
• Bỏ qua kết quả phiên: một proxy trông nhanh trong cô lập vẫn có thể gây ra lỗi truy cập trong các quy trình làm việc thực tế.

Một tiêu chuẩn tốt hơn để giữ

Sử dụng một máy chủ thử nghiệm gần với đối tượng mục tiêu hoặc nền tảng mục tiêu của bạn. Lặp lại bản chuẩn. Tăng cường độ đồng thời một cách cẩn thận. Kết hợp kết quả tổng hợp với một kiểm tra trang thực tế phù hợp với khối lượng công việc của bạn.

Điểm cuối cùng này quan trọng nhất đối với các proxy di động. Nếu tuyến đường được dự định cho các nền tảng xã hội, một bài kiểm tra tốc độ proxy hữu ích phải trả lời nhiều hơn "nhanh bao nhiêu." Nó phải trả lời "có thể sử dụng được không."

Một bài kiểm tra tốc độ proxy có ý nghĩa là có ngữ cảnh. Nó tôn trọng giao thức, điểm đến, mức độ đồng thời và hình dạng nhiệm vụ mà ứng dụng của bạn sử dụng. Khi bạn thử nghiệm theo cách đó, các proxy yếu trở nên rõ ràng, và các tuyến đường di động tốt không còn trông "chậm" chỉ vì chúng không phải là có dây.

Nếu bạn cần IP di động của Pháp để chuẩn hóa hành vi thực tế của nền tảng, Evoproxy là một lựa chọn đáng xem cho các nhóm muốn thử nghiệm các cổng chia sẻ so với cá nhân, khoảng thời gian xoay vòng và tính nhất quán của tuyến đường di động trong một thiết lập thực tế thay vì một công cụ kiểm tra chung chung.