TestCafe proxy: cấu hình --proxy, xác thực và sửa lỗi kết nối

TestCafe proxy là cách cho bộ kiểm thử TestCafe tải trang web qua một máy trung gian thay vì đi thẳng ra Internet. ProxyVN chạy thật TestCafe 3.7.6 qua proxy HTTP có mật khẩu tự dựng, ghi lại nguyên văn từng thông báo lỗi. Bài chỉ cách khai báo đúng, cách mã hóa mật khẩu có ký tự đặc biệt và cách đọc lỗi để sửa đúng chỗ.

TestCafe proxy hoạt động theo đường nào

TestCafe đứng giữa trình duyệt và website

TestCafe khác Selenium hay Playwright ở một điểm: ở chế độ cổ điển, nó tự chạy một máy chủ trung gian riêng trên máy kiểm thử. Trình duyệt không mở thẳng website mà mở một địa chỉ dạng 127.0.0.1:1337/mã-phiên/địa-chỉ-thật. Máy chủ trung gian này tên là Hammerhead, nằm trong gói testcafe-hammerhead. Nó tải trang thật, chèn mã điều khiển vào rồi trả về cho trình duyệt.

Vì thế khi anh em khai báo --proxy, trình duyệt không hề biết có proxy. Người nói chuyện với proxy là tiến trình Node của TestCafe. Đọc mã nguồn bản 3.7.6, hàm setExternalProxySettings trong testcafe-hammerhead nhận chuỗi proxy, tách ra máy, cổng và tài khoản, rồi tự gắn tiêu đề Proxy-Authorization kiểu Basic vào từng request gửi đi.

Hiểu điểm này giúp tránh hai nhầm lẫn hay gặp. Một là cố cài proxy vào hồ sơ trình duyệt rồi thắc mắc sao TestCafe vẫn đi thẳng. Hai là tưởng thông báo lỗi đến từ trình duyệt, trong khi nó đến từ Hammerhead và được in ra dưới dòng Error details.

Native automation đổi đường đi ra sao

Từ bản 3.0, TestCafe mặc định bật native automation cho Chrome và Edge. Ở chế độ này, TestCafe điều khiển trình duyệt qua giao thức CDP và không cho trang đi qua Hammerhead nữa. Trang native automation của TestCafe ghi rõ trong mục giới hạn: ở chế độ này TestCafe không định tuyến request HTTP qua proxy.

Nghĩa là nếu anh em chạy testcafe chrome kèm --proxy mà không tắt native automation, proxy sẽ không có tác dụng với trang. Trong mã nguồn bản 3.7.6 mình không thấy thông báo lỗi riêng cho tình huống này, nên test có thể vẫn chạy và báo xanh, chỉ là đi bằng IP của máy. Cách sửa là thêm cờ --disable-native-automation. Trang tài liệu gợi ý một hướng khác: cài proxy ở cấp hệ điều hành.

Firefox, Safari và trình duyệt từ xa không dùng native automation, nên --proxy luôn đi qua Hammerhead với các trình duyệt này.

Môi trường thử trong bài

Mình chạy trên Windows 10, Node 24.20, TestCafe 3.7.6 cài trong một thư mục riêng. Trình duyệt là Edge 156 chạy không giao diện, kết nối vào TestCafe theo chế độ remote. Proxy là một chương trình Python tự viết, nghe cổng 8912, yêu cầu tài khoản qa_user với mật khẩu p@ss#2026, ghi nhật ký mọi request nhận được.

Website đích có tên shop.test. Tên này chỉ phân giải được khi đi qua proxy, vì proxy thử tự trỏ mọi tên đuôi .test về máy cục bộ. Nhờ vậy, request nào lỡ đi thẳng sẽ lập tức báo lỗi DNS, còn request đi qua proxy sẽ trả về trang có dòng via là http-proxy. Đây là cách mình chứng minh đường đi, không dựa vào cảm giác.

