Lỗi proxy Apify: Actor báo 407, ECONNREFUSED và chạy không proxy

Lỗi proxy Apify khó ở chỗ không phải lỗi nào cũng hiện ra. Có lỗi làm Actor thử lại mười lần trong một giây, có lỗi làm Actor chạy thẳng không qua proxy mà chỉ để lại một dòng cảnh báo. ProxyVN chạy Actor trên máy với Apify SDK 3.7.2 và Crawlee 3.18.2 qua một proxy có mật khẩu, ghi đúng thông báo và đếm số kết nối proxy thật sự nhận.

Lỗi proxy Apify thường gặp và bảng tra nhanh

Lỗi proxy trong Actor Apify rơi vào năm nhóm: sai tài khoản hoặc sai cổng, sai định dạng danh sách proxyUrls, trộn proxy riêng với Apify Proxy, proxy treo, và Actor chạy không qua proxy. Nhóm cuối không có thông báo lỗi nào, nên nguy hiểm nhất.

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

Các lỗi "lúc tạo cấu hình" làm Actor dừng ngay khi gọi Actor.createProxyConfiguration, chưa gửi request nào. Các lỗi "lúc crawl" xảy ra khi crawler đã chạy, và Crawlee có thể thử lại nhiều lần trước khi báo.

Đọc thông báo theo giai đoạn

Mình chia lỗi thành ba giai đoạn. Giai đoạn cấu hình: SDK có tạo được đối tượng ProxyConfiguration không. Giai đoạn kết nối: crawler có tới được proxy và qua được bước xác thực không. Giai đoạn dữ liệu: website có trả đúng trang cần lấy không.

Lỗi ở giai đoạn sau không bao giờ sửa được bằng cách đổi thứ ở giai đoạn trước. Một trang 403 từ website không liên quan tới cú pháp proxyUrls, và một lỗi ArgumentError không liên quan tới chất lượng proxy. Đọc đúng giai đoạn giúp khỏi đổi proxy vô ích. Nếu cần nền tảng về các nhóm proxy của Apify trước, anh em đọc bài Apify proxy của ProxyVN. Bài này đi thẳng vào phần lỗi.

Môi trường tái hiện lỗi proxy Apify

Mọi thông báo trong bài lấy từ lần chạy ngày 26/10/2026 trên Windows 11 với Node.js 24.20.0, apify 3.7.2, crawlee 3.18.2 và CheerioCrawler. Actor chạy trên máy, không lên nền tảng Apify, nên không cần tài khoản để dùng proxy riêng.

Proxy thử nghiệm và cách đếm kết nối

Proxy thử nghiệm là một script Python nhỏ chạy trên máy, cổng 18080, yêu cầu tài khoản u1 với mật khẩu p@ss:w0rd. Cổng 18081 nhận kết nối rồi im lặng để tái hiện proxy treo, cổng 18099 không có gì chạy để tái hiện sai cổng. Đích crawl là https://example.com/.

Proxy ghi từng lệnh CONNECT vào nhật ký kèm trạng thái tài khoản. Nhờ vậy mình đếm được Crawlee thật sự mở bao nhiêu kết nối, điều mà thông báo lỗi cuối cùng không cho biết. Đây là cách phát hiện vòng xoay phiên ngầm ở phần dưới.

Giới hạn của lần chạy trên máy

Chạy local khác chạy trên cloud ở hai điểm: địa chỉ IP nguồn và cách nạp thông tin Apify Proxy. Các lỗi về cú pháp, xác thực, xoay phiên và timeout giống nhau ở hai nơi, vì cùng mã SDK và Crawlee. Phần lỗi riêng của cloud ở cuối bài dựa trên tài liệu chính thức, mình ghi rõ chỗ nào chưa chạy thử.

Lỗi proxy Apify khi sai tài khoản hoặc sai cổng

Đây là nhóm lỗi gặp nhiều nhất, và cũng là nhóm có hành vi bất ngờ nhất. Crawlee không coi 407 là lỗi thường mà coi là lỗi phiên.

407 kèm dòng rotating session

