node-fetch proxy cấu hình agent và xử lý timeout

node-fetch proxy cần được gắn qua agent của thư viện, khác với dispatcher dùng cho fetch tích hợp trong Node.js. Nhầm hai cơ chế này có thể khiến code chạy sai tuyến hoặc không nhận cấu hình. Trong bài này, ProxyVN hướng dẫn một luồng lấy JSON qua HTTPS, kiểm tra xác thực, đặt thời hạn chờ và đọc lỗi bằng ví dụ đã thử trên môi trường cục bộ.

node-fetch proxy và hai hàm fetch dễ nhầm

Trong một dự án Node.js, tên fetch có thể chỉ hàm tích hợp của runtime hoặc hàm được import từ gói node-fetch. Tên gọi giống nhau nhưng phần mở rộng cấu hình mạng khác nhau. Anh em cần xác định đúng hàm đang được gọi trước khi thêm bất kỳ tùy chọn proxy nào.

Nhận biết hàm được import trong tệp

Nếu tệp có import fetch from 'node-fetch', các lời gọi fetch trong phạm vi đó dùng thư viện được import. Nếu không có khai báo tương ứng và runtime cung cấp fetch, chương trình có thể dùng globalThis.fetch. Một wrapper hoặc thư viện khác cũng có thể đổi tên hàm, nên cần kiểm tra chính tệp đang thực thi.

Ví dụ dưới đặt tên nodeFetch rõ ràng để tránh nhầm với hàm toàn cục. Cách đặt tên không thay đổi hành vi, nhưng giúp người đọc nhận ra cấu hình agent cần được áp dụng ở đâu. Trong một đợt chuyển đổi thư viện, nên giữ cách gọi tường minh cho tới khi mọi đường đi đã được kiểm tra.

import nodeFetch from 'node-fetch';
 
const result = await nodeFetch(targetUrl, options);
// Hàm khác, nếu runtime có hỗ trợ:
// const result = await globalThis.fetch(targetUrl, options);

Agent và dispatcher thuộc hai giao diện

node-fetch nhận một agent tương thích với cơ chế HTTP của Node.js. Fetch tích hợp dùng cơ chế dispatcher của Undici cho cấu hình nâng cao. Tài liệu fetch của Node.js giải thích nền tảng này; không nên truyền agent của node-fetch vào fetch gốc rồi mặc định proxy đã được áp dụng.

Nếu dự án đã dùng Axios ở những phần khác, việc có sẵn một đối tượng httpsAgent cũng không có nghĩa mọi client hiểu cùng tên thuộc tính. Axios dùng httpsAgent, node-fetch dùng agent, còn fetch gốc dùng dispatcher. Có thể tham khảo bài Axios proxy trong Node.js để đối chiếu phía client đó mà không trộn cú pháp.

Xác định đúng thư viện thực hiện request trước khi kiểm tra tuyến proxy. Cùng tên fetch chưa có nghĩa cùng cách cấu hình.

Chuẩn bị phiên bản cho node-fetch proxy

Một ví dụ có thể chạy lại cần ghi cả phiên bản Node.js, thư viện HTTP và agent. Chỉ biết phiên bản Node chưa đủ, vì một dự án có thể cài node-fetch qua phụ thuộc trực tiếp hoặc gián tiếp. Kiểm tra package.json và tệp khóa giúp tránh sửa nhầm cấu hình của một bản khác.

Bộ thư viện đã dùng trong phép thử

Ví dụ được kiểm tra ngày 22/10/2026 với Node.js 24.19.0, node-fetch 3.3.2 và https-proxy-agent 7.0.6. Các số này mô tả môi trường đã thử, không phải danh sách bản phát hành mới nhất. Khi đưa vào dự án đang vận hành, anh em cần xem yêu cầu tương thích và bảo trì của các phiên bản được chọn.