Mình không thử với proxy thương mại, không thử NTLM và không chạy trên macOS hay Linux. Kết quả có thể khác ở các bản TestCafe cũ hơn 3.0.

Ai nói chuyện với proxy trong TestCafe

Cấu hình TestCafe proxy bằng dòng lệnh

Cú pháp --proxy

Theo tài liệu dòng lệnh của TestCafe, tham số --proxy nhận tên máy hoặc IP kèm cổng, có thể thêm tài khoản phía trước theo dạng user:pass@máy:cổng. Không có tiền tố http:// trong ví dụ của tài liệu, và đây là chi tiết quan trọng mình sẽ quay lại ở phần lỗi.

npx testcafe "chrome --headless" tests/ --disable-native-automation --proxy 203.0.113.10:8080
npx testcafe firefox tests/ --proxy qa_user:MatKhau123@203.0.113.10:8080

Dòng thứ nhất dùng proxy cho phép theo IP, không cần mật khẩu. Dòng thứ hai dùng proxy có tài khoản. Với Chrome và Edge, nhớ luôn đi kèm --disable-native-automation như đã nói ở trên.

Nếu proxy của anh em đang ở dạng ip:port:user:pass do nhà cung cấp gửi, cần đổi sang dạng user:pass@ip:port trước khi đưa vào TestCafe. Bài định dạng proxy có bảng đổi qua lại giữa các kiểu viết.

Mã hóa tài khoản có ký tự đặc biệt

TestCafe ghép chuỗi proxy thành http://chuỗi rồi đọc như một địa chỉ URL. Mật khẩu có ký tự @, #, : hay / sẽ làm sai cách tách. Cách đúng là mã hóa phần tên và mật khẩu theo quy tắc phần trăm của chuẩn URI RFC 3986: @ thành %40, # thành %23, : thành %3A, / thành %2F, % thành %25.

Với mật khẩu p@ss#2026, chuỗi đúng là qa_user:p%40ss%[email protected]:8912. Mình chạy thật cả hai cách viết. Bản viết thô báo lỗi ngay, bản đã mã hóa qua proxy, proxy nhận đúng tên qa_user và trang trả về via là http-proxy. Hammerhead tự giải mã phần trăm trước khi tạo tiêu đề Basic, nên anh em không phải lo proxy nhận nhầm chuỗi %40.

Trong Node, hàm encodeURIComponent làm việc này. Trên PowerShell và bash, bọc cả chuỗi trong dấu nháy đơn để shell không đụng vào. Riêng tệp .bat của Windows, dấu % có nghĩa riêng nên phải viết đôi thành %%40 và %%23.

Bỏ qua proxy với --proxy-bypass

Tham số --proxy-bypass nhận danh sách quy tắc cách nhau bằng dấu phẩy. Tài liệu ghi có thể bỏ dấu sao ở đầu và cuối, nên *.mycorp.com và .mycorp.com như nhau. Mình thử hai cách: ghi đúng shop.test, và ghi *.test. Cả hai đều làm request đi thẳng, thấy rõ qua lỗi DNS vì shop.test chỉ phân giải được qua proxy.

Một điều dễ bỏ sót: TestCafe không tự bỏ qua localhost. Trong lần thử gọi API, trang khởi đầu 127.0.0.1:8911 cũng đi qua proxy và xuất hiện trong nhật ký. Nếu ứng dụng đang kiểm chạy trên máy cục bộ hay trong mạng nội bộ, hãy thêm localhost, 127.0.0.1 và tên miền nội bộ vào --proxy-bypass. Không thì proxy bên ngoài sẽ nhận request tới một địa chỉ nó không với tới được.

Cấu hình TestCafe proxy bằng tệp .testcaferc.json và API

Tệp cấu hình

Khi dự án có nhiều người chạy, ghi proxy vào tệp cấu hình của TestCafe gọn hơn gõ tham số mỗi lần. Hai khóa tương ứng là proxy và proxyBypass, giá trị giống hệt dòng lệnh.

