Ở đâu đó trên Stack Overflow lúc này, chắc hẳn vẫn có người tin rằng Axios "âm thầm lỗi" với HTTPS proxy. Đây là một trong những nhận định được lặp lại nhiều nhất trong các bài hướng dẫn về Node.js proxy, nhưng nó không phản ánh đúng bản phát hành hiện tại được kiểm thử trong bài viết này. Tôi đã dựng một môi trường test cục bộ với nguồn HTTP và HTTPS thật đứng sau hai proxy khác nhau, và Axios 1.19.0 đã chuyển request HTTPS qua một CONNECT request đúng chuẩn thay vì đi vòng qua proxy.
Điều đó không có nghĩa là những khó khăn mà mọi người mô tả đều là bịa đặt. Các phiên bản Axios cũ từng có lỗi thật (xem issue #3384 và issue #4531 để đối chiếu), và các phiên bản Node mới còn bổ sung thêm một đường xử lý proxy qua biến môi trường cần được cấu hình cẩn thận. Hướng dẫn này sẽ đi từ những gì thực sự hoạt động trong Axios 1.19.0 tính đến hiện tại, cách nối proxy vào request theo từng phương pháp, một mẫu xoay vòng proxy bằng interceptor mà hầu như không có tutorial nào đề cập, và cả bảng lỗi–cách khắc phục đầy đủ để bạn xử lý khi mọi thứ vẫn đi chệch hướng.
Axios Proxy là gì và vì sao nó quan trọng trong Node.js?
Trong ngữ cảnh Axios, proxy chỉ là một máy chủ trung gian nằm giữa tiến trình Node của bạn và website đích. Request sẽ đi đến proxy trước, proxy chuyển tiếp request đó, và website đích sẽ thấy địa chỉ IP của proxy thay vì IP của bạn. Chỉ vậy thôi.
Lập trình viên thường dùng proxy vì vài lý do phổ biến: scrape website có giới hạn tốc độ hoặc chặn theo IP, kiểm thử hành vi ứng dụng từ một khu vực địa lý khác, định tuyến lưu lượng qua cổng thoát của công ty, hoặc đơn giản là không muốn IP của máy chủ mình xuất hiện trong access log của hệ thống đích. Cấu hình request chính thức của Axios có sẵn tuỳ chọn proxy với các trường host, port, protocol và auth — nó đã tồn tại nhiều năm, và cũng là thứ đầu tiên mọi tutorial (kể cả bài này) sẽ cho bạn xem.
Điều thường bị lướt qua là: tuỳ chọn proxy này hoạt động khác nhau tuỳ bạn đang gọi đích HTTP hay HTTPS, và còn phụ thuộc vào phiên bản Axios bạn đang chạy. Sự khác biệt đó chính là lý do bài hướng dẫn này tồn tại.
Thiết lập Node.js và Axios (phần nền tảng nhanh)
Bỏ qua phần này nếu bạn đã có sẵn dự án. Nếu chưa, chỉ mất khoảng hai phút.
mkdir axios-proxy-demo && cd axios-proxy-demo
npm init -y
npm install axios
Thêm "type": "module" vào package.json nếu bạn muốn dùng ESM imports (tôi thì có — dùng CommonJS require() cho demo proxy giờ thấy hơi cũ). Node LTS hiện tại là v24.18.0, dù tôi đã chạy test trên v22.22.3 để kết quả không phụ thuộc vào những thay đổi lạ của runtime mới nhất.
Đặt đoạn này vào app.js rồi chạy node app.js:
import axios from 'axios';
const res = await axios.get('https://httpbin.org/ip');
console.log(res.data);
Bạn sẽ thấy IP thật của mình trong response. Đó là mốc nền — khi proxy hoạt động, cùng request này lẽ ra phải trả về IP của proxy.
Hãy ghi lại response này trước khi bật proxy; nó cho bạn một mốc so sánh rõ ràng với request đi qua proxy ở bước tiếp theo.
Axios có thật sự hỗ trợ HTTPS proxy không? (Nói rõ một lần cho đúng)
Câu trả lời ngắn: có, ở bản stable hiện tại. Axios 1.19.0 đã ghi rõ về CONNECT tunneling cho các đích HTTPS đi qua HTTP proxy. API download của npm ghi nhận 117,890,039 lượt tải Axios từ 31/7 đến 6/8/2026, một chỉ dấu khá cũ nhưng cho thấy thư viện này được dùng rộng rãi đến mức nào. Khi bạn truy cập một URL HTTPS qua proxy, Axios hiện tại sẽ gửi CONNECT request để thiết lập đường hầm, còn TLS handshake diễn ra end-to-end với origin thật. Tôi đã kiểm tra trực tiếp: proxy HTTP local, origin HTTPS local với chứng chỉ tự ký, và bộ đếm CONNECT trên proxy tăng đúng như kỳ vọng.
Vậy tại sao câu "Axios HTTPS proxy bị lỗi" lại xuất hiện gần như ở mọi thread trên diễn đàn? Có vài nguyên nhân, và tất cả đều có thật:
- Phiên bản Axios cũ. Những issue GitHub mà người ta dẫn thường đã vài năm tuổi và mô tả hành vi phụ thuộc vào phiên bản hoặc cấu hình, không nên suy rộng cho Axios hiện tại.
- Proxy server không hỗ trợ CONNECT. Trong trường hợp đó, tunnel sẽ thất bại và Axios nên báo lỗi; hãy bắt đúng tuyến đi và lỗi thực tế trước khi kết luận là IP bị bypass.
- Nhầm tuỳ chọn
proxyvới thứ nó không phải.proxylà chỉ thị cho forward proxy, không phải công tắc chung kiểu "mọi thứ cứ đi qua agent này bất kể thế nào".
Chromium từng báo cáo năm 2023 rằng hơn 90% lượt điều hướng Chrome trên các nền tảng lớn dùng HTTPS. Đây là số liệu cũ của Chrome, không phải thống kê toàn bộ web ở hiện tại, nhưng nó cho thấy vì sao hành vi với đích HTTPS phải là trọng tâm của hướng dẫn này. Nếu bạn đang dùng bản Axios cũ, hãy tái hiện lỗi trên nhánh hiện tại trước khi cho rằng vấn đề lịch sử vẫn còn đúng; nên test nâng cấp ngay trong ứng dụng của bạn trước khi deploy.
Khi nào bạn vẫn nên dùng agent tường minh
Cấu hình proxy gốc của Axios đủ ổn cho một proxy tĩnh, đơn giản. Nhưng nó bắt đầu yếu đi ngay khi bạn cần kiểm soát theo từng request, xoay vòng proxy, hoặc hỗ trợ SOCKS — tuỳ chọn tích hợp sẵn của Axios vốn không sinh ra cho các nhu cầu đó. Đây là lúc HttpsProxyAgent phát huy tác dụng, và tôi sẽ đi qua ngay bên dưới. Hãy coi tuỳ chọn native là "đủ dùng cho một proxy, một mục đích" và cách dùng agent là "thứ bạn thật sự muốn trong production."
Đường proxy qua biến môi trường ở Node v24 và v22.21+
Các bản Node gần đây có sẵn chế độ proxy qua environment, kích hoạt bằng NODE_USE_ENV_PROXY=1 hoặc cờ --use-env-proxy. Theo tài liệu CLI của Node, tính năng này xuất hiện từ v24.0.0 và được backport về v22.21.0 — vì vậy nói "Node 22+" là không chính xác; phải là v22.21.0 trở lên trong nhánh đó. Nếu bạn đang ở một bản vá Node 22 cũ hơn, cờ này hoàn toàn không tồn tại.
Axios hiện tại đã đọc HTTP_PROXY, HTTPS_PROXY và NO_PROXY thông qua dependency proxy-from-env, nên bạn không cần global-agent cho đường đi này. Khi chế độ env-proxy của chính Node cũng được bật, có thể sẽ có hai lớp tham gia vào quyết định định tuyến.
Tài liệu Axios ghi chú rằng trên các bản Node có thuộc tính proxyEnv ở agent, Axios sẽ nhường phần xử lý cho Node thay vì tự resolve. Trên thực tế, điều này có nghĩa là bạn nên chọn một cơ chế duy nhất và nhất quán:
- Để Node xử lý: bật cờ, không cấu hình
proxytrong Axios, và để biến môi trường làm việc. - Để Axios xử lý: không bật cờ của Node, và để cơ chế đọc biến môi trường của riêng Axios hoạt động.
- Kiểm soát hoàn toàn thủ công: đặt rõ
proxy: falsevà cung cấphttpsAgentcủa riêng bạn — cách này bỏ qua cả hai hệ thống tự động, và đó là lựa chọn tôi khuyên dùng khi bạn cần xoay vòng hoặc logic theo từng request.
Tôi đã test trực tiếp đường resolve của Axios: đặt HTTP_PROXY trong environment của một child process khiến request đi qua proxy local của tôi, và thêm một mục NO_PROXY tương ứng thì request tiếp theo đã bỏ qua proxy đúng cách. Nghĩa là đường biến môi trường hiện đã hoạt động ngay từ đầu — điều bạn cần chú ý là kịch bản hai cơ chế cùng bật một lúc.
5 cách nối proxy vào Axios (so sánh nhanh)
Trước khi vào code, hãy nhìn tổng quan. Tôi đã build và test từng cách dưới đây trên một cấu hình proxy local thật, chứ không chỉ đọc tài liệu.
| Phương pháp | Hỗ trợ HTTPS | Hỗ trợ xác thực | Kiểm soát theo từng request | Hợp với xoay vòng | Độ phức tạp |
|---|---|---|---|---|---|
Tuỳ chọn proxy ngay trong request | ✅ (Axios hiện tại) | ✅ | ✅ | ❌ | Thấp |
Mặc định của axios.create() | ✅ (Axios hiện tại) | ✅ | ❌ (áp dụng cho cả instance) | ❌ | Thấp |
Biến môi trường (HTTP_PROXY/HTTPS_PROXY) | ✅ | ✅ | ❌ | ❌ | Thấp |
httpsAgent + HttpsProxyAgent | ✅ | ✅ | ✅ | ⚠️ (thủ công) | Trung bình |
| Request interceptor + pool agent | ✅ | ✅ | ✅ | ✅ | Trung bình - Cao |
Dùng tuỳ chọn inline khi bạn chỉ cần một script nhỏ đi qua một proxy. Dùng axios.create() khi mọi request trong một module đều nên đi qua cùng một proxy mà không muốn lặp config. Dùng biến môi trường khi team hạ tầng của bạn đã quản lý routing proxy tập trung và bạn chỉ muốn kế thừa. Dùng explicit agent khi bạn cần mức kiểm soát mà config native không thể mang lại — và chuyển sang pattern interceptor ngay khi "kiểm soát" biến thành "xoay vòng".
Từng bước: cấu hình proxy cơ bản trong Axios
Thiết lập đơn giản nhất là dùng trực tiếp object proxy tích hợp sẵn ngay trong request:
import axios from 'axios';
const res = await axios.get('https://httpbin.org/ip', {
proxy: {
host: '203.0.113.10',
port: 8080,
protocol: 'http',
},
});
console.log(res.data);
Chạy đoạn này và bạn sẽ thấy IP của proxy trong response thay vì IP của mình. Nếu bạn đang test local với một proxy thật, cách này thường chỉ mất chưa đến một giây — so với việc phải cấu hình proxy ở cấp hệ thống chỉ để test một request, kiểu đó thường nuốt mất mười lăm phút mà bạn chẳng dư ra.
Hãy so sánh response này với mốc nền. Một test thành công sẽ hiển thị IP công khai của proxy thay vì IP gốc bạn đã ghi lại ở bước trước.
Dùng axios.create() để đặt mặc định cho cả instance
Nếu mọi request trong một module đều phải đi qua cùng một proxy, hãy nhét cấu hình đó vào instance thay vì lặp lại ở từng nơi:
const client = axios.create({
proxy: {
host: '203.0.113.10',
port: 8080,
},
timeout: 15_000,
});
const res = await client.get('https://httpbin.org/ip');
Tôi đã xác minh rằng ghi đè proxy: false trên một request riêng lẻ sẽ bỏ qua mặc định của instance một cách sạch sẽ — rất hữu ích nếu 95% request của bạn cần proxy nhưng một vài request (ví dụ ping health-check) thì không cần.
Đặt proxy bằng biến môi trường
Với routing được quản lý tập trung — ví dụ trong container Docker hoặc môi trường CI nơi đội ops đã set sẵn biến proxy — bạn không cần đụng đến config Axios:
export HTTP_PROXY=http://203.0.113.10:8080
export HTTPS_PROXY=http://203.0.113.10:8080
export NO_PROXY=localhost,127.0.0.1
Axios hiện tại đọc các biến này mà không cần global-agent. Chỉ cần nhớ mốc phiên bản của Node ở trên: nếu NODE_USE_ENV_PROXY cũng đang bật, hãy xác định rõ ai là bên chịu trách nhiệm routing và test hành vi NO_PROXY ngay trong runtime thực tế đã deploy.
Từng bước: thiết lập HTTPS proxy với httpsAgent (khi bạn cần kiểm soát thật sự)
Đây là cách tôi sẽ khuyên dùng khi bạn cần hơn mức "một proxy, mãi mãi". Cài package agent hiện tại:
npm install https-proxy-agent
https-proxy-agent 9.1.0 yêu cầu Node 20 trở lên và sẽ gửi CONNECT chuẩn đến proxy trước khi tunnel kết nối đích qua nó.
import axios from 'axios';
import { HttpsProxyAgent } from 'https-proxy-agent';
const agent = new HttpsProxyAgent('http://203.0.113.10:8080');
const client = axios.create({
proxy: false, // ngăn cơ chế resolve native của Axios tự chen vào
httpsAgent: agent,
timeout: 15_000,
});
const res = await client.get('https://httpbin.org/ip');
console.log(res.data);
Hãy đặt proxy: false khi bạn đã giao routing cho một agent tường minh. Làm vậy giúp cấu hình rõ ràng, đồng thời ngăn cơ chế resolve proxy native hoặc qua environment của Axios cạnh tranh với agent bạn cung cấp.
Thêm xác thực proxy
Nhúng luôn thông tin đăng nhập vào URL proxy:
const agent = new HttpsProxyAgent('http://myuser:mypassword@203.0.113.10:8080');
Nếu mật khẩu có ký tự đặc biệt — @, : và # là những ký tự hay gây rắc rối nhất — hãy mã hoá theo percent-encoding trước khi ghép URL, hoặc tự tạo chuỗi bằng encodeURIComponent() cho từng thành phần. Một ký tự @ thô trong mật khẩu sẽ bị hiểu thành bắt đầu phần host, và bạn sẽ nhận lỗi kết nối mà nhìn qua chẳng có gì liên quan đến encoding.
Dùng SOCKS5 proxy với Axios
SOCKS proxy không tương thích với HttpsProxyAgent — bạn cần một agent khác cho giao thức này:
npm install socks-proxy-agent
import { SocksProxyAgent } from 'socks-proxy-agent';
const agent = new SocksProxyAgent('socks5://myuser:mypass@203.0.113.10:1080');
const client = axios.create({
proxy: false,
httpsAgent: agent,
});
socks-proxy-agent 10.1.0 cũng yêu cầu Node 20+. SOCKS5 đáng dùng khi bạn làm việc với các mạng doanh nghiệp chỉ mở cổng SOCKS gateway, hoặc với nhà cung cấp proxy có hỗ trợ giao thức linh hoạt hơn so với HTTP proxy thông thường.
Xoay vòng proxy với Axios request interceptor
Chọn ngẫu nhiên một proxy ngay trong code gọi request thì ổn cho script chạy một lần. Nhưng khi bạn gửi hàng trăm request, cách này bắt đầu vỡ: không có nơi nào quản lý tập trung proxy nào đã chết, không có retry logic, và phần chọn proxy sẽ bị copy-paste khắp nơi. Hệ thống interceptor của Axios cho logic đó một chỗ duy nhất để kiểm thử; trong năm bài đối thủ mà tôi rà soát SERP, không bài nào dùng pattern này.
Xây dựng proxy pool
import axios, { AxiosError, InternalAxiosRequestConfig } from 'axios';
import { HttpsProxyAgent } from 'https-proxy-agent';
class ProxyPool {
private agents: HttpsProxyAgent<string>[];
private index = 0;
constructor(proxyUrls: string[]) {
this.agents = proxyUrls.map((url) => new HttpsProxyAgent(url));
}
next(): HttpsProxyAgent<string> {
const agent = this.agents[this.index];
this.index = (this.index + 1) % this.agents.length;
return agent;
}
}
const pool = new ProxyPool([
'http://user:pass@proxy1.example.com:8080',
'http://user:pass@proxy2.example.com:8080',
]);
const client = axios.create({ timeout: 15_000 });
client.interceptors.request.use((config: InternalAxiosRequestConfig) => {
config.proxy = false;
config.httpsAgent = pool.next();
return config;
});
Tôi đã chạy đoạn này qua hai proxy local và xác nhận request luân phiên đúng: proxy A, rồi proxy B, rồi quay lại A. Lưu ý rằng Axios thực thi request interceptor theo thứ tự vào sau ra trước, nên nếu bạn còn interceptor khác (header auth, logging), thứ tự quan trọng hơn bạn tưởng.
Thêm response interceptor với guard cho retry
Đây là chỗ mà hầu hết script xoay vòng tự viết đều làm khá ẩu. Retry mù quáng cho mọi lỗi, trên một pool vô hạn, có thể biến một request hỏng thành một chuỗi sự cố dây chuyền — đặc biệt với các method không idempotent như POST, vì retry có thể nhân đôi một side effect mà bạn hoàn toàn không muốn lặp lại.
type RetryableConfig = InternalAxiosRequestConfig & {
__proxyRetryCount?: number;
};
client.interceptors.response.use(
undefined,
async (error: AxiosError) => {
const config = error.config as RetryableConfig | undefined;
if (!config) throw error;
const method = String(config.method ?? 'get').toUpperCase();
config.__proxyRetryCount ??= 0;
if (method !== 'GET' || config.__proxyRetryCount >= 1) throw error;
config.__proxyRetryCount += 1;
config.proxy = false;
config.httpsAgent = pool.next();
return client.request(config);
}
);
Tôi đã test đoạn này với một proxy cố tình bị hỏng và xác nhận chỉ có đúng một lần retry được gửi sang agent khác — không vòng lặp vô hạn, không retry trên POST. Đó mới là giới hạn đúng: một chính sách retry trung thực với những request nào có thể lặp lại an toàn, chứ không phải kiểu "cứ thử lại đến khi được".
Bảng chẩn đoán lỗi: map từng lỗi với cách khắc phục
Hãy bookmark phần này. Đây là những lỗi thực sự xuất hiện trong issue GitHub của Axios và các thread Stack Overflow, không phải lỗi giả định.
| Lỗi / Triệu chứng | Nguyên nhân có thể | Cách khắc phục |
|---|---|---|
ECONNREFUSED | Sai host/port, hoặc máy chủ proxy đang tắt | Kiểm tra bằng curl -x http://host:port target-url trước khi đụng vào code Axios |
407 Proxy Authentication Required | Thiếu hoặc sai thông tin đăng nhập | Thêm auth: { username, password } vào config proxy, hoặc nhúng credentials vào URL của HttpsProxyAgent |
403 Forbidden | Origin hoặc WAF từ chối request hoặc IP proxy | Kiểm tra chính sách truy cập, xác thực và tần suất request của site; đừng coi việc đổi header hay IP là quyền được vượt qua giới hạn |
| Response vẫn hiện IP thật của bạn | NO_PROXY, proxy:false, một direct agent tường minh, hoặc cấu hình lịch sử/phụ thuộc phiên bản đang bypass proxy | Xác định rõ lớp nào đang sở hữu routing; nếu cần, hãy kiểm tra đường đi bằng endpoint IP được kiểm soát và explicit agent |
ETIMEDOUT | Khoảng thời gian connect hoặc phản hồi vượt quá timeout đã đặt | Đo xem thời gian bị tiêu ở đâu; chỉ tăng timeout nếu workload thực sự cần, còn không thì thay route hoặc cho route lỗi nghỉ tạm |
ECONNRESET giữa chừng khi nhận response | Proxy, mạng hoặc origin đã đóng kết nối | Ghi lại hop bị lỗi; chỉ retry những request an toàn để phát lại, với số lần giới hạn |
502 Bad Gateway sau Nginx | Cấu hình proxy_pass của Nginx sai, hoặc timeout của Axios không khớp với Nginx | Kiểm tra proxy_connect_timeout và proxy_read_timeout (cả hai mặc định 60s) và đồng bộ với timeout của Axios |
ERR_TLS_CERT_ALTNAME_INVALID | Dùng sai loại agent cho target, hoặc chứng chỉ self-signed | Xác nhận bạn đang dùng đúng agent cho đúng giao thức; chỉ đặt rejectUnauthorized: false cho test local — tuyệt đối không dùng trong production |
Checklist debug nhanh
Khi có gì đó hỏng mà bạn không biết vì sao, hãy làm theo thứ tự này:
- Test proxy trực tiếp bằng
curl -x http://host:port https://your-target.com. Nếu fail, hãy xem lại kết nối proxy, xác thực và chính target trước khi sửa Axios. Nếu pass, đường đi qua Axios vẫn cần kiểm tra riêng. - Xác nhận chính xác bạn đang chạy phiên bản Axios và Node nào, rồi so sánh các báo cáo lịch sử với cùng release/cấu hình trước khi áp dụng bản vá của họ.
- Xác định ai đang resolve proxy — config native của Axios, cơ chế đọc env của Axios, chế độ env-proxy tích hợp của Node, hay một explicit agent. Đừng để hơn một lớp cùng sở hữu một request.
- Kiểm tra
NO_PROXYxem có vô tình khớp hostname nào không. - Nếu dùng explicit agent, hãy bảo đảm
proxy: falseđã được đặt để Axios không xử lý hai lần.
Khi nào nên bỏ hẳn việc tự ráp proxy plumbing
Tất cả những thứ trên đều rất hữu ích nếu mục tiêu thực sự của bạn là định tuyến lưu lượng bất kỳ — test mạng doanh nghiệp, geo-test ứng dụng, hoặc kiểm soát lối ra của traffic. Nhưng nhiều lập trình viên tìm đến câu hỏi "làm sao set Axios proxy" vì thứ họ thật sự muốn là dữ liệu từ một website, còn proxy chỉ là phương tiện.
Nếu đúng là trường hợp của bạn, hãy tự hỏi liệu bạn có thật sự cần proxy không, hay bạn cần một scraping API lo luôn hạ tầng cho bạn. Open API của Thunderbit nhận một URL và schema rồi trả về JSON có cấu trúc — không cần parse HTML thô, không cần thư viện agent, cũng không phải tự chăm sóc proxy pool. Endpoint /extract xử lý cả trang render bằng JS, cơ chế anti-bot và CAPTCHA ở phía server, còn /distill nhẹ hơn, chỉ chuyển trang thành Markdown sạch nếu đó là tất cả những gì bạn cần. Thunderbit cũng có MCP server cung cấp các công cụ như thunderbit_extract và thunderbit_suggest_fields, để các coding assistant như Claude hoặc Cursor có thể lấy dữ liệu có cấu trúc ngay trong lúc làm việc mà không cần chạm vào cấu hình proxy, cùng với một CLI cho terminal và workflow CI.
| Mối quan tâm | DIY Axios + Proxies | Thunderbit API/MCP/CLI |
|---|---|---|
| Nguồn proxy & xoay vòng | Bạn tự quản lý | Được xử lý ở phía server |
| Khó khăn về browser và truy cập | Bạn phải vận hành lớp browser/mạng | Được dịch vụ quản lý trong phạm vi khả năng đã công bố |
| Trang render bằng JS | Cần headless browser | renderMode: full |
| Định dạng đầu ra | HTML thô → bạn tự parse | JSON có cấu trúc qua schema |
| Bảo trì khi website thay đổi | Bạn tự cập nhật parsing/selectors | Lớp extraction được quản lý giúp giảm một phần công bảo trì phía ứng dụng |
Cách nhìn trung thực là: nếu bạn cần định tuyến lưu lượng để test hoặc phục vụ mạng nội bộ doanh nghiệp, thì những gì ở trên không thay thế Axios và config proxy. Nhưng nếu đầu ra bạn cần là dữ liệu web có cấu trúc, một cách tiếp cận API-first có thể giảm đáng kể phần code proxy, browser và parsing mà ứng dụng của bạn phải gánh. Khi truy xuất vào ngày 7/8/2026, tài liệu rate limit của Thunderbit API cho biết gói Free giới hạn 10 request mỗi phút và 2 request đồng thời. Hãy coi đó là giới hạn API có thể thay đổi theo thời điểm và kiểm tra lại trang trước khi dựa vào nó trong production.
Tổng kết
Bài học cốt lõi ở đây đi ngược lại khá nhiều tutorial cũ: Axios hiện tại có tài liệu rõ ràng và, trong test local đã ghi nhận, dùng CONNECT tunneling cho đích HTTPS một cách đúng đắn. Những lỗi lịch sử vẫn quan trọng, nhưng cần đặt đúng bối cảnh phiên bản và cấu hình. Config native là điểm khởi đầu đơn giản, ít phức tạp; khi bạn cần kiểm soát theo request, hỗ trợ SOCKS, hoặc xoay vòng, một HttpsProxyAgent (hoặc SocksProxyAgent) tường minh kết hợp với proxy: false sẽ cho bạn quyền sở hữu rõ ràng hơn. Và nếu bạn đang xoay vòng qua một pool trong production, request/response interceptor sẽ cho bạn một nơi tập trung, dễ test để làm việc đó — chỉ cần đảm bảo logic retry có guard chống vòng lặp và chỉ phát lại những request thực sự an toàn để lặp lại.
Hãy bookmark bảng chẩn đoán ở trên để dùng lần tới khi cấu hình proxy ném ra một lỗi khó hiểu lúc 2 giờ sáng. Và nếu bạn nhận ra mình đang tốn nhiều thời gian debug proxy plumbing hơn là sử dụng chính dữ liệu cần lấy, có lẽ đã đến lúc xem một công cụ trích xuất theo hướng API-first có giải quyết vấn đề thật nhanh hơn cả tầng hạ tầng hay không.
Câu hỏi thường gặp
Axios có hỗ trợ HTTPS proxy một cách native không? Có, trong Axios hiện tại với một HTTP proxy thông thường: tài liệu hiện hành mô tả CONNECT tunneling cho đích HTTPS, và Axios 1.19.0 đã đi qua tuyến đó thành công trong test local đã ghi nhận. Các bản phát hành cũ và một số cấu hình proxy cụ thể từng gây lỗi thật, nên hãy kiểm tra đúng phiên bản và proxy thay vì mặc định rằng lúc nào cũng thành công hoặc lúc nào cũng thất bại.
Làm sao xoay vòng proxy trong Axios?
Dùng request interceptor để gán một httpsAgent khác từ proxy pool trước khi mỗi request được gửi đi, rồi kết hợp với response interceptor để retry request thất bại trên proxy khác. Giữ logic retry ở mức giới hạn — một lần retry, và chỉ với method idempotent như GET — để không vô tình phát lại một request không nên được phát lại.
Vì sao proxy Axios của tôi lại hiện IP thật?
Kiểm tra xem NO_PROXY, proxy:false, một direct agent tường minh, hoặc routing theo môi trường deploy có đang bypass proxy không. Ghi lại phiên bản Axios/Node và test proxy độc lập bằng cURL. Nếu bạn cần routing theo từng request một cách không mập mờ, hãy dùng HttpsProxyAgent với proxy:false và xác minh IP quan sát được trên một endpoint kiểm soát được.
Tôi có thể dùng SOCKS5 proxy với Axios không?
Có, thông qua package socks-proxy-agent. Tạo một instance SocksProxyAgent với URL SOCKS của bạn rồi truyền nó vào httpsAgent trong config Axios — chỉ cần đảm bảo bạn không đồng thời truyền HttpsProxyAgent, vì hai giao thức này dùng loại agent khác nhau.
Khác nhau giữa tuỳ chọn proxy và httpsAgent trong Axios là gì?
Tuỳ chọn proxy là config tích hợp sẵn của Axios cho một proxy đơn lẻ, tĩnh, và dùng ổn cho các tình huống đơn giản trong các phiên bản hiện tại. httpsAgent nhận một Node.js agent tuỳ chỉnh — như HttpsProxyAgent hoặc SocksProxyAgent — cho bạn quyền kiểm soát trực tiếp theo từng request đối với routing, xác thực và xoay vòng, những thứ mà tuỳ chọn native vốn không được thiết kế để xử lý.