Tạo một thư mục thử riêng rồi cài các phụ thuộc sau. Tệp code dùng đuôi .mjs để cú pháp import được nhận diện rõ. Giữ tệp khóa do trình quản lý gói tạo sau khi cài, đồng thời ghi lại lệnh khởi chạy để người khác không phải đoán ngữ cảnh thực thi.

mkdir node-fetch-proxy-demo
cd node-fetch-proxy-demo
npm init -y
npm install --save-exact node-fetch@3.3.2 https-proxy-agent@7.0.6

Hiểu khác biệt giữa nhánh v2 và v3

node-fetch v3 dùng ES modules, vì vậy cách require quen thuộc của một dự án CommonJS không thể được áp dụng nguyên trạng. Hướng dẫn chuyển sang v3 của node-fetch cũng ghi nhận các thay đổi cấu hình cần xem lại. Không nên chỉ sửa dòng cài đặt rồi giữ mọi tùy chọn cũ.

Nếu gặp lỗi import, hãy xử lý kiểu module trước khi chẩn đoán proxy. Một tiến trình dừng ngay ở bước nạp gói chưa gửi request ra mạng. Việc đổi IP, tăng thời gian chờ hoặc thay mật khẩu trong tình huống đó không giải quyết được lỗi khởi chạy của chương trình.

Anh em có thể giữ một tệp thử tối thiểu chỉ import các gói rồi in một thông báo. Khi tệp đó chạy được, mới thêm cấu hình agent và một URL thử. Tách từng bước như vậy giúp phân biệt lỗi cài thư viện với lỗi xảy ra sau khi kết nối bắt đầu.

Thiết kế đầu vào cho node-fetch proxy dùng HTTPS

Bài này chọn một phạm vi nhỏ: đích HTTPS, HTTP hoặc HTTPS proxy có hỗ trợ CONNECT và phản hồi JSON dạng object. Mục tiêu là kiểm tra luồng request cùng chất lượng đầu vào đầu ra. Đây không phải bộ client bao phủ mọi loại proxy, giao thức hoặc kiểu dữ liệu.

Khai báo URL đích và thông tin proxy

TARGET_URL chỉ địa chỉ API cần gọi, còn PROXY_URL chỉ máy chủ trung gian. Hai URL có vai trò khác nhau nên không cần cùng giao thức. Một proxy có URL bắt đầu bằng http:// vẫn có thể mở đường hầm cho kết nối tới đích https:// nếu dịch vụ hỗ trợ CONNECT.

Trong PowerShell, cấu hình như mẫu dưới sau khi thay toàn bộ giá trị giả. Miền example.test chỉ để trình bày cú pháp, không phải API đang được cung cấp. Để thử thực tế, chọn endpoint của anh em hoặc một API cho phép kiểm tra có phản hồi phù hợp với điều kiện trong code.

$env:TARGET_URL = 'https://example.test/api/summary'
$env:PROXY_URL = 'http://USERNAME:PASSWORD@HOST:PORT'
node run.mjs

Nếu username hoặc password có ký tự đặc biệt, hãy mã hóa riêng từng phần trước khi ghép thành URL. Mã hóa cả chuỗi sẽ làm hỏng các dấu phân tách cần thiết. Khi trao đổi lỗi, chỉ gửi dạng đã che thông tin đăng nhập và giữ lại giao thức, hostname cùng cổng cần đối chiếu.

Định nghĩa hợp đồng dữ liệu trước khi viết code

Một API có thể trả JSON object, JSON array hoặc dữ liệu dạng khác. Hàm trong bài chỉ chấp nhận object để tạo một điều kiện kiểm tra cụ thể. Nếu nguồn thật trả array hợp lệ, anh em cần sửa hợp đồng đó; không được gọi mọi array là lỗi của API hoặc lỗi proxy.

Tương tự, phản hồi Content-Type application/json là điều kiện của ví dụ. Một API sử dụng media type riêng cần được đánh giá theo tài liệu của nó. Việc đặt điều kiện rõ ngay từ đầu giúp đọc lỗi chính xác hơn so với cố phân tích mọi phản hồi rồi chờ tới bước sử dụng dữ liệu mới phát hiện sai.