Với mật khẩu sai, failedRequestHandler nhận lỗi "Detected a session error, rotating session... Proxy responded with 407 Proxy Authentication Required: 0 bytes". Lỗi hiện sau khoảng 1 giây, request có retryCount bằng 10. Nhật ký proxy ghi 11 lệnh CONNECT, tất cả với tài khoản sai, tất cả trong cùng một giây.

Mình đặt maxRequestRetries bằng 0 rồi chạy lại. Kết quả không đổi: vẫn 11 CONNECT, retryCount vẫn 10. Lý do là Crawlee xếp 407 vào nhóm lỗi phiên, và lỗi phiên được thử lại theo một giới hạn khác là maxSessionRotations, mặc định 10. maxRequestRetries chỉ áp cho lỗi thường.

ECONNREFUSED cũng bị xoay phiên

Với cổng 18099 không có gì chạy, thông báo là "Detected a session error, rotating session... connect ECONNREFUSED 127.0.0.1:18099", retryCount cũng bằng 10. Crawlee xếp lỗi không nối được proxy vào cùng nhóm lỗi phiên với 407.

Với một proxy hỏng, mười lần xoay phiên không giúp gì. Danh sách proxyUrls chỉ có một URL, nên mỗi phiên mới vẫn đi qua đúng proxy hỏng đó. Bài lỗi ERR_CONNECTION_REFUSED có thêm nguyên nhân phía mạng khi gặp ECONNREFUSED.

ENOTFOUND khi sai tên máy chủ proxy

Một số nhà cung cấp cấp proxy bằng tên miền thay vì IP. Gõ sai tên đó, lỗi là RequestError: getaddrinfo ENOTFOUND proxy.khong-ton-tai.invalid, sau 1,3 giây, retryCount bằng 3. Lần này Crawlee không gọi là lỗi phiên mà thử lại theo maxRequestRetries mặc định.

Hai lỗi cùng là không tới được proxy nhưng đi theo hai đường thử lại khác nhau. ECONNREFUSED bị xoay phiên 10 lần, ENOTFOUND thử lại 3 lần. Đặt cả maxSessionRotations lẫn maxRequestRetries thì mới kiểm soát được tổng số lần gọi. Từ khóa getaddrinfo nghĩa là máy không đổi được tên proxy ra IP, kiểm tra chính tả tên proxy trước tiên.

Đích HTTP: 407 biến thành lỗi Content-Type

Với đích HTTP không mã hóa, crawler gửi request thẳng tới proxy, không có bước CONNECT. Mật khẩu sai, proxy trả 407 như một response bình thường. Crawlee không báo 407. Thông báo nhận được là Resource http://example.com/ served Content-Type application/octet-stream, but only text/html, text/xml... are allowed. Skipping resource.

Đọc thông báo này, ai cũng tưởng website trả sai kiểu nội dung. Nhật ký proxy mới cho thấy sự thật: đúng một request GET với tài khoản sai. Gặp lỗi Content-Type lạ khi crawl trang HTTP qua proxy, mình kiểm tra tài khoản proxy trước khi đi sửa bộ lọc nội dung.

Chặn vòng thử bằng maxSessionRotations

Đặt maxSessionRotations bằng 0 trong CheerioCrawler, lỗi 407 dừng ngay sau 1 lệnh CONNECT, retryCount bằng 0. Đặt bằng 2, nhật ký ghi đúng 3 lệnh CONNECT. Đây là tham số mình đặt nhỏ trong mọi lần chạy thử, để lỗi tài khoản hiện ra ngay thay vì bị nhân lên.

Với proxy tính tiền theo request hay theo lưu lượng, vòng xoay ngầm này làm số lần gọi lớn hơn hẳn số URL trong hàng đợi. Nó còn có thể làm nhà cung cấp tạm khóa tài khoản vì đăng nhập sai liên tục. Tài liệu tùy chọn của BasicCrawler mô tả maxSessionRotations cùng các tham số retry khác.

Schema quyết định ô proxy

Khi gặp 407, kiểm tra user và mật khẩu, hạn của gói, và kiểu xác thực của nhà cung cấp. Nếu proxy xác thực theo IP được phép, IP của máy chạy Actor phải nằm trong danh sách. Bài sửa lỗi 407 Proxy Authentication Required có thêm các trường hợp phía nhà cung cấp.

Lỗi proxy Apify do định dạng proxyUrls