{
  "disableNativeAutomation": true,
  "proxy": "qa_user:p%40ss%232026@127.0.0.1:8912",
  "proxyBypass": ["localhost", "127.0.0.1"]
}

Mình đặt tệp này cạnh tệp test rồi chạy không kèm tham số nào. TestCafe đọc tệp, request tới shop.test đi qua proxy với tài khoản đúng, test đạt. Tệp cấu hình hợp với giá trị cố định như danh sách bypass. Mật khẩu thì không nên nằm ở đây, phần dưới nói cách tách ra.

runner.useProxy trong mã Node

Nếu chạy TestCafe bằng mã Node, hàm runner.useProxy nhận chuỗi proxy và danh sách bypass. Đoạn dưới đây mình đã chạy thật, đọc tài khoản từ biến môi trường rồi tự mã hóa:

const createTestCafe = require('testcafe');
 
(async () => {
    const testcafe = await createTestCafe({ hostname: '127.0.0.1', port1: 1337, port2: 1338 });
    try {
        const user = encodeURIComponent(process.env.PROXY_USER);
        const pass = encodeURIComponent(process.env.PROXY_PASS);
        const failed = await testcafe.createRunner()
            .src('tests/')
            .browsers('chrome:headless')
            .useProxy(`${user}:${pass}@${process.env.PROXY_HOST}`, ['localhost', '127.0.0.1'])
            .run({ disableNativeAutomation: true });
        console.log('So test loi:', failed);
    } finally {
        await testcafe.close();
    }
})();

Trong lần chạy thử, mình thay chrome:headless bằng một kết nối trình duyệt từ xa vì lý do nói ở phần sau. Kết quả: một test đạt, nhật ký proxy ghi đúng một request tới shop.test với tài khoản đúng. Đặt encodeURIComponent ngay trong mã là cách chắc ăn nhất, vì người khác đổi mật khẩu sau này không cần nhớ quy tắc mã hóa.

Không ghi mật khẩu vào kho mã

Chuỗi proxy có mật khẩu dễ lọt vào kho Git qua tệp .testcaferc.json hoặc tệp package.json có sẵn lệnh chạy. Cách an toàn là để tệp cấu hình giữ phần không bí mật, còn mật khẩu đưa vào qua biến môi trường như đoạn mã trên. Trên máy chủ CI, dùng mục secret của hệ thống CI thay vì ghi thẳng vào tệp cấu hình pipeline.

Nhớ rằng TestCafe in toàn bộ dòng lệnh khi có lỗi tham số. Nếu mật khẩu nằm trên dòng lệnh, nó có thể hiện trong nhật ký CI. Đọc từ biến môi trường trong mã Node tránh được chuyện này.

Lỗi TestCafe proxy khi khai sai chuỗi kết nối

Mọi lỗi dưới đây có chung một dấu hiệu: TestCafe báo không tải được trang, kèm dòng Failed to load the page at và một đoạn Error details. Phần quan trọng nằm sau Error details, phần trên chỉ là lời khuyên chung.

Failed to connect to the proxy host at "ss"

Đây là lỗi mình gặp khi viết mật khẩu p@ss#2026 không mã hóa. TestCafe không báo sai mật khẩu, mà báo không nối được tới một máy tên ss. Lý do nằm ở cách đọc URL: dấu # bắt đầu phần đuôi của URL nên mọi thứ phía sau bị cắt. Phần còn lại là qa_user:p@ss, trong đó ss bị hiểu thành tên máy.

Nhật ký proxy không ghi gì trong lần chạy này, vì request chưa từng tới proxy. Nhìn thấy tên máy lạ trong thông báo, gần như chắc là mật khẩu có ký tự đặc biệt chưa mã hóa. Sửa bằng cách mã hóa như phần trên.

Biến thể khác: mật khẩu chỉ có @ mà không có #. Khi đó cách tách vẫn sai nhưng có thể ra tên máy khác, hoặc ra đúng máy nhưng tài khoản bị cắt cụt và proxy trả 407. Cả hai trường hợp đều xử lý bằng mã hóa phần trăm.