Đặt đúng đích và tuyến proxy

Code node-fetch proxy có xác thực và thời hạn chờ

Hàm dưới làm ba việc theo thứ tự: xác nhận cấu hình, lấy phản hồi qua proxy và kiểm tra dữ liệu JSON. Agent được tạo cho lượt gọi và hủy khi kết thúc. Timer hủy yêu cầu cũng được dọn trong finally để tiến trình không giữ một tác vụ chờ đã hết mục đích.

Mở kết nối bằng HttpsProxyAgent

Lưu toàn bộ đoạn code thành fetch-json.mjs. Lớp HttpsProxyAgent được truyền vào thuộc tính agent của node-fetch. Cơ chế CONNECT cho đích HTTPS được mô tả trong tài liệu chính thức của https-proxy-agent. Ví dụ không thêm đồng thời một cơ chế proxy khác vào cùng lời gọi.

import fetch from 'node-fetch';
import { HttpsProxyAgent } from 'https-proxy-agent';
 
export async function fetchJsonViaProxy(target, proxyUrl,
  timeoutMs = 15000) {
  const url = new URL(target);
  const proxy = new URL(proxyUrl);
  if (url.protocol !== 'https:') {
    throw new Error('HTTPS_TARGET_REQUIRED');
  }
  if (!['http:', 'https:'].includes(proxy.protocol)) {
    throw new Error('HTTP_PROXY_REQUIRED');
  }
  const agent = new HttpsProxyAgent(proxy);
  const controller = new AbortController();
  const timer = setTimeout(() => controller.abort(), timeoutMs);
  try {
    const response = await fetch(url, {
      agent, signal: controller.signal,
      redirect: 'manual', size: 2 * 1024 * 1024,
      headers: { Accept: 'application/json' },
    });
    if (!response.ok) {
      response.body?.destroy();
      const error = new Error('HTTP_STATUS');
      error.status = response.status;
      throw error;
    }
    const type = response.headers.get('content-type') || '';
    if (!type.toLowerCase().includes('application/json')) {
      response.body?.destroy();
      throw new Error('EXPECTED_JSON');
    }
    const value = await response.json();
    if (!value || typeof value !== 'object' ||
        Array.isArray(value)) {
      throw new Error('EXPECTED_JSON_OBJECT');
    }
    return value;
  } finally {
    clearTimeout(timer);
    agent.destroy();
  }
}

Hiểu thời hạn bao quanh cả phần đọc body

Timer được giữ cho tới khi response.json hoàn tất, nên việc nhận header chưa làm thời hạn biến mất. Nếu phần body tiếp tục chậm, tín hiệu hủy vẫn có thể kết thúc việc đọc. Đây là lý do không đặt clearTimeout ngay sau khi fetch trả về đối tượng response.

Giá trị 15000 mili giây chỉ là lựa chọn minh họa cho một yêu cầu nhỏ. Với API xử lý lâu hoặc tệp lớn, anh em cần một chính sách khác. Nên phân biệt thời gian chờ cho một lần gọi với tổng thời gian của cả tác vụ có nhiều request và nhiều lần thử lại.

Giới hạn size hai MiB áp dụng cho body được đọc bằng cơ chế của node-fetch. Nó giúp ví dụ không nhận dữ liệu lớn ngoài dự kiến, nhưng cũng có thể từ chối phản hồi hợp lệ của một endpoint khác. Trước khi tăng giới hạn, hãy kiểm tra kích thước thật và nhu cầu dữ liệu thay vì chỉ đặt một số rất lớn.

Chạy hàm từ một tệp riêng

Tạo run.mjs cùng thư mục với fetch-json.mjs rồi dùng đoạn dưới. Phần ghi file chỉ diễn ra sau khi hàm tải và kiểm tra dữ liệu trả về. Nếu có lỗi, chương trình trả mã kết thúc khác không để lịch chạy hoặc tác vụ gọi bên ngoài có thể nhận biết thất bại.