proxyUrls là mảng các URL đầy đủ, dạng http://user:pass@host:port. Phần lớn lỗi định dạng đến từ việc dán nguyên chuỗi nhà cung cấp gửi mà không chuyển đổi.

Dạng ip:port:user:pass bị từ chối ngay

Dán 127.0.0.1:18080:u1:p@ss:w0rd vào proxyUrls, Actor.createProxyConfiguration ném ArgumentError: (array proxyUrls) Any predicate failed with the following errors: Expected property string values to be a URL. Lỗi xảy ra trước khi gửi request nào, nên dễ sửa. Bài định dạng proxy liệt kê các kiểu viết hay gặp và cách đổi sang URL.

Thông báo lỗi in nguyên chuỗi đã dán, kể cả mật khẩu. Nếu log của Actor được chia sẻ cho người khác, mật khẩu proxy đi theo. Mình kiểm tra định dạng trước khi gọi createProxyConfiguration để lỗi không in ra thông tin nhạy cảm.

Thiếu http:// ra thông báo khó hiểu

Dán u1:sai@127.0.0.1:18080, tức thiếu tiền tố http://, SDK không báo lỗi lúc tạo cấu hình. Lỗi chỉ hiện lúc crawl: Proxy URL protocol "u1:" is not supported. Please use HTTP or HTTPS. Trình phân tích URL coi phần trước dấu hai chấm đầu tiên là giao thức, nên user trở thành tên giao thức.

Lần chạy này còn bị thử lại 3 lần theo maxRequestRetries mặc định trước khi báo lỗi. Thấy giao thức lạ như "u1:" trong thông báo là biết ngay URL thiếu http://.

socks5 không chạy với CheerioCrawler

Dán socks5://u1:x@127.0.0.1:18080, lỗi lúc crawl là Proxy URL protocol "socks5:" is not supported. Please use HTTP or HTTPS. CheerioCrawler gửi request bằng thư viện HTTP riêng, và trong lần chạy này thư viện đó chỉ nhận proxy HTTP hoặc HTTPS.

Khi nhà cung cấp cấp cả hai giao thức, dùng cổng HTTP cho Actor. Bài proxy HTTP và SOCKS5 giải thích khác biệt giữa hai giao thức. Crawler dùng trình duyệt như PlaywrightCrawler có cách xử lý proxy khác, cần thử riêng trước khi dùng SOCKS5.

https:// cho proxy HTTP thì treo

Nhiều người nghĩ đích là HTTPS thì URL proxy cũng phải là https://. Dán https://u1:sai@127.0.0.1:18080 cho proxy HTTP thử nghiệm, Actor không báo lỗi giao thức nào. Nó treo đúng 30 giây rồi báo request timed out after 30 seconds, và nhật ký proxy không có dòng CONNECT nào.

Tiền tố https:// trong URL proxy nghĩa là crawler bắt tay TLS với chính proxy trước. Proxy HTTP thường không nói TLS, nên chỉ nhận một chuỗi byte khó hiểu và ngồi chờ. Proxy HTTP thường vẫn mở được đường hầm tới website HTTPS bằng lệnh CONNECT, nên URL proxy để http:// là đúng. Chỉ dùng https:// khi nhà cung cấp ghi rõ proxy của họ nhận kết nối TLS.

Mật khẩu có ký tự đặc biệt

Dán mật khẩu p@ss:w0rd chưa mã hóa vào URL, lần chạy này vẫn thành công với 200 và nhật ký ghi tài khoản đúng. Trình phân tích URL của Node lấy dấu @ cuối cùng làm ranh giới. Nhưng mình không dựa vào may mắn đó: mật khẩu có dấu thăng, dấu gạch chéo hay dấu hỏi sẽ làm URL vỡ ở chỗ khác.

Cách an toàn là mã hóa riêng mật khẩu bằng encodeURIComponent trước khi ghép. Với p@ss:w0rd, chuỗi mã hóa là p%40ss%3Aw0rd, và Crawlee gửi đúng tài khoản. Danh sách proxyUrls rỗng thì ném ArgumentError: Expected property array proxyUrls to not be empty, nên kiểm tra số phần tử trước.

Hàm chuẩn hóa danh sách proxy