Failed to connect to the proxy host at "http"

Lỗi này xuất hiện khi mình ghi --proxy http://qa_user:[email protected]:8912, giống thói quen của curl hay requests. TestCafe tự thêm http:// phía trước, nên chuỗi thành http://http://... và chữ http bị hiểu là tên máy. Bỏ tiền tố đi là chạy.

Lỗi này hay gặp khi đội kiểm thử dùng chung một biến môi trường HTTP_PROXY cho nhiều công cụ. curl và Python cần tiền tố, TestCafe thì không. Nếu muốn dùng chung, cắt tiền tố trong mã Node trước khi truyền vào useProxy.

Failed to connect to the proxy host at "socks5"

Ghi socks5://... cho kết quả tương tự, tên máy thành socks5. Hammerhead chỉ biết nói chuyện với proxy HTTP: request http gửi kèm địa chỉ đầy đủ, request https mở đường hầm bằng CONNECT. Mình không thấy nhánh nào cho SOCKS trong mã nguồn bản 3.7.6. Proxy SOCKS5 cùng tài khoản trên cổng 8913 không nhận được kết nối nào.

Nếu nhà cung cấp chỉ cấp SOCKS5, anh em có hai hướng. Một là hỏi xem gói đó có cổng HTTP song song không, nhiều nhà cung cấp mở cả hai. Hai là chạy một chương trình chuyển đổi SOCKS sang HTTP trên máy kiểm thử rồi trỏ TestCafe vào cổng HTTP cục bộ. Bài proxy HTTP và SOCKS5 giải thích khác biệt giữa hai loại.

Mã hóa @ thành %40, # thành %23

Lỗi TestCafe proxy về xác thực và cổng

Failed to authorize to the proxy

Lỗi này mình gặp trong hai lần. Lần đầu không ghi tài khoản, nhật ký proxy ghi request tới shop.test không có tiêu đề xác thực. Lần hai ghi sai mật khẩu, nhật ký ghi có tiêu đề, tên qa_user, nhưng xác thực thất bại. Cả hai lần proxy đều trả mã 407 Proxy Authentication Required, và TestCafe dịch mã này thành dòng Failed to authorize to the proxy at "127.0.0.1:8912".

Thông báo không nói rõ thiếu hay sai tài khoản. Kiểm theo thứ tự: chuỗi proxy có phần user:pass@ chưa, mật khẩu đã mã hóa chưa, tài khoản còn hạn không, và gói proxy có giới hạn IP được dùng không. Bài sửa lỗi 407 Proxy Authentication Required liệt kê thêm nguyên nhân phía nhà cung cấp.

Proxy chỉ cho phép theo IP thì không cần tài khoản. Lúc đó lỗi 407 thường có nghĩa IP máy chạy test chưa nằm trong danh sách cho phép. Máy CI đổi IP mỗi lần chạy là nguồn gốc quen thuộc của lỗi này.

Failed to connect to the proxy host at "127.0.0.1:8999"

Khi mình trỏ vào cổng 8999 không có gì nghe, TestCafe báo đúng địa chỉ và cổng. Khác với lỗi "ss" hay "http" ở trên, ở đây tên máy là địa chỉ thật, nghĩa là chuỗi được tách đúng nhưng không có ai trả lời. Nguyên nhân thường là gõ nhầm cổng, proxy đã tắt, hoặc tường lửa chặn chiều ra tới cổng đó.

Kiểm nhanh bằng một lệnh curl từ cùng máy, ví dụ curl -x http://user:pass@máy:cổng https://example.com -I. Nếu curl cũng không nối được thì vấn đề nằm ở mạng hoặc proxy, không phải TestCafe.

Bảng tra nhanh thông báo lỗi

Bảng: Bảng tra nhanh thông báo lỗi