import { writeFile } from 'node:fs/promises';
import { fetchJsonViaProxy } from './fetch-json.mjs';
 
try {
  const data = await fetchJsonViaProxy(
    process.env.TARGET_URL, process.env.PROXY_URL
  );
  await writeFile('result.json',
    JSON.stringify(data, null, 2) + '\n', 'utf8');
  console.log(JSON.stringify({ saved: 'result.json' }));
} catch (error) {
  console.error(JSON.stringify({
    error: error.code || error.name,
    status: error.status ?? null,
  }));
  process.exitCode = 1;
}

Thông báo lỗi ngắn không chứa toàn bộ đối tượng request hoặc URL proxy. Khi cần phân loại sâu hơn, anh em có thể thêm mã tác vụ cùng nhãn tuyến do mình đặt. Không cần đưa mật khẩu hoặc nội dung phản hồi có dữ liệu nhạy cảm vào log chỉ để biết một request đã thất bại.

Kiểm tra HTTP status trong node-fetch proxy

Một khác biệt dễ gây hiểu nhầm là phản hồi HTTP lỗi không tự biến thành lỗi mạng. Request có thể nhận đầy đủ một phản hồi 404 hoặc 429, nghĩa là quá trình vận chuyển đã trả được dữ liệu. Chương trình vẫn phải tự xác định phản hồi đó có đáp ứng mục tiêu hay không.

Phân biệt phản hồi lỗi và lỗi trước phản hồi

Hàm mẫu kiểm tra response.ok trước khi đọc JSON. Với HTTP status nằm ngoài nhóm thành công, nó tạo lỗi có trường status để người gọi phân loại. Cách kiểm tra này được trình bày trong hướng dẫn xử lý HTTP response của node-fetch.

Lỗi DNS, kết nối bị từ chối hoặc hủy theo thời hạn có thể xuất hiện trước khi chương trình có phản hồi hợp lệ. Trong trường hợp đó, không nên tự gán status bằng một mã HTTP dự đoán. Hãy giữ sự khác biệt giữa không có response và có response nhưng không đáp ứng điều kiện thành công.

Chủ động xem xét phản hồi chuyển hướng

Ví dụ đặt redirect thành manual để không tự đi tới URL mới. Nếu API trả 302 sang trang đăng nhập, chương trình sẽ báo HTTP status thay vì đọc nhầm trang HTML sau chuyển hướng. Khi nguồn có chuyển hướng hợp lệ, cần duyệt lại URL và chính sách theo đích trước khi thay cấu hình này.

Một chuỗi chuyển hướng còn có thể đổi từ HTTPS sang HTTP hoặc sang một miền khác. Khi tự động đi tiếp, agent phải phù hợp với giao thức của từng bước. Giữ phạm vi nhỏ trong lần thử đầu tiên giúp anh em biết tuyến nào đã được kiểm chứng và tuyến nào chưa được thử.

Không dùng lỗi JSON để kết luận proxy hỏng

Nếu status thành công và Content-Type phù hợp nhưng response.json vẫn lỗi, hãy xem phản hồi có bị cắt, chứa thông báo khác định dạng hoặc có lỗi từ máy chủ nguồn hay không. Chương trình đã vượt qua một số bước kiểm tra mạng, nhưng phần dữ liệu vẫn chưa đạt hợp đồng đã đặt.

Trong môi trường phát triển, có thể lưu một mẫu phản hồi đã rà soát để tái hiện lỗi phân tích mà không gọi lại API. Mẫu này nên có thời điểm cùng URL nguồn hoặc mã endpoint. Không nên chỉ giữ một ảnh lỗi rồi thay nhiều yếu tố cấu hình cùng lúc vì sẽ khó tìm nguyên nhân.

Kiểm tra status trước dữ liệu