Thay vì sửa tay từng dòng, mình dùng một hàm nhỏ chạy trước createProxyConfiguration. Hàm nhận danh sách dòng như nhà cung cấp gửi, bỏ dòng trống và null, đổi dạng ip:port:user:pass sang URL có mật khẩu đã mã hóa, và chặn giao thức không phải http. Lỗi chỉ ghi số dòng, không in lại chuỗi có mật khẩu.

export function chuanHoaProxy(dong) {
  const ketQua = [];
  for (const [i, raw] of dong.entries()) {
    const s = (raw ?? '').trim();
    if (!s) continue;
    if (s.includes('://')) {
      const u = new URL(s);
      if (u.protocol !== 'http:') throw new Error(`Dong ${i + 1}: khong dung giao thuc ${u.protocol}`);
      ketQua.push(u.href);
      continue;
    }
    const [host, port, user, ...pass] = s.split(':');
    if (!host || !/^\d+$/.test(port ?? '')) throw new Error(`Dong ${i + 1}: khong dung dang ip:port:user:pass`);
    const auth = user ? `${encodeURIComponent(user)}:${encodeURIComponent(pass.join(':'))}@` : '';
    ketQua.push(`http://${auth}${host}:${port}`);
  }
  if (ketQua.length === 0) throw new Error('Danh sach proxy rong sau khi loc');
  return ketQua;
}

Chạy thử với ba dòng gồm một dòng trống, dòng 127.0.0.1:18080:u1:p@ss:w0rd và một null, hàm trả đúng một URL http://u1:p%40ss%3Aw0rd@127.0.0.1:18080. Đưa kết quả vào createProxyConfiguration, newUrl trả đúng URL đó. Với dòng socks5 ở vị trí thứ hai, hàm báo Dong 2: khong dung giao thuc socks5:. Với cổng là chữ, hàm báo sai dạng.

Phần mật khẩu được nối lại bằng dấu hai chấm sau khi tách, nên mật khẩu có dấu hai chấm vẫn giữ nguyên. Hàm cố ý chặn https:// vì lý do ở mục trên. Nếu nhà cung cấp của anh em dùng proxy TLS thật, bỏ điều kiện đó.

Lỗi proxy Apify khi trộn proxy riêng với Apify Proxy

Apify có hai nhánh proxy: Apify Proxy của nền tảng và proxy riêng truyền qua proxyUrls. Hai nhánh không dùng chung tham số.

Cannot combine custom proxies with Apify Proxy

Đặt proxyUrls cùng groups RESIDENTIAL, hoặc cùng countryCode VN, Actor.createProxyConfiguration ném lỗi: Cannot combine custom proxies with Apify Proxy! It is not allowed to set "options.proxyUrls" or "options.newUrlFunction" combined with "options.groups", "options.apifyProxyGroups", "options.countryCode"... Lỗi hiện ngay, chưa gửi request nào.

Lỗi này thường xuất hiện khi anh em sửa một Actor đang dùng Apify Proxy sang proxy riêng nhưng quên xóa groups hay countryCode. countryCode chỉ có nghĩa với Apify Proxy. Muốn proxy riêng ra IP Việt Nam thì chọn proxy Việt Nam từ nhà cung cấp, không đặt countryCode.

Chọn đúng một nhánh trong input

Với Actor trên Store, ô Proxy configuration lưu input dạng một đối tượng có useApifyProxy và proxyUrls. Mình truyền đối tượng useApifyProxy false cùng proxyUrls vào Actor.createProxyConfiguration, SDK tạo cấu hình đúng và newUrl trả URL proxy riêng. Theo hướng dẫn dùng proxy riêng, ô cấu hình này chỉ có ở Actor định nghĩa nó trong schema input.

Không thấy ô proxy trong một Actor không có nghĩa tài khoản bị lỗi. Actor đó có thể không hỗ trợ proxy riêng, hoặc dùng tên trường khác. Đọc phần Input của chính Actor trước khi tự thêm khóa JSON.

Lỗi proxy Apify khiến Actor chạy không qua proxy

Nhóm lỗi này không có exception. Actor chạy, trả dữ liệu, trả 200, nhưng request đi thẳng từ máy chạy Actor. Mình chỉ phát hiện được vì nhật ký proxy trống.

Chạy local không có token