Thông báo sau Error details	Nguyên nhân thường gặp	Cách sửa
Failed to connect to the proxy host at "ss"	Mật khẩu có @ hoặc # chưa mã hóa	Mã hóa phần trăm tên và mật khẩu
Failed to connect to the proxy host at "http"	Chuỗi proxy có tiền tố http://	Bỏ tiền tố, chỉ ghi user:pass@máy:cổng
Failed to connect to the proxy host at "socks5"	Dùng proxy SOCKS	Đổi sang cổng HTTP của nhà cung cấp
Failed to authorize to the proxy	Thiếu hoặc sai tài khoản, IP chưa được cho phép	Kiểm tài khoản, danh sách IP
Failed to connect to the proxy host at "máy:cổng"	Sai cổng, proxy tắt, tường lửa	Thử bằng curl cùng máy
Failed to find a DNS-record for the resource	Request đi thẳng, không qua proxy	Kiểm native automation và proxyBypass
Failed to complete a request ... within the timeout period	Proxy chậm hơn pageRequestTimeout	Tăng thời gian chờ hoặc đổi proxy

Lỗi TestCafe proxy do DNS, thời gian chờ và bypass

Failed to find a DNS-record

Mình gặp lỗi này ở ba lần chạy: không khai proxy, bypass đúng shop.test, và bypass *.test. Cả ba có chung một điểm, request tới shop.test đi thẳng và máy kiểm thử không phân giải được tên này. Nhật ký proxy trống ở cả ba lần.

Ngoài đời, website thật vẫn phân giải được nên anh em sẽ không thấy lỗi DNS. Test sẽ chạy và đạt, chỉ là đi bằng IP của máy. Đó là lý do mình khuyên luôn có một test kiểm đường đi, nói ở phần sau. Lỗi DNS chỉ xuất hiện khi tên miền đích là tên nội bộ mà chỉ proxy biết, hoặc khi DNS của máy kiểm thử bị chặn.

Nếu ứng dụng thật chỉ phân giải được trong mạng công ty, lỗi này là dấu hiệu rõ: proxy không được dùng. Kiểm lần lượt native automation, danh sách proxyBypass và tệp cấu hình có bị tệp khác ghi đè không.

Proxy chậm và pageRequestTimeout

Mình dựng proxy thứ hai, cố ý chờ 8 giây trước khi trả lời. Chạy với --page-request-timeout 3000, TestCafe báo Failed to complete a request to "http://shop.test:8911/landing..." within the timeout period. Thông báo còn gợi ý vấn đề ở mạng cục bộ hay tường lửa, dễ làm anh em đi sai hướng. Nhật ký proxy vẫn ghi đã nhận request, tức là proxy có nhận nhưng trả lời quá muộn.

Chạy lại với --page-request-timeout 20000, test đạt sau khoảng 8 giây. Mặc định của TestCafe là 25000 ms theo tài liệu dòng lệnh, nên proxy chậm 8 giây vẫn qua nếu không ai hạ con số này. Lỗi chủ yếu đến từ dự án đặt thời gian chờ thấp để test nhanh.

Trang tài liệu cũng ghi pageRequestTimeout không áp dụng khi bật native automation. Thêm một lý do để tắt chế độ này khi cần proxy. Nếu proxy chậm không ổn định, cờ --retry-test-pages cho TestCafe tải lại trang lỗi trước khi đánh rớt test.

Selector báo không tìm thấy phần tử

Ở mọi lần proxy lỗi, TestCafe in hai lỗi. Lỗi số 1 là Selector không khớp phần tử nào, lỗi số 2 mới là Failed to load the page. Người đọc lướt hay dừng ở lỗi số 1 rồi đi sửa selector, mất thời gian vô ích.

Quy tắc đơn giản: khi thấy lỗi selector, kéo xuống xem có dòng Failed to load the page không. Nếu có, trang chưa từng tải được, selector không có lỗi gì. Mình thấy địa chỉ trình duyệt lúc đó là 127.0.0.1:1337/mã-phiên/about:error, tức Hammerhead đã đưa trình duyệt sang trang lỗi.

TestCafe proxy với native automation và trình duyệt từ xa