Kết quả thử node-fetch proxy trong môi trường cục bộ

Bộ thử của bài dùng máy chủ HTTPS và một proxy HTTP hỗ trợ CONNECT trên localhost. Proxy kiểm tra username cùng password trước khi mở đường hầm. Vì vậy, phép thử có cả bước xác thực trung gian và việc đọc dữ liệu HTTPS, thay vì chỉ chạy hàm phân tích JSON từ một chuỗi sẵn có.

Bổ sung điều kiện nghiệp vụ sau JSON object

JSON object là điều kiện kỹ thuật ban đầu, chưa đủ để kết luận API đã trả đúng báo cáo cần lấy. Với phản hồi mẫu có count, anh em cần xác nhận trường này tồn tại, là số hữu hạn và nằm trong phạm vi được ứng dụng chấp nhận. Một object chứa thông báo lỗi cũng có thể vượt qua kiểm tra kiểu dữ liệu chung.

Ví dụ, một tác vụ đếm bản ghi có thể từ chối count âm hoặc chuỗi ký tự thay vì số. Nếu nguồn cho phép null để chỉ dữ liệu chưa có, cần định nghĩa trạng thái đó riêng. Không nên chuyển mọi giá trị thiếu thành số không, vì khi đó hệ thống khó phân biệt không có bản ghi với chưa lấy được dữ liệu.

Ở dự án thật, nên đặt phần kiểm tra nghiệp vụ trong một hàm tách biệt để chạy được với dữ liệu lưu sẵn. Khi API thay đổi tên trường, anh em sửa và thử hàm kiểm tra trước, không cần gọi mạng trong mọi vòng sửa. Điều này cũng giúp người làm dữ liệu cùng người vận hành proxy trao đổi bằng một mẫu đầu vào cụ thể.

Thử lại request không chỉ phụ thuộc HTTP status

Ví dụ hiện tại là GET và chưa có vòng thử lại tự động. Nếu mở rộng sang POST hoặc một API có tác dụng thay đổi trạng thái, cần xem chính sách của endpoint trước khi lặp request. Một lỗi đọc phản hồi không chứng minh máy chủ chưa xử lý yêu cầu; gửi lại ngay có thể tạo hai hành động cho một tác vụ.

Anh em nên lưu mã thao tác do ứng dụng đặt hoặc cơ chế chống lặp mà API hỗ trợ, nếu có. Nếu không có bằng chứng về khả năng lặp an toàn, hãy chuyển ca đó sang trạng thái cần đối chiếu. Không nên dùng cùng chính sách retry của việc tải một trang công khai cho mọi lời gọi có dữ liệu ghi.

Khi nhiều tác vụ cùng bị giới hạn, lịch thử lại cũng cần được điều phối. Chỉ thêm một khoảng chờ giống nhau ở từng request có thể khiến cả nhóm cùng quay lại một thời điểm. Theo dõi số lượt thử trên mỗi tác vụ và giữ một giới hạn chung sẽ làm tải dễ dự đoán hơn khi nguồn gặp sự cố kéo dài.

Kiểm tra thư mục và quyền ghi file

Sau khi nhận dữ liệu hợp lệ, bước lưu kết quả vẫn có thể thất bại vì quyền truy cập hoặc thư mục làm việc khác dự kiến. Hãy phân biệt lỗi này với lỗi request bằng cách giữ vị trí thao tác trong log. Nếu dùng lịch chạy, kiểm tra đường dẫn đầy đủ và tài khoản thực thi thay vì chỉ thử từ cửa sổ terminal cá nhân.

Một tệp kết quả cũ cũng có thể còn nguyên sau lượt chạy lỗi. Hãy xem thời điểm tạo hoặc mã tác vụ trước khi chuyển file cho bước xử lý tiếp theo, tránh nhầm dữ liệu cũ là kết quả mới.

Chín trường hợp đã được kiểm tra