Gọi Actor.createProxyConfiguration với groups RESIDENTIAL trên máy không có biến APIFY_PROXY_PASSWORD hay APIFY_TOKEN, SDK không ném lỗi. Nó in hai dòng WARN: No proxy password or token detected, running without proxy, và Invalid password provided: User not found. Giá trị trả về là undefined.

Truyền undefined vào proxyConfiguration của CheerioCrawler, crawler chạy bình thường không qua proxy. Lần chạy thử trả 200 với tiêu đề Example Domain. Ai tắt log WARN cho gọn sẽ không bao giờ biết Actor đang dùng IP thật. Theo hướng dẫn quản lý proxy của SDK, muốn dùng Apify Proxy khi chạy local phải cấp mật khẩu proxy hoặc token.

Gõ nhầm tên trường cũng ra undefined

Truyền useApifyProxy false cùng proxyUrl, thiếu chữ s ở cuối, SDK cũng trả undefined, không có lỗi nào. Khóa sai tên bị bỏ qua, và với useApifyProxy false thì không còn gì để tạo cấu hình. Kết quả giống hệt trường hợp không có token: Actor chạy thẳng.

Phần tử null trong proxyUrls

Crawlee cho phép đặt null trong proxyUrls, nghĩa là request đó không dùng proxy. Đặt proxyUrls bằng một mảng chỉ có null, Actor trả 200 và nhật ký proxy trống. Đặt mảng gồm null và một URL proxy đúng, request đầu tiên cũng đi thẳng, vì vòng luân phiên bắt đầu từ phần tử đầu.

Lỗi này hay gặp khi danh sách proxy được dựng tự động từ một file hay một bảng tính có dòng trống. Dòng trống thành null, và một phần request lặng lẽ đi bằng IP thật. Mình lọc bỏ null và chuỗi rỗng trước khi đưa danh sách vào createProxyConfiguration, trừ khi tác vụ cố ý cần request đi thẳng.

Chặn bằng một dòng kiểm tra

Cách mình chặn các trường hợp trên là kiểm tra giá trị trả về và nội dung danh sách. Nếu Actor.createProxyConfiguration trả undefined trong khi tác vụ bắt buộc đi qua proxy, ném lỗi ngay và dừng Actor. Một dòng kiểm tra rẻ hơn nhiều so với một lần chạy dài bằng IP thật.

Một lần chạy nhỏ có bằng chứng

Lỗi proxy Apify do proxy treo và timeout

Proxy quá tải hay proxy nhận kết nối mà không trả lời tạo ra lỗi timeout. Thời gian chờ quyết định Actor kẹt bao lâu trên mỗi URL.

request timed out after 10 seconds

Với cổng 18081 nhận kết nối rồi im lặng, navigationTimeoutSecs 10 và maxRequestRetries 0, lỗi là "request timed out after 10 seconds", hiện sau 10,8 giây. Nhật ký proxy ghi một kết nối. Lỗi timeout không bị xếp vào nhóm lỗi phiên trong lần chạy này, nên tuân theo maxRequestRetries.

Bỏ maxRequestRetries về mặc định và đặt navigationTimeoutSecs 5, lỗi hiện sau 21 giây với retryCount bằng 3, nhật ký ghi 4 kết nối cách nhau 5 giây. Suy ra với mặc định 30 giây, một proxy treo giữ mỗi URL khoảng hai phút. Nhân với vài nghìn URL, Actor có thể hết giờ chạy trước khi xong việc. Bài lỗi 504 Gateway Timeout giải thích lỗi timeout xảy ra ở phía proxy.

Đặt thời gian chờ theo loại trang

Trang HTML tĩnh qua CheerioCrawler thường xong trong vài giây, mình đặt navigationTimeoutSecs khoảng 20 cho bước kiểm tra. Proxy nào không trả lời trong khoảng đó thì loại khỏi danh sách thay vì chờ lâu hơn. Trang nặng tải qua trình duyệt cần thời gian dài hơn, đo trên vài URL mẫu rồi mới đặt.

Lỗi proxy Apify với session và xoay URL

Session trong Crawlee và session trên gateway của nhà cung cấp là hai thứ khác nhau. Nhầm hai thứ này làm anh em tưởng đang giữ IP trong khi IP vẫn đổi.