Vì sao --proxy bị bỏ qua

Như đã nói ở đầu, native automation không đi qua Hammerhead, nên tham số --proxy không có chỗ để áp dụng. Trường hợp đáng sợ nhất là test vẫn đạt. Đội kiểm thử tưởng đã kiểm giao diện ở vùng khác, trong khi mọi request đi bằng IP văn phòng.

Cách phòng: trong dự án dùng proxy, ghi "disableNativeAutomation": true vào tệp cấu hình thay vì nhớ thêm cờ mỗi lần. Thêm một test kiểm IP ra như phần sau để phát hiện ngay khi ai đó bỏ cấu hình này.

Chạy trình duyệt từ xa

Chế độ remote cho phép trình duyệt ở máy khác, điện thoại hay máy ảo mở một đường dẫn để nhận test. Lệnh testcafe remote in ra dòng Connect URL, trình duyệt nào mở địa chỉ đó sẽ thành trình duyệt chạy test. Native automation không hỗ trợ trình duyệt từ xa, nên ở chế độ này proxy luôn đi qua Hammerhead.

Điều cần nhớ: với trình duyệt từ xa, proxy được dùng bởi máy chạy TestCafe, không phải thiết bị của trình duyệt. Điện thoại chỉ nói chuyện với máy chạy TestCafe qua cổng 1337 và 1338. Nếu điện thoại ở mạng khác, cần --hostname là địa chỉ mà điện thoại với tới được.

Cannot establish one or more browser connections

Trên máy thử, lệnh testcafe "chrome:headless" và "edge:headless" đều dừng sau 2 phút với lỗi Cannot establish one or more browser connections. Lỗi này xảy ra cả khi không dùng proxy, nên không phải lỗi proxy. Mình vẫn ghi lại vì nó hay bị đổ cho proxy.

Mình xử lý bằng chế độ remote: chạy testcafe remote, sau đó mở Edge không giao diện tới Connect URL bằng một script riêng. Từ đó mọi lần chạy đều kết nối được. Nếu anh em gặp lỗi này, thử chạy không kèm proxy trước. Không kèm proxy mà vẫn lỗi thì xem lại cách trình duyệt được khởi chạy, quyền chạy trình duyệt, phần mềm bảo mật, và tăng --browser-init-timeout.

Native automation bỏ qua --proxy

Kiểm TestCafe proxy có đi đúng đường không

Trang kiểm tra phía đích

Cách chắc nhất là có một trang phía đích trả lại thông tin request nó nhận được. Mình dùng một trang thử in ra đường dẫn, IP client và một tiêu đề do proxy gắn thêm. Test đọc nội dung trang rồi so với giá trị mong đợi:

import { Selector } from 'testcafe';
 
fixture('Kiem duong di qua proxy')
    .page('http://shop.test:8911/landing');
 
test('trang dich di qua proxy', async t => {
    const data = JSON.parse(await Selector('#data').innerText);
    await t.expect(data.via).eql('http-proxy');
});

Với proxy thật, anh em thay trang thử bằng một dịch vụ trả về IP công khai, rồi so IP đó với IP mong đợi hoặc quốc gia mong đợi. Đặt test này chạy đầu tiên trong bộ test. Nếu nó rớt, các test giao diện phía sau không còn ý nghĩa.

Với dự án kiểm nội dung theo vùng, bài kiểm thử website theo khu vực bàn kỹ cách lập ma trận vùng. Ở đây chỉ cần nhớ: kiểm IP ra trước, kiểm giao diện sau.

t.request cũng đi qua proxy

TestCafe có hàm t.request để gọi API trực tiếp từ test, thường dùng tạo dữ liệu mẫu hay kiểm phản hồi API. Mình thử gọi http://api.test:8911/api/stock?sku=A1 bằng t.request khi có --proxy. Kết quả trả 200, nhật ký proxy ghi đúng request kèm tài khoản.