Trong lần chạy ngày 22/10/2026, cả chín kiểm tra đều đạt điều kiện mong đợi. Trường hợp thành công trả object có source bằng local-fixture và count bằng hai. Các ca lỗi kiểm tra việc chương trình dừng đúng lớp thay vì ghi nhầm một kết quả như thể mọi dữ liệu đều hợp lệ.

Các kiểm tra này đánh giá hành vi của code trên dữ liệu do người viết kiểm soát. Chúng không chứng minh một API bên ngoài luôn trả được dữ liệu, cũng không đo độ trễ Internet hoặc chất lượng một gói proxy thương mại. Phạm vi kết luận cần đi cùng môi trường thử đã mô tả.

Giữ xác minh chứng chỉ trong phép thử

Máy chủ HTTPS thử dùng chứng chỉ tự tạo được thêm vào kho tin cậy riêng cho tiến trình kiểm tra. Không có bước tắt xác minh TLS cho mọi kết nối. Khi chạy với website thật có chứng chỉ hợp lệ, anh em không cần mang chứng chỉ cục bộ này sang môi trường triển khai.

Lần thử chưa dùng endpoint thương mại của ProxyVN. Trước khi chạy thật, cần xác nhận gói đã chọn cho phép kết nối theo đúng giao thức, cách xác thực và giới hạn sử dụng. Kết quả một proxy localhost không thể được dùng thay cho đánh giá một dịch vụ ở mạng khác.

Chuyển node-fetch proxy sang fetch tích hợp

Việc chuyển sang fetch của runtime có thể giảm một phụ thuộc, nhưng cần rà soát toàn bộ phần mở rộng đã dùng. Một đoạn code gọi fetch thành công mà bỏ qua cấu hình mạng cũ chưa phải là chuyển đổi đạt yêu cầu. Hãy kiểm tra lại tuyến kết nối bằng một phép thử có dấu mốc quan sát.

Thay agent bằng dispatcher phù hợp

Undici cung cấp ProxyAgent cho cơ chế dispatcher. Tài liệu ProxyAgent của Undici trình bày cách dùng và vòng đời của thành phần này. Khi chuyển đổi, cần dùng đúng loại đối tượng thay vì đổi mỗi tên thuộc tính agent thành dispatcher.

Anh em cũng cần rà lại các tùy chọn giới hạn body, chuyển hướng và cách hủy yêu cầu. Một tùy chọn riêng của node-fetch có thể không tồn tại trong fetch gốc hoặc có cách biểu đạt khác. Giữ bộ kiểm tra hành vi giúp phát hiện những thay đổi này ngay cả khi code vẫn chạy qua bước khởi động.

Kiểm tra tác dụng của biến môi trường theo runtime

Không nên khẳng định mọi phiên bản Node.js đều tự đọc hoặc đều bỏ qua HTTP_PROXY theo cùng một cách. Hành vi phụ thuộc runtime và cách bật hỗ trợ tương ứng. Với code cần kiểm chứng, hãy ghi rõ phiên bản cùng cơ chế cấu hình đang sử dụng, rồi kiểm tra bằng một endpoint có thể xác nhận tuyến.

Nếu có wrapper dùng chung trong dự án, hãy chọn một nơi chịu trách nhiệm tạo client hoặc dispatcher. Tạo cấu hình riêng ở nhiều tệp dễ khiến một số request đi đúng proxy còn một số khác dùng tuyến khác. Kiểm kê các lời gọi mạng là phần cần làm trước khi xóa phụ thuộc cũ.

Chuyển client cần kiểm lại tuyến

Vận hành node-fetch proxy khi có nhiều request

Mẫu một request được thiết kế để dễ đọc, không phải cấu trúc tối ưu cho mọi lô dữ liệu lớn. Khi thêm nhiều URL, cần quyết định cách chia agent, giới hạn đồng thời và ghi nhận lỗi. Những quyết định này nên xuất phát từ mục tiêu của công việc cùng hạn mức của nguồn.