newUrl luân phiên và giữ theo session id

Với ba URL a, b, c trong proxyUrls, gọi newUrl bốn lần không truyền session id trả lần lượt a, b, c, a. Gọi newUrl với session id phien_1 hai lần đều trả b. Gọi với phien_2 trả c. SDK luân phiên khi không có session và giữ cố định URL cho cùng session id.

Đây chỉ là ánh xạ trong SDK: cùng session id thì cùng chuỗi URL. Nếu URL đó trỏ tới một gateway xoay, gateway vẫn có thể đổi IP sau mỗi kết nối dù SDK trả cùng chuỗi. Muốn giữ IP thật, phải dùng proxy tĩnh hoặc tham số giữ phiên của chính nhà cung cấp. Bài sticky session proxy là gì giải thích cơ chế giữ phiên phía gateway.

URL phiên khác IP ngoài

Cookie đi theo session

Với tác vụ có đăng nhập, cookie gắn với session của Crawlee. Đổi URL proxy giữa các bước mà giữ nguyên cookie dễ làm website đòi đăng nhập lại, vì cùng một phiên đăng nhập xuất hiện từ hai IP. Mình giữ cùng session id cho cả chuỗi thao tác của một tài khoản. Tài liệu session management của Apify SDK mô tả cách phiên, cookie và proxy đi cùng nhau.

Lỗi proxy Apify khi chạy trên cloud

Phần này dựa trên tài liệu Apify, mình chưa chạy thử trên cloud. Hai lỗi hay gặp khi chuyển Actor từ máy lên nền tảng đều đến từ việc môi trường thay đổi.

localhost không còn là máy của anh em

Trên máy, proxy ở 127.0.0.1 là chính máy đó. Lên cloud, 127.0.0.1 là container của lần chạy. Một proxyUrls trỏ tới localhost chạy tốt trên máy sẽ báo ECONNREFUSED trên cloud. Proxy dùng cho Actor cloud phải là địa chỉ ra được Internet.

IP được phép không còn khớp

Nếu nhà cung cấp xác thực proxy theo IP được phép, IP của máy nhà đã được thêm vào danh sách, nhưng Actor trên cloud ra Internet bằng IP của nền tảng. Kết quả là 407 trên cloud trong khi local vẫn chạy. Dùng xác thực user và password cho Actor cloud thì tránh được lỗi này. Bài IP whitelist hay user password so sánh hai cách xác thực.

Mã kiểm tra lỗi proxy Apify trước khi chạy lô

Trước khi chạy hàng nghìn URL, mình chạy một Actor kiểm tra ngắn. Nó dừng ngay nếu cấu hình không tạo được, giới hạn vòng thử, và in loại lỗi cho từng URL.

Actor chẩn đoán đã chạy thử

Actor đọc proxy từ input dạng Store, hoặc từ biến môi trường PROXY_URLS khi chạy local. Nếu createProxyConfiguration trả undefined, Actor ném lỗi thay vì chạy thẳng. maxSessionRotations và maxRequestRetries đặt bằng 1 để lỗi tài khoản hiện ra sau hai kết nối.

import { Actor } from 'apify';
import { CheerioCrawler } from 'crawlee';
 
await Actor.init();
const input = (await Actor.getInput()) ?? {};
const proxyInput = input.proxyConfiguration ?? {
  useApifyProxy: false,
  proxyUrls: JSON.parse(process.env.PROXY_URLS ?? '[]'),
};
const proxyConfiguration = await Actor.createProxyConfiguration(proxyInput);
if (!proxyConfiguration) {
  throw new Error('Khong tao duoc cau hinh proxy: Actor se chay KHONG qua proxy');
}
const ketQua = [];
const crawler = new CheerioCrawler({
  proxyConfiguration,
  maxConcurrency: 1,
  maxRequestRetries: 1,
  maxSessionRotations: 1,
  navigationTimeoutSecs: 20,
  async requestHandler({ request, response, $ }) {
    ketQua.push(`ok ${response.statusCode} ${request.url} title=${$('title').text().trim()}`);
  },
  failedRequestHandler({ request }, error) {
    const m = String(error.message);
    const loai = /407/.test(m) ? 'proxy_auth' : /ECONNREFUSED|ENOTFOUND/.test(m) ? 'connect'
      : /timed out/.test(m) ? 'timeout' : /protocol/.test(m) ? 'url' : 'khac';
    ketQua.push(`${loai} ${request.url} lan_thu=${request.retryCount}`);
  },
});
await crawler.run([process.env.TARGET_URL ?? 'https://example.com/']);
console.log(ketQua.join('\n'));
await Actor.exit();