Nghĩa là API gọi trong test và trang mở trên trình duyệt dùng chung một proxy. Đây là điểm cộng khi kiểm hệ thống phân luồng theo vùng: dữ liệu tạo qua API và giao diện cùng nhìn từ một IP. Nếu muốn API nội bộ đi thẳng, thêm tên máy API vào proxyBypass.

Có một chi tiết nhỏ: trang thử ghi tiêu đề User-Agent rỗng cho request của t.request. Request trang thì mang User-Agent của Edge. Website nào chặn request không có User-Agent sẽ cư xử khác giữa hai loại này, nên đừng lấy kết quả t.request để suy ra kết quả của trang.

HTTPS đi bằng CONNECT

Với https://example.com, nhật ký proxy ghi hai lệnh CONNECT tới example.com:443 có tài khoản đúng. Test đọc được tiêu đề trang Example Domain. Proxy chỉ thấy tên máy và cổng, không thấy đường dẫn hay nội dung, vì TLS đi xuyên qua đường hầm.

Lần thử đầu, test HTTPS của mình rớt với lỗi Selector không tìm thấy thẻ h1, dù không có dòng Failed to load the page. Kiểm lại thì trang tải bình thường, chỉ là nội dung trang không khớp selector mình đoán. Bài học: khi không có lỗi tải trang, proxy đã làm xong việc, hãy kiểm lại selector.

Nếu proxy công ty giải mã HTTPS, Hammerhead sẽ gặp chứng chỉ do thiết bị trong công ty cấp. Lúc đó cần đưa chứng chỉ gốc của công ty vào Node qua biến NODE_EXTRA_CA_CERTS. Phần này mình chưa thử trên máy.

TestCafe proxy trong CI và chạy song song

Biến môi trường trong pipeline

Trên máy CI, cách gọn là lưu ba giá trị PROXY_HOST, PROXY_USER, PROXY_PASS vào secret của hệ thống CI, rồi dùng script Node có useProxy như trên. Script tự mã hóa nên người cấu hình CI chỉ dán mật khẩu gốc. Không ai phải nhớ quy tắc %40 hay %23.

Nhớ rằng nhiều máy CI dùng chung chạy trong container, có thể đã có sẵn biến HTTP_PROXY của công ty. TestCafe không đọc biến này cho --proxy, nhưng các công cụ khác trong cùng pipeline như npm hay curl thì có. Bài proxy Docker mô tả cách các lớp proxy chồng lên nhau trong container.

Máy CI trên đám mây đổi IP thường xuyên. Nếu gói proxy chỉ cho phép theo IP, lỗi 407 sẽ đến sớm thôi. Chọn gói proxy xác thực bằng tài khoản cho môi trường CI.

Nhiều trình duyệt chung một proxy

Khi chạy song song bằng tham số -c hay nhiều trình duyệt cùng lúc, mọi phiên đều đi qua một tiến trình TestCafe và dùng chung chuỗi proxy. Proxy sẽ thấy nhiều kết nối đồng thời từ một tài khoản. Gói proxy giới hạn số luồng sẽ bắt đầu từ chối khi vượt ngưỡng, thường dưới dạng 407 hoặc ngắt kết nối giữa chừng.

Trước khi tăng -c, hỏi nhà cung cấp hạn mức kết nối đồng thời của gói. Nếu proxy xoay IP theo kết nối, các trình duyệt chạy song song có thể ra các IP khác nhau ngay trong một test. Với test cần giữ phiên đăng nhập, chọn proxy giữ IP theo thời gian.

Đổi proxy theo vùng

Một tiến trình TestCafe chỉ nhận một chuỗi proxy. Muốn chạy cùng bộ test qua ba vùng, cách đơn giản là chạy ba lần với ba chuỗi proxy khác nhau, mỗi lần ghi kết quả ra một tệp báo cáo riêng. Trong mã Node, vòng lặp qua danh sách proxy rồi gọi createRunner cho từng proxy là đủ.