Quản lý agent theo vòng đời tác vụ

Hàm minh họa tạo agent cho mỗi lượt gọi và hủy sau khi đọc body. Nếu nhiều request cùng dùng một tuyến, có thể quản lý agent ở cấp tác vụ để tái sử dụng tài nguyên kết nối. Khi đó, chỉ hủy sau khi các request sử dụng agent đã hoàn tất, tránh cắt ngang công việc đang chạy.

Nếu các bước phụ thuộc cùng phiên, giữ tuyến proxy chưa đủ để duy trì cookie. node-fetch không tự đóng vai trò trình duyệt lưu trạng thái đăng nhập cho mọi lời gọi. Cần một cơ chế quản lý cookie phù hợp nếu nghiệp vụ yêu cầu, đồng thời thử lại cả chuỗi thay vì chỉ thử từng URL riêng lẻ.

Giới hạn đồng thời và thử lại có điều kiện

Đừng đưa cả danh sách lớn vào Promise.all chỉ vì JavaScript hỗ trợ bất đồng bộ. Một mức đồng thời nhỏ giúp quan sát tác động của tải và xác định điểm bắt đầu tăng lỗi. Sau đó điều chỉnh theo dữ liệu hợp lệ thu được, thay vì chỉ nhìn tổng số request đã kết thúc.

Với nhiều tuyến, anh em có thể tham khảo cách chia proxy pool theo nhiệm vụ. Tách lỗi mạng tạm thời, lỗi xác thực và lỗi hợp đồng dữ liệu để quyết định thử lại. Đưa mọi lỗi vào một vòng retry giống nhau thường làm hệ thống khó kiểm soát hơn.

Nếu cần mua proxy, anh em có thể đối chiếu các gói đang hiển thị trên trang chủ ProxyVN và thử một endpoint với đúng phiên bản node-fetch trước khi mở rộng. Cần kiểm tra tuyến thực tế, xác thực và dữ liệu API; tên thư viện không tự bảo đảm mọi gói đều tương thích với cùng cấu hình.

Checklist node-fetch proxy trước khi chạy thật

Hãy chạy lại một nhóm nhỏ trên máy triển khai, vì kết quả trên máy phát triển chưa đại diện cho mọi môi trường. Quyền mạng, kho chứng chỉ, thư mục làm việc và biến môi trường của lịch chạy có thể khác. Giữ một tệp cấu hình đã che thông tin nhạy cảm để đối chiếu giữa hai nơi.

• Xác nhận đang gọi node-fetch hay fetch tích hợp của runtime.
• Ghi phiên bản Node.js, thư viện HTTP và agent đã kiểm tra.
• Kiểm tra cấu trúc URL proxy và mã hóa riêng thông tin xác thực.
• Đặt thời hạn cho cả quá trình đọc phản hồi cần dùng.
• Xử lý HTTP status trước khi phân tích dữ liệu nghiệp vụ.
• Kiểm tra Content-Type và hình dạng JSON theo endpoint thực tế.
• Duyệt chính sách chuyển hướng, giới hạn kích thước và thử lại.
• Ghi kết quả theo URL cùng mã tác vụ, không ghi mật khẩu.

Nếu một ca thất bại, hãy giữ lại tín hiệu đầu tiên và thay từng yếu tố cấu hình. Một phép thử thành công sau khi đổi đồng thời thư viện, proxy và thời hạn chỉ chứng minh tổ hợp mới hoạt động. Nó chưa xác định được nguyên nhân khiến cấu hình cũ thất bại.

Chín ca kiểm tra cục bộ

node-fetch proxy dễ kiểm tra hơn khi dùng đúng agent, xử lý HTTP status và giữ thời hạn tới lúc đọc xong body. Anh em nên thử tuyến cùng hợp đồng dữ liệu trước khi chạy nhiều request. Có thể trao đổi nhu cầu với Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam khi chọn kết nối cho node-fetch proxy.