Chạy với proxy đúng, kết quả là ok 200 https://example.com/ title=Example Domain. Với mật khẩu sai, kết quả là proxy_auth với lan_thu bằng 1, nhật ký proxy ghi đúng 2 lệnh CONNECT thay vì 11. Với cổng sai, kết quả là connect. Với socks5, kết quả là url. Với danh sách rỗng, Actor dừng ở ArgumentError trước khi crawl.

Đọc kết quả và quyết định

Kết quả proxy_auth thì kiểm tra tài khoản và kiểu xác thực. Kết quả connect thì kiểm tra cổng, địa chỉ và việc proxy có ra được Internet không. Kết quả url thì sửa định dạng proxyUrls. Kết quả timeout thì đổi proxy khác. Kết quả khac thì mở log của lần chạy, đọc nguyên văn thông báo rồi tra lại bảng ở đầu bài. Kết quả ok thì kiểm tra thêm nội dung trang, vì trang chặn hay trang đăng nhập cũng trả 200.

Bàn giao Actor và endpoint

Trước khi mua proxy cho Actor, anh em hỏi rõ có cổng HTTP không, xác thực bằng user và password hay theo IP, và giới hạn kết nối đồng thời. ProxyVN có proxy dân cư tĩnh, datacenter và 4G, dùng HTTP hoặc SOCKS5, cấp user và password riêng, hợp với Actor chạy trên cloud. Bài proxy cho Crawlee có thêm cách cấu hình cho các loại crawler khác.

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

Vì sao đặt maxRequestRetries bằng 0 mà Actor vẫn thử lại 10 lần. Crawlee coi 407 và ECONNREFUSED qua proxy là lỗi phiên, thử lại theo maxSessionRotations, mặc định 10. Đặt maxSessionRotations nhỏ để chặn.

Vì sao Actor chạy được nhưng không qua proxy. Thường do Actor.createProxyConfiguration trả undefined: chạy local không có token Apify, hoặc gõ sai tên trường như proxyUrl. Kiểm tra giá trị trả về và đọc các dòng WARN.

Dùng proxyUrls với countryCode được không. Không. SDK báo Cannot combine custom proxies with Apify Proxy. countryCode chỉ dùng cho Apify Proxy, muốn IP Việt Nam thì chọn proxy Việt Nam từ nhà cung cấp.

CheerioCrawler có dùng được SOCKS5 không. Trong lần chạy với Crawlee 3.18.2, không. Thông báo là Proxy URL protocol "socks5:" is not supported. Dùng cổng HTTP của nhà cung cấp.

Đích là HTTPS thì URL proxy có phải để https:// không. Không. Proxy HTTP mở đường hầm tới website HTTPS bằng lệnh CONNECT, URL proxy vẫn để http://. Đặt https:// cho proxy HTTP, lần chạy thử treo 30 giây mà proxy không nhận được lệnh nào.

Vì sao lỗi Content-Type lạ chỉ xuất hiện với trang HTTP. Với đích HTTP, proxy trả 407 như một response thường và Crawlee báo lỗi kiểu nội dung thay vì 407. Kiểm tra tài khoản proxy trước khi sửa bộ lọc nội dung.

Cùng session id có giữ cùng IP không. SDK giữ cùng URL proxy cho cùng session id. Giữ cùng IP hay không còn tùy proxy đó là tĩnh hay gateway xoay.

Lỗi proxy Apify: những điều cần nhớ

Lỗi proxy Apify đọc theo giai đoạn: ArgumentError là sai định dạng, rotating session kèm 407 hay ECONNREFUSED là sai tài khoản hoặc cổng, WARN running without proxy là Actor đang dùng IP thật. Đặt maxSessionRotations nhỏ, kiểm tra cấu hình không undefined. Cần proxy HTTP ổn định để bớt lỗi proxy Apify, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.