Mình không khuyên đổi proxy giữa chừng trong một lần chạy. Cookie và bộ nhớ phiên của Hammerhead gắn với phiên test, đổi proxy giữa chừng làm website thấy một người dùng nhảy vùng, dễ kích hoạt cơ chế chống gian lận.

Khi tải lớn hơn mức kiểm giao diện, đó đã là bài toán khác. Bài proxy cho load testing JMeter phù hợp hơn TestCafe cho việc tạo tải.

So sánh TestCafe proxy với Playwright và Cypress

Khác nhau ở chỗ ai nói chuyện với proxy

Với TestCafe ở chế độ cổ điển, tiến trình Node nói chuyện với proxy, trình duyệt không biết gì. Với Playwright, proxy khai báo khi khởi chạy trình duyệt hoặc khi tạo context, và chính trình duyệt gửi request qua proxy. Cypress cũng chạy trình duyệt qua một máy chủ trung gian của nó, và tài liệu Cypress hướng dẫn khai proxy qua biến môi trường HTTP_PROXY.

Hệ quả thực tế: ở TestCafe, mọi lỗi proxy hiện trong báo cáo test với dòng Error details. Ở Playwright, lỗi proxy thường hiện thành lỗi điều hướng của trình duyệt như net::ERR_PROXY_CONNECTION_FAILED. Bài proxy Playwright và bài Cypress proxy có hướng dẫn riêng cho hai công cụ đó.

Chọn công cụ theo việc

Nếu dự án đã viết test bằng TestCafe, chỉ cần thêm proxy để kiểm vùng, cứ giữ TestCafe, tắt native automation và dùng proxy HTTP. Nếu cần SOCKS5 hoặc cần mỗi context một proxy khác nhau trong cùng lần chạy, Playwright linh hoạt hơn. Đừng đổi công cụ chỉ vì một tình huống proxy, chi phí viết lại test thường lớn hơn nhiều.

Câu hỏi thường gặp về TestCafe proxy

TestCafe có hỗ trợ proxy SOCKS5 không. Trong lần thử bản 3.7.6, chuỗi socks5:// bị đọc thành tên máy socks5 và không có kết nối nào tới proxy SOCKS. Dùng proxy HTTP hoặc cổng HTTP song song của nhà cung cấp.

Vì sao test vẫn đạt mà IP không đổi. Thường do native automation đang bật với Chrome hoặc Edge, khi đó --proxy không áp dụng. Thêm --disable-native-automation và một test kiểm IP ra.

Mật khẩu có ký tự @ thì ghi thế nào. Mã hóa phần trăm: @ thành %40, # thành %23. Trong Node dùng encodeURIComponent cho cả tên và mật khẩu.

Có cần ghi http:// trước chuỗi proxy không. Không. TestCafe tự thêm, ghi thêm sẽ ra lỗi Failed to connect to the proxy host at "http".

t.request có dùng proxy không. Có. Trong lần thử, request của t.request đi qua proxy với cùng tài khoản như trang.

Có cần đưa localhost vào proxyBypass không. Có, nếu ứng dụng chạy cục bộ. TestCafe không tự bỏ qua 127.0.0.1, request tới đó vẫn gửi cho proxy.

Proxy chậm thì chỉnh gì. Tăng --page-request-timeout, mặc định 25000 ms. Nếu proxy chập chờn, thêm --retry-test-pages.

Khi cần proxy HTTP có tài khoản riêng cho máy kiểm thử và CI, anh em có thể mua proxy uy tín tại trang chủ ProxyVN rồi chạy test kiểm IP ở trên trước khi đưa vào bộ test chính.

Kiểm TestCafe proxy trước khi chạy test

TestCafe proxy và những điều cần nhớ

TestCafe proxy chỉ chạy khi native automation tắt, nhận chuỗi user:pass@máy:cổng không có tiền tố, mật khẩu phải mã hóa phần trăm. Tên máy lạ trong lỗi là dấu hiệu chuỗi bị tách sai. Không hỗ trợ SOCKS, không tự bỏ qua localhost. Cần IP ổn định cho TestCafe proxy, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.