Gemini CLI proxy: cấu hình cho CLI, API và máy chủ MCP
Gemini CLI proxy là cách cho công cụ dòng lệnh Gemini CLI của Google đi ra Internet qua proxy. Gemini CLI có ba lớp mạng tách biệt: tiến trình CLI gọi API, máy chủ MCP chạy dạng tiến trình con, và sandbox. Mỗi lớp nhận proxy theo cách riêng. ProxyVN đọc tài liệu và mã nguồn Gemini CLI để lập ma trận cấu hình cho từng lớp.
Gemini CLI proxy có ba lớp mạng
Ba lớp mạng của CLI
Tiến trình CLI, máy chủ MCP và sandbox
Gemini CLI là trợ lý dòng lệnh mã nguồn mở viết bằng Node.js, phát hành qua gói npm @google/gemini-cli, bản mới nhất trên npm ngày 27/10/2026 là 0.65.0. Khi chạy, nó không chỉ gọi API Gemini. Nó có thể khởi chạy máy chủ MCP làm tiến trình con, kết nối tới máy chủ MCP qua HTTP, và chạy công cụ trong sandbox container hoặc sandbox của macOS.
Ba lớp này nhận proxy khác nhau. Tiến trình CLI đọc biến môi trường proxy và gắn một dispatcher toàn cục cho fetch. Máy chủ MCP chạy dạng tiến trình con nhận biến môi trường đã qua lọc, kèm khối env riêng trong cấu hình. Sandbox có cơ chế proxy riêng qua biến GEMINI_SANDBOX_PROXY_COMMAND.
Đặt HTTPS_PROXY xong mà một máy chủ MCP vẫn đi thẳng là chuyện bình thường nếu chưa hiểu ba lớp này. Phần sau đi lần lượt từng lớp.
Ranh giới với các bài proxy AI khác
Bài proxy cho AI agent tự động nói về proxy cho agent tự viết ở mức chung. Bài này chỉ nói về Gemini CLI: biến nào được đọc, theo thứ tự nào, cách truyền vào tiến trình con MCP và sandbox. Bài không so sánh Gemini CLI với công cụ khác.
Proxy không cấp thêm quyền và không tăng hạn mức của khóa API hay tài khoản. Hạn mức gắn với dự án, khóa và gói dịch vụ. Bài không hướng dẫn dùng proxy để lách giới hạn hay đổi vùng.
Phạm vi nguồn
Mình đọc tài liệu trong thư mục docs của kho google-gemini/gemini-cli trên GitHub và các tệp mã nguồn liên quan ở nhánh main ngày 27/10/2026. Mình không cài Gemini CLI và không chạy nó qua proxy thử, vì cần khóa API thật cho mọi request. Các hành vi mô tả dựa trên mã nguồn đã đọc, có thể đổi ở bản sau.
Khi mã nguồn và tài liệu khác nhau, mình ghi rõ đó là theo mã. Trước khi áp dụng, anh em nên kiểm lại với bản đang cài bằng các ca kiểm ở cuối bài.
Cấu hình Gemini CLI proxy cho tiến trình CLI
Thứ tự đọc biến môi trường
Trong mã cấu hình của gói cli, giá trị proxy lấy từ biến đầu tiên có giá trị theo thứ tự HTTPS_PROXY, https_proxy, HTTP_PROXY, http_proxy. Như vậy biến chữ hoa thắng chữ thường, và HTTPS thắng HTTP. Thứ tự này khác vài công cụ khác, nơi chữ thường được ưu tiên.
# macOS, Linux
export HTTPS_PROXY="http://proxy.example.com:8080"
export NO_PROXY="localhost,127.0.0.1,.corp.example"
gemini
# Windows PowerShell
$env:HTTPS_PROXY = "http://proxy.example.com:8080"
$env:NO_PROXY = "localhost,127.0.0.1,.corp.example"
geminiGiá trị trong cả bốn biến đều được dùng cho cả request http lẫn https. Không cần đặt riêng HTTP_PROXY nếu đã có HTTPS_PROXY.
Dispatcher toàn cục của Undici
Khi có giá trị proxy, lớp Config của gói core gọi hàm setGlobalProxy. Hàm này đặt dispatcher toàn cục của Undici bằng EnvHttpProxyAgent, truyền cùng một URL proxy cho cả httpProxy và httpsProxy, đồng thời đọc NO_PROXY hoặc no_proxy làm danh sách bỏ qua. Mọi fetch trong tiến trình CLI vì thế đi qua proxy, trừ host khớp NO_PROXY.
Nếu URL proxy sai định dạng, mã bắt lỗi và hiện thông báo Invalid proxy configuration detected. Check debug drawer for more details (F12). Thông báo này giúp nhận ra lỗi ngay, không phải đợi tới request đầu tiên. Gặp nó, kiểm tiền tố http:// và mã hóa mật khẩu.
Tài khoản trong URL proxy
Vì proxy truyền vào EnvHttpProxyAgent dưới dạng URL, tài khoản đặt trong URL theo dạng http://user:pass@host:port. Mật khẩu có @, #, : hay / phải mã hóa phần trăm, ví dụ p@ss#2026 thành p%40ss%232026. Bài định dạng proxy có bảng mã hóa ký tự.
Mình chưa thấy tài liệu Gemini CLI mô tả hỗ trợ SOCKS. EnvHttpProxyAgent của Undici dành cho proxy HTTP và HTTPS. Nếu gói proxy chỉ có SOCKS5, dùng cổng HTTP của nhà cung cấp hoặc một proxy HTTP trung gian. Bài proxy HTTP và SOCKS5 giúp chọn đúng loại.
Gemini CLI proxy cho máy chủ MCP
Hai kiểu máy chủ MCP
Gemini CLI kết nối máy chủ MCP theo hai kiểu. Kiểu stdio chạy một lệnh như node mcp_server.js hay npx tên-gói làm tiến trình con, nói chuyện qua đầu vào và đầu ra chuẩn. Kiểu HTTP kết nối tới một URL qua httpUrl hoặc url. Proxy áp vào hai kiểu theo cách khác nhau.
Với kiểu HTTP, kết nối do chính tiến trình CLI mở. Với kiểu stdio, tiến trình con tự mở kết nối ra ngoài nếu cần, và nó chỉ dùng proxy nếu chương trình bên trong tự đọc biến proxy. Đây là điểm mấu chốt của cả bài.
MCP qua HTTP tôn trọng NO_PROXY
Trong mã tạo transport URL cho MCP, Gemini CLI tạo một EnvHttpProxyAgent với noProxy lấy từ NO_PROXY hoặc no_proxy. Chú thích trong mã nói rõ mục đích: tôn trọng NO_PROXY cho máy chủ MCP, đặc biệt máy chủ cục bộ ở localhost hay 127.0.0.1 khi công ty đặt proxy toàn cục.
Hệ quả thực tế: nếu chạy máy chủ MCP HTTP trên máy mình ở cổng 3000 và đặt HTTPS_PROXY của công ty, phải có localhost và 127.0.0.1 trong NO_PROXY. Không có, request tới máy chủ cục bộ sẽ bị đẩy ra proxy công ty, proxy không với tới được máy của anh em và báo lỗi. Bài no_proxy là gì giải thích cách viết danh sách này.
MCP stdio nhận môi trường đã lọc
Tiến trình con cần khai env riêng
Với máy chủ stdio, mã của Gemini CLI dựng môi trường cho tiến trình con theo ba bước. Đầu tiên lấy môi trường của tiến trình CLI cộng biến của extension. Sau đó lọc bằng sanitizeEnvironment với chế độ che biến bật, để tránh rò bí mật toàn hệ thống sang tiến trình con. Cuối cùng gộp khối env khai trong cấu hình máy chủ, chặn các biến bị coi là nguy hiểm.
Bước lọc là chỗ cần chú ý. Mã có một danh sách biến luôn được cho qua và một danh sách do người dùng cho phép. Mình chưa đọc hết danh sách mặc định để khẳng định HTTPS_PROXY luôn được truyền. Cách chắc ăn nhất là khai proxy trong khối env của máy chủ MCP như tài liệu enterprise hướng dẫn.
Khai proxy trong mcpServers
Tài liệu Gemini CLI cho doanh nghiệp có mục kiểm soát truy cập mạng qua proxy, với ví dụ khai HTTP_PROXY và HTTPS_PROXY trong khối env của một máy chủ MCP.
{
"mcpServers": {
"proxied-server": {
"command": "node",
"args": ["mcp_server.js"],
"env": {
"HTTP_PROXY": "http://proxy.example.com:8080",
"HTTPS_PROXY": "http://proxy.example.com:8080",
"NO_PROXY": "localhost,127.0.0.1"
}
}
}
}Mình thêm NO_PROXY so với ví dụ gốc để máy chủ MCP không đẩy request nội bộ ra proxy. Khối env cũng hỗ trợ mở rộng biến, nên có thể viết giá trị dạng $HTTPS_PROXY để lấy từ môi trường thay vì ghi cứng URL có mật khẩu.
Chương trình bên trong phải tự đọc biến
Đặt biến cho tiến trình con chưa đủ. Chương trình MCP bên trong phải tự dùng biến đó. Với máy chủ viết bằng Node, fetch tích hợp chỉ đọc biến proxy khi bật NODE_USE_ENV_PROXY=1 từ Node 24.5, hoặc khi chương trình tự gắn dispatcher. Với máy chủ Python dùng requests hay httpx, thư viện thường đọc biến proxy mặc định.
Vì vậy, khi một máy chủ MCP Node vẫn đi thẳng dù đã khai env, thử thêm NODE_USE_ENV_PROXY=1 vào khối env, hoặc đọc mã máy chủ để xem nó dùng thư viện HTTP nào. Bài Node.js fetch proxy giải thích cách fetch của Node nhận proxy.
Ma trận Gemini CLI proxy theo lớp
Bảng tổng hợp
Brief của bài yêu cầu một ma trận CLI, API và MCP subprocess. Bảng dưới tổng hợp từ mã nguồn và tài liệu đã đọc, chưa phải kết quả chạy thử.
Lớp |
Nhận proxy từ đâu |
NO_PROXY |
Ghi chú |
|---|---|---|---|
Tiến trình CLI gọi API |
HTTPS_PROXY, https_proxy, HTTP_PROXY, http_proxy |
Có |
Dispatcher toàn cục của Undici |
Base URL riêng cho API |
GOOGLE_GEMINI_BASE_URL, GOOGLE_VERTEX_BASE_URL |
Không áp dụng |
Phải HTTPS trừ localhost |
MCP qua HTTP |
Proxy của tiến trình CLI |
Có, tạo agent riêng |
Cần localhost trong NO_PROXY cho máy chủ cục bộ |
MCP stdio |
Môi trường đã lọc cộng khối env |
Tùy chương trình |
Chương trình phải tự đọc biến |
Sandbox có proxy |
GEMINI_SANDBOX_PROXY_COMMAND |
Có, truyền vào sandbox |
Mặc định http://localhost:8877 |
Bảng này cho thấy không có một nút gạt duy nhất. Một tổ chức muốn mọi lưu lượng đi qua proxy phải xử lý cả năm dòng.
Base URL không phải proxy chuyển tiếp
Base URL đổi đích, proxy đổi đường
Tài liệu cấu hình có hai biến GOOGLE_GEMINI_BASE_URL và GOOGLE_VERTEX_BASE_URL để đổi địa chỉ gốc của API. Ví dụ trong tài liệu dùng tên my-proxy.com, dễ làm người đọc tưởng đây là cách đặt proxy. Thực ra đây là đổi đích của request sang một cổng trung gian, thường là reverse proxy hay cổng API của công ty.
Tài liệu yêu cầu URL này dùng HTTPS, trừ khi trỏ về localhost. Base URL và HTTPS_PROXY có thể dùng cùng lúc: request đi tới cổng trung gian, và đi qua proxy chuyển tiếp nếu cổng đó nằm ngoài mạng. Đừng đặt địa chỉ proxy HTTP thông thường vào base URL, request sẽ hỏng vì proxy không hiểu API.
Với Gemini CLI, HTTPS_PROXY đổi đường đi, còn GOOGLE_GEMINI_BASE_URL đổi đích đến. Hai biến làm hai việc khác nhau.
Gemini CLI proxy trong sandbox
Hồ sơ proxied trên macOS
Tài liệu sandbox liệt kê các hồ sơ Seatbelt trên macOS: permissive-open là mặc định, ghi giới hạn và cho mạng. Các hồ sơ có hậu tố proxied như permissive-proxied, restrictive-proxied, strict-proxied giữ cùng giới hạn đọc ghi nhưng đưa mạng qua proxy. Chọn hồ sơ bằng biến SEATBELT_PROFILE.
Hồ sơ proxied hợp khi muốn công cụ chạy trong sandbox chỉ ra mạng qua một điểm kiểm soát. Mọi kết nối ngoài proxy bị chặn bởi sandbox, không phụ thuộc chương trình bên trong có đọc biến proxy hay không.
GEMINI_SANDBOX_PROXY_COMMAND
Trong mã khởi chạy sandbox, nếu đặt GEMINI_SANDBOX_PROXY_COMMAND, Gemini CLI chạy lệnh đó làm tiến trình proxy, rồi đặt HTTPS_PROXY, https_proxy, HTTP_PROXY, http_proxy cho môi trường sandbox. Giá trị proxy lấy từ biến của máy chủ, nếu không có thì mặc định http://localhost:8877. Chú thích trong mã nói biến chữ thường cũng được đặt vì một số công cụ như curl cần.
NO_PROXY hoặc no_proxy của máy chủ cũng được truyền vào sandbox nếu có. Khi Gemini CLI thoát, tiến trình proxy được dừng theo. Cơ chế này cho phép tổ chức dùng một proxy lọc tên miền riêng cho sandbox, khác với proxy của tiến trình CLI.
Khi nào dùng sandbox proxied
Với lập trình viên cá nhân, sandbox proxied thường không cần thiết. Với tổ chức cần kiểm soát công cụ nào được ra mạng, sandbox proxied kết hợp danh sách tên miền cho phép là cách đóng chặt nhất. Tài liệu enterprise có ví dụ ép mọi công cụ chạy trong sandbox Docker qua khóa tools.sandbox.
Mình chưa chạy sandbox Docker hay Seatbelt. Phần sandbox trong bài dựa trên mã và tài liệu, cần thử với proxy thật trước khi áp cho cả nhóm.
Giữ log không lộ khóa trong Gemini CLI proxy
Khóa API và tài khoản proxy là hai bí mật khác nhau
Gemini CLI dùng GEMINI_API_KEY hoặc đăng nhập Google để gọi API. Tài khoản proxy là bí mật thứ hai, nằm trong URL proxy. Cả hai đều dễ lộ qua lịch sử lệnh, tệp .env commit nhầm, ảnh chụp màn hình hay log gỡ lỗi.
Khi đặt proxy trong khối env của máy chủ MCP, tệp settings.json chứa URL proxy. Nếu URL có mật khẩu, tệp đó trở thành bí mật. Dùng mở rộng biến kiểu $HTTPS_PROXY trong env để tệp cấu hình chỉ chứa tên biến, còn giá trị nằm trong môi trường.
Bước lọc môi trường giúp gì
Bước sanitizeEnvironment trong mã nhằm ngăn bí mật toàn hệ thống rò sang tiến trình con MCP. Đây là lớp bảo vệ có ích, nhưng không thay cho việc quản lý bí mật. Một biến được khai rõ trong khối env vẫn được truyền, kể cả khi nó chứa mật khẩu.
Nguyên tắc của mình: chỉ truyền cho máy chủ MCP những biến nó cần. Máy chủ MCP đọc tệp cục bộ không cần proxy, đừng truyền proxy cho nó. Máy chủ MCP gọi API bên ngoài cần proxy, truyền đúng URL proxy, không truyền khóa API của Gemini.
Log và gỡ lỗi
Khi gỡ lỗi mạng, đừng in giá trị HTTPS_PROXY ra màn hình chia sẻ. In tên máy và cổng là đủ. Với lỗi xác thực proxy, nhật ký phía proxy cho biết tài khoản nào bị từ chối, an toàn hơn in mật khẩu ở phía máy khách.
Nếu dùng telemetry của Gemini CLI, kiểm cấu hình xem request có gửi kèm thông tin nhạy cảm không. Tài liệu cấu hình có các biến bật tắt telemetry, đọc kỹ trước khi bật trong môi trường có proxy công ty.
Gemini CLI proxy sau proxy kiểm tra TLS của công ty
Lỗi chứng chỉ chỉ xuất hiện ở công ty
Nhiều công ty dùng thiết bị giải mã HTTPS để kiểm nội dung. Thiết bị này thay chứng chỉ của website bằng chứng chỉ do CA nội bộ ký. Trình duyệt trên máy công ty đã được cài CA đó nên không báo lỗi, nhưng tiến trình Node như Gemini CLI có kho chứng chỉ riêng và có thể không tin CA nội bộ.
Triệu chứng điển hình là Gemini CLI chạy tốt ở nhà, còn ở công ty báo lỗi chứng chỉ khi gọi API. Đổi proxy hay đổi tài khoản đều không giúp gì, vì vấn đề nằm ở lòng tin chứng chỉ chứ không ở đường đi.
NODE_EXTRA_CA_CERTS
Node.js đọc biến NODE_EXTRA_CA_CERTS lúc khởi động, thêm các chứng chỉ trong tệp PEM chỉ định vào danh sách tin cậy. Vì Gemini CLI chạy trên Node, đây là cách chuẩn để nó tin CA nội bộ. Biến phải đặt trước khi chạy gemini, đặt sau khi tiến trình đã khởi động không có tác dụng.
export NODE_EXTRA_CA_CERTS=/etc/ssl/certs/corp-root-ca.pem
export HTTPS_PROXY="http://proxy.corp.example:8080"
geminiVới máy chủ MCP viết bằng Node, biến này cũng cần có trong môi trường của tiến trình con. Nếu bước lọc môi trường không cho qua, khai thêm trong khối env của máy chủ MCP. Máy chủ MCP viết bằng Python dùng kho chứng chỉ khác, thường cấu hình qua biến của thư viện như REQUESTS_CA_BUNDLE hoặc SSL_CERT_FILE.
Đừng tắt kiểm tra chứng chỉ
Một số hướng dẫn trên mạng đặt NODE_TLS_REJECT_UNAUTHORIZED=0 để chữa lỗi. Làm vậy tắt toàn bộ kiểm tra chứng chỉ của tiến trình, mọi kết nối HTTPS đều có thể bị chặn bắt mà không ai biết. Với công cụ gửi mã nguồn và khóa API qua mạng, đây là rủi ro không đáng.
Cách đúng là xin đội hạ tầng tệp CA nội bộ dạng PEM, đặt NODE_EXTRA_CA_CERTS và kiểm lại. Bài lỗi NET::ERR_CERT_AUTHORITY_INVALID giải thích cùng hiện tượng ở phía trình duyệt.
Gemini CLI proxy trong CI và chế độ không tương tác
Đặt biến từ mục secret
Gemini CLI có chế độ không tương tác cho script và pipeline. Trong CI, tiến trình chạy trên máy dựng tạm, mỗi lần một môi trường mới. Biến proxy và khóa API phải đặt qua mục secret của hệ thống CI, không ghi trong tệp cấu hình pipeline.
Đặt HTTPS_PROXY, NO_PROXY và GEMINI_API_KEY ở cùng một bước, ngay trước lệnh gọi gemini. Nếu pipeline có nhiều bước dùng proxy khác nhau, đặt biến theo bước thay vì cho toàn pipeline, tránh một bước gọi kho gói nội bộ bị đẩy ra proxy bên ngoài.
Máy dựng sau tường lửa
Máy dựng tự quản trong mạng công ty thường chỉ ra Internet qua proxy. Ngoài API Gemini, Gemini CLI cài qua npm cần registry.npmjs.org hoặc kho gói nội bộ. Máy chủ MCP chạy bằng npx cũng tải gói lúc khởi chạy. Thiếu một trong các đường này, pipeline lỗi ở bước tưởng không liên quan tới proxy.
Mình khuyên tách bước cài đặt và bước chạy. Bước cài đặt dùng cấu hình proxy của npm, bước chạy dùng HTTPS_PROXY cho Gemini CLI. Bài npm proxy hướng dẫn cấu hình proxy cho npm.
Kiểm nhanh trong pipeline
Thêm một bước kiểm trước khi chạy tác vụ chính: gọi một URL công khai bằng curl qua cùng HTTPS_PROXY, in mã trạng thái. Nếu bước này lỗi, dừng pipeline với thông báo rõ ràng về proxy. Cách này rẻ hơn nhiều so với đọc log dài của một lần chạy Gemini CLI thất bại.
Chạy đối chứng Gemini CLI proxy
Proxy cục bộ có nhật ký
Cách chắc nhất để biết từng lớp đi đường nào là trỏ tất cả vào một proxy ghi nhật ký. Có thể dùng mitmproxy ở chế độ thường, Squid hoặc một proxy nhỏ tự viết. Yêu cầu là ghi được phương thức, host đích và có tiêu đề Proxy-Authorization hay không.
Đặt HTTPS_PROXY trỏ về proxy cục bộ, NO_PROXY có localhost. Khai một máy chủ MCP stdio đơn giản gọi một URL bên ngoài, và một máy chủ MCP HTTP chạy cục bộ.
Bộ ca kiểm theo ma trận
- Câu hỏi ngắn tới Gemini: nhật ký proxy có CONNECT tới tên miền API của Google.
- Proxy sai định dạng: CLI hiện thông báo Invalid proxy configuration detected.
- MCP HTTP cục bộ: nhật ký proxy không có dòng cho localhost.
- MCP stdio không khai env: kiểm request ra ngoài của máy chủ có qua proxy không.
- MCP stdio có khai env: request ra ngoài có trong nhật ký proxy.
- MCP stdio viết bằng Node: nếu vẫn đi thẳng, thêm NODE_USE_ENV_PROXY=1.
- Sai mật khẩu proxy: CLI báo lỗi kết nối, nhật ký proxy ghi 407.
Ca MCP stdio không khai env là ca trả lời câu hỏi bước lọc môi trường có truyền biến proxy không trên bản đang cài. Ghi kết quả lại để cả nhóm không phải thử lại.
Ghi kết quả
Lập bảng gồm bản Gemini CLI, bản Node, hệ điều hành và kết quả từng ca. Mỗi lần nâng Gemini CLI, chạy lại. Mã nguồn thay đổi nhanh, hành vi lọc môi trường hay transport MCP có thể đổi giữa các bản.
Chọn loại proxy cho Gemini CLI proxy
Proxy công ty hay proxy riêng
Trong doanh nghiệp, Gemini CLI thường đi qua proxy công ty có sẵn. Với cá nhân hoặc nhóm nhỏ, có khi cần proxy riêng để có IP ra cố định, ví dụ khi API đối tác mà máy chủ MCP gọi chỉ cho phép một số IP.
Với nhu cầu IP ra cố định, proxy tĩnh phù hợp hơn proxy xoay. Proxy xoay làm IP ra đổi giữa các request, dễ xung đột với danh sách IP cho phép của API đối tác. Chọn proxy HTTP có hỗ trợ CONNECT tới cổng 443.
ProxyVN có proxy dân cư tĩnh và datacenter với IP cố định, hỗ trợ HTTP và SOCKS5, cấp tài khoản user và mật khẩu. Nếu cần proxy HTTP cho Gemini CLI hoặc cho máy chủ MCP gọi API đối tác, anh em có thể mua proxy uy tín tại trang chủ ProxyVN rồi chạy bộ ca kiểm ở trên.
Proxy riêng cho từng máy chủ MCP
Vì khối env khai theo từng máy chủ, có thể cho mỗi máy chủ MCP một proxy khác nhau. Máy chủ lấy dữ liệu từ thị trường A dùng proxy vùng A, máy chủ khác dùng proxy công ty. Cách này linh hoạt nhưng làm cấu hình phức tạp, chỉ dùng khi thật sự cần.
Nhớ rằng nếu máy chủ MCP gọi website bên ngoài với tần suất cao, proxy chỉ đổi IP, không đổi cách website đánh giá request. Tôn trọng điều khoản và giới hạn tốc độ của website. Bài lỗi 429 khi dùng proxy có cách xử lý khi bị giới hạn tần suất.
Câu hỏi thường gặp về Gemini CLI proxy
Gemini CLI có cờ dòng lệnh proxy không. Theo mã cấu hình đã đọc, giá trị proxy lấy từ biến môi trường. Mình không thấy cờ proxy riêng trong tài liệu tham chiếu dòng lệnh hiện hành.
Biến chữ hoa hay chữ thường thắng. Theo mã, HTTPS_PROXY được kiểm trước https_proxy, rồi tới HTTP_PROXY, http_proxy.
Có dùng được SOCKS5 không. Mình không thấy tài liệu nói hỗ trợ. Dispatcher dùng EnvHttpProxyAgent cho proxy HTTP, HTTPS. Dùng cổng HTTP.
Vì sao máy chủ MCP cục bộ lỗi khi bật proxy công ty. Thiếu localhost hoặc 127.0.0.1 trong NO_PROXY, request bị đẩy ra proxy.
Máy chủ MCP stdio có tự nhận proxy không. Tùy bước lọc môi trường và tùy chương trình. Khai proxy trong khối env của máy chủ cho chắc, và kiểm chương trình có đọc biến không.
GOOGLE_GEMINI_BASE_URL có phải proxy không. Không. Đó là đổi đích API sang một cổng trung gian, phải dùng HTTPS trừ localhost.
Proxy có giúp tăng hạn mức API không. Không. Hạn mức gắn với khóa, dự án và gói.
Đổi proxy giữa phiên có được không. Không nên kỳ vọng. Dispatcher toàn cục được gắn khi cấu hình nạp lúc khởi động. Muốn đổi proxy, thoát Gemini CLI, đổi biến rồi mở lại.
Máy chủ MCP HTTP ở xa có đi qua proxy không. Có, transport HTTP của MCP dùng agent nhận proxy từ môi trường và tôn trọng NO_PROXY. Nếu máy chủ nằm trong mạng nội bộ, thêm tên miền của nó vào NO_PROXY.
Có cần đặt proxy cho cả npm không. Có nếu cài Gemini CLI hoặc chạy máy chủ MCP bằng npx sau tường lửa. npm có cấu hình proxy riêng, không phụ thuộc biến của Gemini CLI.
Checklist Gemini CLI proxy
Checklist Gemini CLI proxy
Trước khi triển khai
- HTTPS_PROXY có tiền tố http://, mật khẩu đã mã hóa phần trăm.
- NO_PROXY có localhost và 127.0.0.1 nếu dùng máy chủ MCP cục bộ.
- Khai proxy trong khối env của máy chủ MCP stdio cần mạng.
- Máy chủ MCP Node có NODE_USE_ENV_PROXY=1 hoặc tự gắn dispatcher.
- Không nhầm base URL với proxy.
- Dùng mở rộng biến thay vì ghi cứng mật khẩu trong settings.json.
- Chỉ truyền biến máy chủ MCP cần.
- Chạy bộ ca kiểm với proxy cục bộ có nhật ký.
Giới hạn của bài
Bài dựa trên tài liệu và mã nguồn nhánh main của Gemini CLI ngày 27/10/2026, bản npm 0.65.0. Mình không cài và không chạy Gemini CLI qua proxy thử vì cần khóa API thật. Chưa kiểm danh sách biến mặc định của bước lọc môi trường, chưa thử sandbox Docker hay Seatbelt, chưa thử gateway thương mại.
Gemini CLI proxy và những điều cần nhớ
Gemini CLI proxy có ba lớp: tiến trình CLI đọc HTTPS_PROXY rồi gắn dispatcher toàn cục, máy chủ MCP stdio cần khai env riêng, sandbox dùng GEMINI_SANDBOX_PROXY_COMMAND. Thêm localhost vào NO_PROXY, không nhầm base URL với proxy. Cần proxy HTTP ổn định cho Gemini CLI proxy, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.
