Node.js Proxy là gì & Cách sử dụng máy chủ Proxy trong Node.js
Tóm tắt
Node.js không có hỗ trợ proxy tích hợp sẵn. Các mô-đun core http/https gửi yêu cầu trực tiếp đến máy chủ đích trừ khi bạn gán một http.Agent có khả năng nhận diện proxy hoặc tự cài đặt tùy chọn yêu cầu.
Biến môi trường HTTP_PROXY/HTTPS_PROXY chỉ hoạt động nếu thư viện bạn gọi đọc chúng. Hàm http.request core hoàn toàn bỏ qua chúng; hầu hết các công cụ CLI và một số khách hàng HTTP đọc chúng thông qua các gói hỗ trợ, không tự động.
https-proxy-agent và http-proxy-agent là cách tiêu chuẩn để chuyển hướng các yêu cầu core http/https qua một proxy, sử dụng một đường hầm CONNECT HTTP cho các mục tiêu HTTPS và chuyển tiếp trực tiếp cho các mục tiêu HTTP.
Axios chấp nhận một đối tượng proxy trực tiếp (host, port, protocol, auth tùy chọn), vì vậy hầu hết các dự án dựa trên Axios không cần một gói agent riêng biệt cho các proxy HTTP.
fetch gốc và undici chuyển tiếp qua một proxy thông qua và , điều này cũng ảnh hưởng đến toàn cầu của Node kể từ phiên bản 18+ vì Node đã xây dựng nó trên undici.
Trải nghiem Nstproxy - Bat dau dung thu mien phi ngay
ProxyAgent
setGlobalDispatcher
fetch()
Thông tin xác thực của proxy nên nằm trong URL proxy hoặc một trường xác thực chuyên dụng, không bao giờ được mã hóa cứng trong mã ứng dụng mà được đưa vào kiểm soát phiên bản.
Proxy SOCKS5 cần một agent khác (socks-proxy-agent) bởi vì các agent proxy dựa trên CONNECT không thực hiện bắt tay SOCKS.
Giới thiệu: proxy có nghĩa là gì trong một yêu cầu Node.js
Một proxy trong Node.js là một máy chủ trung gian mà một script cố ý chuyển hướng một yêu cầu HTTP hoặc HTTPS ra ngoài thông qua, thay vì kết nối trực tiếp đến máy chủ đích. Các mô-đun core http và https của Node không được xây dựng với hỗ trợ proxy như một hành vi mặc định — mỗi yêu cầu được chuyển tiếp trong Node.js hoạt động vì mã (hoặc một thư viện) rõ ràng chỉ định yêu cầu đến một máy chủ proxy, thông qua một http.Agent tùy chỉnh hoặc thông qua cấu hình cụ thể của khách hàng.
Sự phân biệt đó quan trọng vì nó giải thích lý do tại sao việc sao chép một hướng dẫn proxy được viết cho một khách hàng HTTP vào một dự án sử dụng một khách hàng khác thường không có tác dụng gì. curl và nhiều công cụ hệ thống tự động đọc HTTP_PROXY/HTTPS_PROXY từ môi trường; http.request của Node thì không. Mỗi thư viện khách hàng bên dưới cần có thiết lập rõ ràng của riêng mình.
Nhìn Nhanh
Việc kết nối thông tin xác thực của proxy và logic xoay vòng vào mỗi yêu cầu rất dễ bị sai nếu làm bằng tay — Nstproxy cung cấp một điểm cuối cổng ổn định theo kế hoạch để mã Node.js của bạn chỉ cần chỉ vào một URL proxy.
Node.js cung cấp http, https, và (từ Node 18 trở đi) một fetch toàn cầu được hỗ trợ bởi ProxyAgent của undici. Không gói nào trong số đó bao gồm mã chuyển tiếp proxy, vì vậy hãy thêm gói agent phù hợp với khách hàng mà bạn đã sử dụng:
Bạn không cần tất cả năm gói trong một dự án — chỉ cài đặt các gói cho khách hàng mà mã của bạn thực sự gọi. https-proxy-agent phiên bản 9.1.0 và http-proxy-agent phiên bản 9.1.0 đều xuất khẩu một lớp có tên (HttpsProxyAgent, HttpProxyAgent) chứ không phải xuất khẩu mặc định, điều này quan trọng cho cú pháp require/import bên dưới.
Cấu hình một proxy cho các mô-đun core http/https của Node
http-proxy-agent chuyển tiếp các yêu cầu HTTP thông thường qua proxy; https-proxy-agent mở một đường hầm CONNECT HTTP qua proxy và sau đó trao đổi TLS với điểm đến, điều này là những gì một mục tiêu HTTPS yêu cầu. Truyền agent kết quả như tùy chọn agent vào các hàm yêu cầu dựa trên http.Agent của Node là sự thay đổi duy nhất cho một cuộc gọi https.request bình thường:
Ví dụ này được chạy chống lại một máy chủ proxy thử nghiệm cục bộ (Node http.createServer xử lý CONNECT) và một đích HTTPS cục bộ: yêu cầu trả về 200 và thân JSON mong đợi thông qua đường hầm, xác nhận rằng luồng CONNECT-sau-TLS hoạt động với phiên bản tác nhân và hình thức gọi này.
Đối với một đích HTTP đơn thuần (không phải HTTPS), sử dụng HttpProxyAgent thay thế — nó chuyển tiếp yêu cầu mà không cần bắt tay CONNECT:
Chạy một lệnh gọi http.get() không thay đổi chống lại cùng một đích mà không có tùy chọn agent, và với HTTP_PROXY chỉ được thiết lập như một biến môi trường, đã xác nhận rằng core http bỏ qua biến môi trường — yêu cầu đã đi thẳng đến đích thay vì qua proxy. Hãy coi bất kỳ hướng dẫn nào bảo bạn "chỉ cần thiết lập HTTP_PROXY" cho core http/https là chưa hoàn chỉnh; nó chỉ hoạt động cho các công cụ mà cụ thể đọc biến đó.
Cấu hình một proxy trong Axios
Axios (được thử nghiệm ở phiên bản 1.19.0) chấp nhận cài đặt proxy dưới dạng một đối tượng đơn giản trong cấu hình yêu cầu, không cần gói tác nhân bổ sung cho các proxy theo giao thức HTTP:
Yêu cầu này được chạy chống lại cùng một proxy và đích cục bộ được sử dụng ở trên và đã trả về 200 với thân yêu cầu mong đợi, xác nhận rằng tuỳ chọn proxy của Axios thực hiện đường hầm CONNECT cho một mục tiêu HTTPS tự động. Nếu bạn cần các tùy chọn TLS mà đối tượng proxy của Axios không công khai — một CA tùy chỉnh, hoặc việc tắt xác minh chứng chỉ đối với một máy chủ thử nghiệm nội bộ — hãy chuyển httpsAgent: new https.Agent({...}) cùng với proxy, hoặc thay thế hoàn toàn proxy bằng một phiên bản của https-proxy-agent gán cho httpsAgent.
Axios cũng tôn trọng các biến môi trường HTTP_PROXY/HTTPS_PROXY/NO_PROXY theo mặc định, trừ khi proxy: false được thiết lập trong cấu hình yêu cầu — đây là một trong số ít các khách hàng mà quy ước biến môi trường hoạt động mà không cần bạn viết mã tác nhân.
Cấu hình một proxy cho node-fetch và fetch/undici gốc
node-fetch (được thử nghiệm ở phiên bản 2.7.0) chấp nhận tùy chọn agent giống như core http/https, vì vậy cùng một phiên bản http-proxy-agent/https-proxy-agent áp dụng:
Chạy chống lại máy chủ proxy thử nghiệm cục bộ và một đích HTTP, điều này trả về thân JSON mong đợi, xác nhận rằng cùng một lớp tác nhân hoạt động không thay đổi giữa core http và node-fetch.
Hàm fetch() toàn cầu được tích hợp sẵn của Node (có sẵn từ Node 18 trở lên) và gói độc lập undici không chấp nhận tùy chọn agent theo cùng một cách — chúng sử dụng ProxyAgent của undici, được đăng ký toàn cầu với setGlobalDispatcher:
const{ProxyAgent, setGlobalDispatcher }=require('undici');setGlobalDispatcher(newProxyAgent('http://proxy.example.com:8000'));const res =awaitfetch('https://api.example.com/status');console.log(res.status,await res.json());
Điều này được chạy với phiên bản undici 6.28.0: sau khi gọi setGlobalDispatcher, cả undici.request() và fetch() toàn cầu của Node đều được định tuyến qua máy chủ proxy thử nghiệm cục bộ và trả về phản hồi 200 mong đợi — xác nhận rằng setGlobalDispatcher ảnh hưởng đến fetch toàn cầu, không chỉ là các hàm yêu cầu riêng của undici, vì triển khai fetch của Node được xây dựng dựa trên undici. Hạn chế một ProxyAgent cho một yêu cầu duy nhất thay vì thiết lập nó toàn cầu khi chỉ có một số yêu cầu trong một quy trình cần đi qua proxy — truyền { dispatcher: new ProxyAgent(...) } như một tùy chọn theo cuộc gọi cho undici.request().
Mô hình nâng cao: xác thực, SOCKS5 và xoay vòng
Xác thực proxy. Đối với cả bốn khách hàng ở trên, nhúng thông tin xác thực vào URL proxy (http://user:pass@proxy.example.com:8000) hoặc trường xác thực dành riêng của khách hàng (trường proxy.auth của Axios). Không bao giờ định dạng chúng vào tiêu đề Authorization của yêu cầu đích — tiêu đề đó gửi đến máy chủ đích, không phải proxy, và hầu hết các máy chủ proxy mong đợi thông tin xác thực trong tiêu đề Proxy-Authorization, tiêu đề mà các gói tác nhân tạo ra từ thông tin người dùng trong URL.
Proxy SOCKS5.https-proxy-agent và http-proxy-agent chỉ thực hiện giao thức proxy HTTP CONNECT. Một điểm cuối SOCKS5 cần socks-proxy-agent, cung cấp cùng mẫu tùy chọn agent:
Kiểm soát phiên (dính vs. xoay vòng). Việc một yêu cầu nhất định có sử dụng cùng một IP thoát như yêu cầu trước đó hay không, hoặc có được một IP mới, được kiểm soát bởi cổng của nhà cung cấp proxy, không phải bởi Node.js — mã ở phía khách hàng trên vẫn giữ nguyên cả hai trường hợp. Các nhà cung cấp hỗ trợ cả hai chế độ thường chuyển đổi hành vi dựa trên một tham số phiên được thêm vào tên người dùng proxy (ID "phiên dính") hoặc trên các cổng gateway riêng biệt cho các pool dính và xoay vòng; hãy kiểm tra tài liệu gateway của nhà cung cấp cụ thể để biết tên tham số chính xác trước khi giả định rằng một quy ước từ một nhà cung cấp áp dụng cho nhà cung cấp khác.
Sử dụng Nstproxy với cùng mẫu
Nstproxy cung cấp các điểm cuối gateway HTTP/SOCKS5 qua Residential Lite Proxies và sáu dòng sản phẩm proxy khác — Residential Prime, Datacenter, Static ISP, IPv6, Unlimited Residential và Mobile — vì vậy mã HttpsProxyAgent/Axios proxy/ProxyAgent trên hoạt động bằng cách chỉ định agent đến máy chủ, cổng và thông tin xác thực Nstproxy của bạn thay vì một giá trị thay thế. Nstproxy được xây dựng cho các nhóm cần nhắm mục tiêu theo địa lý, kiểm soát phiên, hoặc khối lượng yêu cầu cao hơn mức mà một proxy tự lưu trữ đơn lẻ có thể duy trì, và nó phù hợp với việc lấy dữ liệu, giám sát giá cả, xác minh quảng cáo và kiểm thử QA nơi một IP thoát đơn lẻ sẽ bị giới hạn hoặc chặn.
Nhắm mục tiêu theo quốc gia và thành phố — chọn vị trí thoát bằng cách bao gồm tham số vị trí trong tên người dùng proxy, mà không cần thay đổi mã yêu cầu phía khách hàng.
Các phiên dính hoặc xoay vòng — giữ một IP cho một quy trình làm việc nhiều bước (đăng nhập, sau đó phân trang) hoặc thay đổi theo mỗi yêu cầu, tùy thuộc vào tham số phiên được sử dụng.
Gateway HTTP và SOCKS5 — cùng mã khách hàng được trình bày ở trên (dựa trên agent cho http/node-fetch, đối tượng proxy gốc cho Axios, ProxyAgent cho undici/fetch) hoạt động với gateway của Nstproxy mà không cần thay đổi thêm.
Xác nhận các tên máy chủ gateway hiện tại, cổng và giá cả trên trang giá Residential Lite Proxies trước khi triển khai, vì các chi tiết và tỷ lệ gateway có thể thay đổi. Tất cả các tham số gateway, định dạng xác thực và đoạn mã SDK có trong tài liệu Nstproxy; nếu bạn đang quyết định giữa các nhà cung cấp proxy đầu tiên, trang so sánh proxy Nstproxy phác thảo sự khác biệt tính năng so với các nhà cung cấp khác. Các nhóm kết hợp lưu lượng proxy với một crawler Node.js thường tập trung hóa các quy tắc định tuyến và giám sát pool tiếp theo - xem cách Nstproxy Proxy Manager áp dụng cho các khối lượng công việc crawling cho lớp đó.
Giới hạn trung thực
Các http/https cốt lõi và node-fetch không bao giờ đọc HTTP_PROXY/HTTPS_PROXY một mình - mọi ví dụ ở trên đều thiết lập proxy rõ ràng trong mã, và bất kỳ triển khai nào chỉ dựa vào biến môi trường cho những khách hàng này sẽ lặng lẽ bỏ qua proxy.
Tunnel CONNECT của https-proxy-agent thêm một vòng đi lại mạng bổ sung cho mỗi kết nối HTTPS mới so với một yêu cầu trực tiếp; việc tái sử dụng kết nối (keepAlive: true trên agent) phân bổ chi phí đó qua nhiều yêu cầu đến cùng một máy chủ.
Không có gói agent nào ở trên thử lại một kết nối proxy bị lỗi hoặc tự động chuyển sang một IP thoát khác — logic đó, nếu bạn cần, phải được viết vào wrapper yêu cầu của riêng bạn hoặc được cung cấp bởi gateway của dịch vụ proxy.
Các kết nối WebSocket cần xử lý nâng cấp nhận thức về proxy riêng; các agent được trình bày ở đây bao trùm các chu kỳ yêu cầu/phản hồi HTTP/HTTPS đơn giản, không phải là bắt tay Upgrade.
Khắc phục sự cố
ECONNREFUSED hoặc ECONNRESET khi kết nối qua proxy. Xác nhận rằng máy chủ và cổng proxy có thể truy cập trực tiếp (ví dụ với nc -vz host port) trước khi giả định rằng mã Node.js bị sai - một tường lửa hoặc phiên proxy hết hạn tạo ra cùng lỗi như một lỗi trong mã.
Lỗi unable to verify the first certificate hoặc self-signed certificate. Điều này có nghĩa là khách hàng đang xác thực TLS cho máy chủ đích thông qua đường hầm và thất bại, thường do một proxy doanh nghiệp hoặc thử nghiệm đang chặn TLS với chứng chỉ riêng của nó. Thêm chứng chỉ đó vào kho lưu trữ tin cậy của Node (NODE_EXTRA_CA_CERTS) thay vì vô hiệu hóa xác thực chứng chỉ trong mã sản xuất.
Yêu cầu treo thay vì thất bại. Đặt thời gian chờ rõ ràng cho tác nhân hoặc khách hàng (tuỳ chọn timeout trên http.request, timeout trên Axios) — các proxy bí mật rơi gói thay vì trả về lỗi từ chối kết nối sẽ treo cho đến khi thời gian chờ socket mặc định của nền tảng.
Chỉ một số yêu cầu sử dụng proxy. Đối với undici/global fetch, setGlobalDispatcher áp dụng cho mọi cuộc gọi tiếp theo trong quy trình; nếu một số cuộc gọi bỏ qua proxy một cách bất ngờ, hãy kiểm tra xem đường đi mã đó có sử dụng một khách hàng HTTP khác (Axios, node-fetch) cần cấu hình proxy riêng biệt không.
Kết luận
Mỗi cấu hình proxy trong Node.js đều quay về cùng một quyết định: khách hàng HTTP nào đang thực hiện yêu cầu, và cơ chế proxy nào được hỗ trợ của khách hàng đó — một http.Agent rõ ràng, một đối tượng cấu hình proxy, hoặc một bộ điều phối toàn cầu — bạn cấu hình với máy chủ điểm đến, cổng và thông tin xác thực. Các mô-đun cốt lõi http/https và node-fetch cần một tác nhân từ https-proxy-agent/http-proxy-agent/socks-proxy-agent; Axios chấp nhận một đối tượng proxy trực tiếp; fetch và undici gán qua ProxyAgent và setGlobalDispatcher. Không cái nào trong số đó hoạt động qua biến môi trường HTTP_PROXY đơn lẻ trừ khi khách hàng cụ thể được ghi tài liệu rằng nó đọc nó.
Câu hỏi thường gặp
H: Node.js có hỗ trợ proxy ngay lập tức không?
Không — các mô-đun cốt lõi http và https kết nối trực tiếp đến máy chủ điểm đến trừ khi yêu cầu rõ ràng sử dụng một http.Agent nhận biết proxy (từ một gói như https-proxy-agent) hoặc thư viện khách hàng có cấu hình proxy riêng của nó, như tùy chọn proxy của Axios.
H: Tại sao việc đặt HTTP_PROXY không hoạt động trong kịch bản Node.js của tôi?
Việc đặt HTTP_PROXY chỉ hoạt động cho các khách hàng được chỉ định rõ ràng đọc nó — Axios đọc nó theo mặc định, nhưng các mô-đun cốt lõi http/https và node-fetch thì không, vì vậy những cái đó cần một tác nhân rõ ràng trong mã bất kể biến môi trường.
H: Sự khác biệt giữa http-proxy-agent và https-proxy-agent là gì?
http-proxy-agent truyền một yêu cầu HTTP thuần túy qua proxy mà không có đường hầm, trong khi https-proxy-agent mở một đường hầm HTTP CONNECT qua proxy trước và sau đó đàm phán TLS với máy đích HTTPS — hãy sử dụng cái phù hợp với chế độ của mục tiêu của bạn, không phải chế độ của proxy của bạn.
H: Tôi có thể sử dụng proxy với fetch() gốc của Node không?
Có — đăng ký một ProxyAgent undici với setGlobalDispatcher() trước khi gọi fetch(), vì fetch tích hợp sẵn của Node chạy trên undici và đọc cùng một bộ điều phối toàn cầu.
H: Tôi có cần một cấu hình khác cho một proxy SOCKS5 không?
Có — https-proxy-agent và http-proxy-agent chỉ thực hiện giao thức proxy HTTP CONNECT, vì vậy một điểm cuối SOCKS5 cần socks-proxy-agent thay vào đó, sử dụng cùng một mẫu tùy chọn agent.
H: Có an toàn khi mã hóa cứng thông tin xác thực proxy trong mã Node.js của tôi không?
Không — giữ tên người dùng và mật khẩu proxy trong biến môi trường hoặc một trình quản lý bí mật và xây dựng URL proxy trong thời gian chạy, theo cách mà bạn sẽ xử lý mật khẩu cơ sở dữ liệu, thay vì cam kết chúng vào kiểm soát nguồn.
H: Liệu proxy có làm chậm yêu cầu Node.js của tôi không?
Một yêu cầu HTTPS qua một đường hầm HTTP CONNECT sẽ thêm một lần vòng trip bổ sung để thiết lập đường hầm so với một kết nối trực tiếp, nhưng việc bật keepAlive trên tác nhân sẽ cho phép các yêu cầu tiếp theo đến cùng một máy chủ tái sử dụng đường hầm đó thay vì phải trả chi phí một lần nữa.
Ivy Lin
Aug. 7th 2026
110M+ IP that voi ti le truy cap thanh cong 99.9%
Phan hoi trung binh ~0.5s cho tac vu dong thoi cao
Chi tu $0.1/GB
Truy cap ngay cac pool proxy residential, datacenter, IPv6 va ISP cao cap.