LiteLLM outbound proxy: tách gateway và đường ra tới provider

Chuyên viên Kỹ thuật ProxyVN 02-12-2026 Đang tính... phút đọc

LiteLLM outbound proxy là tuyến mạng mà LiteLLM dùng để gọi ra nhà cung cấp model, ví dụ đi qua proxy công ty thay vì ra Internet trực tiếp. Nhiều người nhầm nó với LiteLLM Proxy, tên gọi của chính gateway. Hai thứ nằm ở hai đầu khác nhau của đường đi. ProxyVN dựng một provider giả, một proxy ghi log và gateway LiteLLM 1.106.6 ngày 03/11/2026, rồi đo từng hop xem request đi đường nào và API key lộ ở đâu. Bài ghi rõ phần đã chạy và phần chưa thử.

LiteLLM outbound proxy: mục tiêu và phạm vi không lặp

Phần này chốt bài toán và đầu ra.

Bài toán

Một nhóm chạy LiteLLM để gom nhiều nhà cung cấp model sau một API chung. Máy chủ chạy LiteLLM nằm trong mạng chỉ cho ra Internet qua proxy công ty. Nhóm cần biết đặt biến nào để request tới provider đi qua proxy, request nào không nên đi qua, và key nào có thể bị proxy nhìn thấy.

Đầu ra nghiệm thu

Đầu ra gồm sơ đồ client, gateway, proxy, provider và bảng kiểm đường egress. Bảng ghi mỗi ca cấu hình đi qua hop nào, hop đó thấy gì, và key có lộ ra ngoài nơi cần thấy nó hay không.

Tên gọi dễ nhầm

LiteLLM gọi gateway của mình là LiteLLM Proxy Server. Đó là reverse proxy: nhận request từ ứng dụng, xác thực bằng key riêng, rồi gọi provider. Outbound proxy thì ngược lại, là forward proxy nằm giữa LiteLLM và provider. Bài dùng chữ gateway cho cái đầu và chữ proxy cho cái sau để khỏi lẫn.

Ranh giới với bài khác

Bài không bàn cân bằng tải giữa nhiều provider, không bàn reverse proxy chia tải API. Cũng không bàn việc dùng proxy IP để vượt hạn mức của provider. Proxy không tăng quota, không thay key và không làm request hợp lệ hơn.

Phiên bản đã khóa

Lab dùng litellm 1.106.6 cài kèm phần proxy, openai 2.54.0, httpx 0.28.1, aiohttp 3.14.5, Python 3.12 trên Windows. Provider là máy chủ giả trả lời kiểu OpenAI, không gọi nhà cung cấp thật nào. Mọi con số lấy từ lần chạy này. Hành vi biến môi trường có thể khác ở bản khác, vì LiteLLM đổi transport khá thường xuyên.

Ai nên đọc

Người vận hành LiteLLM trong mạng doanh nghiệp có proxy bắt buộc. Người viết ứng dụng gọi LiteLLM SDK trực tiếp và thấy request không đi theo proxy như mong đợi. Người phụ trách bảo mật cần biết key của provider và key của gateway có thể xuất hiện ở đâu.

Phân biệt LiteLLM gateway và outbound transport đến model với LiteLLM outbound proxy

Trước khi đo, cần vẽ đúng đường đi.

Hai cách dùng LiteLLM

Cách thứ nhất là SDK: ứng dụng import litellm và gọi completion. Khi đó chính tiến trình ứng dụng mở kết nối tới provider. Cách thứ hai là gateway: ứng dụng gọi một máy chủ LiteLLM qua HTTP, máy chủ đó mới gọi provider.

Với SDK, chỉ có một đoạn đường. Với gateway, có hai đoạn: ứng dụng tới gateway, gateway tới provider. Mỗi đoạn có cấu hình proxy riêng, đặt ở tiến trình riêng.

Hai key khác nhau

Gateway dùng master key hoặc virtual key để xác thực ứng dụng. Provider dùng API key của nhà cung cấp. Ứng dụng chỉ nên biết key gateway. Gateway giữ key provider, đọc từ biến môi trường hoặc kho bí mật.

Một đường egress đúng là đường mà key gateway không bao giờ ra khỏi mạng nội bộ, còn key provider chỉ tới provider.

Transport là gì

Transport là thư viện HTTP mà LiteLLM dùng để gửi request. Bản 1.106.6 gọi provider kiểu OpenAI qua SDK openai. Lời gọi đồng bộ đi qua httpx. Lời gọi bất đồng bộ mặc định đi qua một transport dựa trên aiohttp. Hai thư viện đọc biến proxy theo cách riêng, nên cần thử cả hai.

Vì sao phải tách hai đoạn

Khi gặp sự cố, câu hỏi đầu tiên là request hỏng ở đoạn nào. Nếu ứng dụng nhận lỗi 400 từ gateway, vấn đề nằm ở đoạn thứ nhất hoặc ở chính gateway. Nếu gateway nhận Connection error, vấn đề nằm ở đoạn thứ hai. Gộp hai đoạn làm một, người vận hành sẽ đi sửa biến proxy ở client trong khi lỗi nằm ở tiến trình gateway.

Tách hai đoạn cũng giúp phân quyền. Đội ứng dụng lo đoạn thứ nhất. Đội hạ tầng lo đoạn thứ hai, nơi có proxy công ty và key provider.

Tài liệu nói gì

Trang config_settings của LiteLLM liệt kê các biến môi trường của gateway. Trong đó có nhóm biến về transport aiohttp, ví dụ tắt hẳn transport này hoặc tắt việc nó tin biến môi trường. Bài chỉ dùng các biến có trong trang đó và kiểm từng biến bằng lab.

Sơ đồ lab

Sơ đồ lab

Lab có bốn thành phần trên cùng một máy. Provider giả nghe HTTP ở cổng 9471 và HTTPS tự ký ở cổng 9473, ghi lại header Authorization và Via. Proxy ghi log nghe ở cổng 9472, hiểu cả CONNECT lẫn request HTTP thường. Gateway LiteLLM nghe ở cổng 9474. Client là SDK openai hoặc litellm.

Mỗi hop ghi một dòng JSON vào cùng tệp log. Key được che, chỉ giữ vài ký tự đầu và bốn ký tự cuối để nhận ra key nào.

Phân biệt listener gateway với tuyến đi tới provider trong LiteLLM outbound proxy

Phần này chạy gateway và đọc log hai đoạn đường.

Cấu hình gateway

Gateway đọc tệp cấu hình có một model tên fake trỏ tới provider HTTPS, key provider lấy từ biến môi trường PROV_KEY. Master key đặt trong general_settings.

model_list:
  - model_name: fake
    litellm_params:
      model: openai/fake
      api_base: https://127.0.0.1:9473/v1
      api_key: os.environ/PROV_KEY
litellm_settings:
  ssl_verify: false
general_settings:
  master_key: sk-master-lab-0000

Tiến trình gateway được chạy với HTTPS_PROXY trỏ tới proxy ghi log. ssl_verify false chỉ vì provider dùng chứng chỉ tự ký trong lab. Đừng chép dòng đó vào môi trường thật.

Lỗi khởi động trên Windows

Lần chạy đầu, gateway dừng với UnicodeEncodeError rồi báo Application startup failed. Nguyên nhân là console Windows dùng bảng mã cũ, không in được ký tự trong banner khởi động. Đặt PYTHONIOENCODING bằng utf-8 cho tiến trình gateway là chạy được. Lỗi này không liên quan proxy nhưng dễ làm người dùng nghĩ cấu hình mạng sai.

Ca G1: client gọi gateway

Client không đặt biến proxy, gọi gateway bằng master key. Log có hai dòng. Proxy thấy CONNECT 127.0.0.1:9473 và không thấy header Authorization nào. Provider thấy Bearer với key provider.

Master key không xuất hiện ở proxy lẫn provider. Gateway đã đổi key đúng như thiết kế.

Gateway thêm gì vào request

Provider ở ca G1 không thấy header Via hay X-Forwarded-For. Gateway không báo cho provider biết request gốc đến từ đâu. Đây là điều tốt về riêng tư, nhưng cũng có nghĩa provider chỉ thấy một nguồn duy nhất là gateway. Muốn biết ứng dụng nào tiêu tốn bao nhiêu, phải đọc log và thống kê của gateway, không trông vào phía provider.

Listener không quan tâm biến proxy

Biến HTTPS_PROXY của gateway không ảnh hưởng tới cổng 9474 mà gateway nghe. Biến đó chỉ dùng khi gateway là bên gọi đi. Ai muốn đặt proxy trước gateway để chặn truy cập vào gateway thì cần một reverse proxy, là chuyện khác hẳn.

Vì sao provider thấy User-Agent AsyncOpenAI

Ở ca G1, provider ghi User-Agent là AsyncOpenAI/Python 2.54.0, dù client gọi gateway bằng SDK đồng bộ. Lý do là gateway chạy bất đồng bộ bên trong, nên lời gọi ra provider luôn là lời gọi async. Hệ quả: với gateway, cấu hình proxy cho transport aiohttp quan trọng hơn cấu hình cho httpx. Biến DISABLE_AIOHTTP_TRUST_ENV đặt nhầm ở tiến trình gateway sẽ làm mọi request ra provider bỏ qua proxy.

Ca G2: sai master key

Client gửi key sai. Gateway trả 400 với thông báo No connected db, không phải 401. Lý do là lab không nối cơ sở dữ liệu, nên gateway không tra được virtual key. Provider không nhận request nào.

Kết quả này đáng ghi lại vì người vận hành có thể tưởng lỗi kết nối. Thật ra request đã bị chặn ở gateway, không ra tới proxy.

Log của gateway

Lab tìm cả hai key trong toàn bộ đầu ra của gateway. Không thấy key provider, không thấy master key. Ở mức log mặc định, gateway chỉ ghi dòng truy cập như POST /chat/completions cùng mã trạng thái.

Kiểm HTTP_PROXY, HTTPS_PROXY, NO_PROXY theo transport và bản cài trong LiteLLM outbound proxy

Phần này dùng SDK litellm trực tiếp, mỗi ca chạy một tiến trình mới để biến môi trường được đọc lại từ đầu.

Cách chạy từng ca

Tệp one.py gọi litellm.completion hoặc acompletion với api_base, key provider giả, timeout và num_retries bằng 0. Mỗi ca ghi một dòng đánh dấu vào log trước khi gọi. Như vậy đọc log biết dòng nào thuộc ca nào.

kw = dict(model="openai/fake", api_base=base, api_key=KEY,
          messages=[{"role": "user", "content": "ping"}],
          timeout=20, num_retries=0)
r = litellm.completion(**kw) if mode == "sync" else asyncio.run(litellm.acompletion(**kw))

Không đặt proxy

Ca 1 và 1b gọi thẳng provider HTTPS, đồng bộ và bất đồng bộ. Provider nhận request, proxy không thấy gì. User-Agent là OpenAI/Python 2.54.0 cho lời gọi đồng bộ và AsyncOpenAI/Python 2.54.0 cho lời gọi bất đồng bộ.

Đặt HTTPS_PROXY

Ca 2 và 2b đặt HTTPS_PROXY. Cả hai đều đi qua proxy bằng CONNECT 127.0.0.1:9473. Proxy chỉ thấy tên máy và cổng, không thấy đường dẫn, không thấy key. Provider vẫn nhận Bearer key provider bên trong đường hầm TLS.

Vậy với bản 1.106.6, cả transport httpx lẫn aiohttp đều tin biến HTTPS_PROXY khi provider dùng HTTPS.

Biến môi trường được đọc lúc nào

Lab chạy mỗi ca trong một tiến trình mới vì thư viện HTTP thường đọc biến proxy khi tạo client. LiteLLM giữ client trong bộ nhớ đệm để dùng lại. Đổi os.environ giữa chừng trong một tiến trình đang chạy có thể không có tác dụng với client đã tạo. Khi đổi cấu hình proxy cho gateway, hãy khởi động lại tiến trình thay vì chờ nó tự nhận.

Một kết nối bất ngờ

Ở mọi ca có HTTPS_PROXY, proxy ghi thêm một CONNECT tới raw.githubusercontent.com cổng 443, xảy ra ngay lúc import litellm. Đó là lúc LiteLLM tải bảng giá model từ GitHub. Ca 11 đặt LITELLM_LOCAL_MODEL_COST_MAP bằng True, kết nối này biến mất, chỉ còn CONNECT tới provider.

Trong mạng bị kiểm soát chặt, kết nối này có thể bị chặn và làm import chậm. Nó cũng là một đường egress mà người vận hành thường không ghi vào danh sách cho phép.

HTTP_PROXY với provider HTTP

Ca 3 và 3b dùng provider HTTP thường ở cổng 9471 và đặt HTTP_PROXY. Proxy nhận POST với URL đầy đủ, và thấy nguyên header Authorization chứa key provider. Provider thấy thêm header Via do proxy chèn.

Đây là ca lộ key rõ nhất. Khi provider không dùng TLS, proxy đọc được mọi thứ, kể cả key. Proxy của bên thứ ba trong trường hợp này có thể ghi lại key của bạn.

NO_PROXY

Ca 4 và 4b đặt HTTPS_PROXY cùng NO_PROXY bằng 127.0.0.1. Request tới provider đi thẳng, cả đồng bộ lẫn bất đồng bộ. Nhưng CONNECT tới GitHub lúc import vẫn đi qua proxy, vì GitHub không nằm trong NO_PROXY.

Chữ thường và chữ hoa

Ca 5 đặt biến https_proxy viết thường cho lời gọi bất đồng bộ. Kết quả giống ca chữ hoa: request đi qua proxy. Trên Windows biến môi trường không phân biệt hoa thường, nên ca này chỉ xác nhận không có gì lạ. Trên Linux nên thử lại vì hai cách viết là hai biến khác nhau.

Đặt endpoint provider fixture và log egress ở từng hop cho LiteLLM outbound proxy

Phần này thử hai biến riêng của transport aiohttp và cách ghi log hop.

Tắt việc aiohttp tin biến môi trường

Ca 6 đặt HTTPS_PROXY và DISABLE_AIOHTTP_TRUST_ENV bằng True, gọi bất đồng bộ. Request tới provider không đi qua proxy nữa. Proxy chỉ còn thấy CONNECT tới GitHub, vốn đi qua httpx lúc import.

Biến này hữu ích khi bạn muốn tiến trình dùng proxy cho việc khác nhưng gọi provider nội bộ thì đi thẳng. Nó cũng là cái bẫy: ai đó đặt biến này trong tệp môi trường chung rồi quên, lời gọi bất đồng bộ âm thầm bỏ qua proxy trong khi lời gọi đồng bộ vẫn đi qua.

Khi nào nên đặt DISABLE_AIOHTTP_TRUST_ENV

Trường hợp hợp lý là provider nằm trong mạng nội bộ, còn tiến trình cần HTTPS_PROXY cho việc khác như tải bảng giá hay gọi webhook ra ngoài. Ngay cả khi đó, NO_PROXY chứa địa chỉ provider là cách rõ ràng hơn, vì nó áp dụng cho cả httpx lẫn aiohttp. Đặt biến tắt trust env chỉ ảnh hưởng một transport, dễ tạo ra hai hành vi khác nhau trong cùng tiến trình.

Tắt hẳn transport aiohttp

Ca 7 đặt DISABLE_AIOHTTP_TRANSPORT bằng True. Lời gọi bất đồng bộ chuyển sang httpx và đi qua proxy như ca 2. Thời gian tăng nhẹ, 1,14 giây so với khoảng 0,87 giây, nhưng một lần đo không đủ để kết luận về hiệu năng.

Bảng các ca SDK

Bảng các ca SDK

Bảng: Bảng các ca SDK
Ca	Biến đặt	Kiểu gọi	Qua proxy	Proxy thấy key
1, 1b	không	sync, async	không	không
2, 2b	HTTPS_PROXY	sync, async	có, CONNECT	không
3, 3b	HTTP_PROXY, provider HTTP	sync, async	có, POST	có
4, 4b	HTTPS_PROXY, NO_PROXY	sync, async	không	không
6	thêm DISABLE_AIOHTTP_TRUST_ENV	async	không	không
7	thêm DISABLE_AIOHTTP_TRANSPORT	async	có, CONNECT	không
11	thêm LITELLM_LOCAL_MODEL_COST_MAP	sync	có, không còn GitHub	không

Ghi log ở từng hop

Proxy trong lab ghi phương thức, đích, có header Authorization hay không, có Proxy-Authorization hay không. Provider ghi đường dẫn, Authorization đã che, Via và User-Agent. Ghép hai log theo thời gian là thấy request đi đường nào.

Trong môi trường thật, proxy công ty thường đã có log. Việc cần làm là hỏi đội mạng xem log đó ghi gì. Proxy chặn TLS để soi nội dung sẽ thấy cả key provider, dù provider dùng HTTPS.

Đo thời gian từng hop

Log có giờ phút giây ở từng hop, nhưng độ phân giải giây không đủ để đo độ trễ do proxy thêm vào. Muốn đo, hãy ghi thời gian chính xác tới mili giây ở client và ở provider giả, rồi lấy hiệu. Trong lab, toàn bộ lời gọi qua proxy mất khoảng 0,87 giây, gần bằng gọi thẳng, vì mọi thứ nằm trên cùng một máy.

Provider giả có ích gì

Provider giả cho phép đo mà không tốn tiền, không cần key thật, và quan trọng là thấy được header mà provider thật nhận. Nhà cung cấp thật không cho bạn xem log phía họ. Muốn biết key có tới đúng nơi hay không, cách rẻ nhất là thay provider bằng máy chủ do bạn kiểm soát.

Đọc log proxy công ty

Nếu không tự dựng được proxy ghi log, hãy nhờ đội mạng lọc log theo địa chỉ IP của máy chạy gateway trong một khoảng thời gian ngắn. Gọi gateway đúng một lần trong khoảng đó. Log cần cho thấy một CONNECT tới tên máy provider. Không thấy dòng nào nghĩa là request đi thẳng, không qua proxy. Thấy POST với URL đầy đủ nghĩa là provider đang dùng HTTP.

Đổi api_base để đo

LiteLLM cho đặt api_base cho từng model. Trong lab, đổi api_base sang provider giả là đủ. Không cần sửa mã ứng dụng. Sau khi đo xong, đổi lại api_base về provider thật và giữ nguyên các biến proxy đã kiểm.

So ca bật/tắt tuyến proxy, timeout và credential redaction trong LiteLLM outbound proxy

Phần này thử lúc mọi thứ hỏng và soát chỗ key có thể lọt.

Proxy chết

Ca 8 và 8b trỏ HTTPS_PROXY tới cổng 9479 không có gì nghe. Cả hai báo litellm.InternalServerError với nội dung OpenAIException Connection error, sau khoảng 3,3 giây tính cả thời gian import. Thông báo không nhắc tới proxy.

Người đọc lỗi dễ nghĩ provider sập. Khi thấy Connection error, hãy kiểm proxy trước: biến môi trường, cổng, xác thực proxy.

Provider chậm

Ca 9 đặt timeout bằng 3 giây, provider giả ngủ 6 giây trước khi trả lời. LiteLLM báo litellm.Timeout sau 4,12 giây. Phần dư khoảng một giây là thời gian import và khởi tạo. Không có proxy trong ca này, nhưng timeout áp dụng giống nhau khi có proxy.

Retry che giấu lỗi proxy

Lab đặt num_retries bằng 0 để thấy lỗi ngay. Trong môi trường thật, retry mặc định của SDK có thể gọi lại vài lần trước khi báo lỗi. Proxy chết khi đó biểu hiện như request rất chậm rồi mới lỗi. Khi chẩn đoán, tạm tắt retry để thấy lỗi gốc.

Client có HTTP_PROXY gọi gateway

Client gọi qua proxy

Client gọi qua proxy

Ca G3 là ca quan trọng nhất của phần gateway. Client đặt HTTP_PROXY, không đặt NO_PROXY, gọi gateway ở http://127.0.0.1:9474. Request của client đi qua proxy dưới dạng POST thường, và proxy thấy header Authorization chứa master key.

Nghĩa là key gateway rời khỏi tiến trình client, đi qua proxy, rồi mới tới gateway. Nếu proxy là của bên ngoài, key gateway đã lộ. Cách sửa là ca G4: thêm NO_PROXY cho địa chỉ gateway. Request đi thẳng, proxy không thấy master key.

Proxy cần xác thực mà thiếu thông tin

Lab không có proxy đòi xác thực. Với proxy như vậy, thiếu user và mật khẩu thường dẫn tới mã 407 từ proxy. Qua nhiều lớp thư viện, mã này có thể chỉ còn là một lỗi kết nối chung. Khi gặp Connection error mà proxy vẫn sống, thử gọi provider bằng curl với cùng biến proxy để xem mã trả về thật.

Debug log

Ca 12 bật _turn_on_debug của LiteLLM, ghi 56 dòng debug. Lab tìm chuỗi key provider đầy đủ và cả tiền tố của nó: không thấy. Ở bản 1.106.6, debug log không in key. Bản khác có thể khác, nên vẫn nên tìm key trong log trước khi gửi log cho người ngoài.

Chuỗi proxy cũng là bí mật

Nếu proxy công ty cần xác thực, HTTPS_PROXY có dạng chứa user và mật khẩu. Chuỗi này nằm trong biến môi trường của tiến trình gateway. Đừng ghi nó vào tệp cấu hình đẩy lên kho mã. Cách viết chuỗi proxy có xác thực đúng định dạng được giải thích trong bài định dạng proxy.

Key không đi qua proxy dạng CONNECT

Với provider HTTPS và proxy không chặn TLS, proxy chỉ thấy tên máy và cổng. Lab xác nhận ở mọi ca CONNECT: trường Authorization phía proxy luôn rỗng. Đây là lý do nên luôn dùng HTTPS tới provider, kể cả provider nội bộ.

Đầu ra nghiệm thu: topology client gateway model và bảng kiểm đường egress không lộ API key của LiteLLM outbound proxy

Phần cuối gom kết quả thành sơ đồ và bảng kiểm dùng khi triển khai.

Topology

Client gọi gateway trong mạng nội bộ, không qua proxy, mang key gateway. Gateway gọi provider qua proxy công ty bằng CONNECT, mang key provider bên trong TLS. Proxy chỉ thấy tên máy provider. Provider chỉ thấy key provider.

Bảng kiểm egress

Bảng: Bảng kiểm egress
Đoạn đường	Cấu hình đúng	Kiểm bằng
Client tới gateway	NO_PROXY chứa địa chỉ gateway	log proxy không có POST tới gateway
Gateway tới provider	HTTPS_PROXY ở tiến trình gateway, provider HTTPS	log proxy chỉ có CONNECT
Import LiteLLM	LITELLM_LOCAL_MODEL_COST_MAP hoặc cho phép GitHub	log proxy không có raw.githubusercontent.com
Lời gọi async	không đặt DISABLE_AIOHTTP_TRUST_ENV nếu cần proxy	log proxy có CONNECT cho async
Log gateway	mức mặc định	không tìm thấy key trong log

Quy trình kiểm trước khi đưa vào chạy

Bước một, đổi api_base sang provider giả, giữ nguyên biến proxy dự định dùng. Bước hai, gọi một lần đồng bộ và một lần bất đồng bộ. Bước ba, đọc log proxy và log provider giả, đối chiếu bảng kiểm. Bước bốn, đổi api_base về provider thật.

Khi nào cần proxy với LiteLLM outbound proxy

Proxy ở đoạn gateway tới provider thường là yêu cầu của mạng công ty, không phải lựa chọn. Có trường hợp nhóm cần IP cố định để provider hoặc API nội bộ của đối tác đặt danh sách cho phép. Khi đó anh em có thể mua proxy tĩnh Việt Nam tại trang chủ ProxyVN để có IP cố định cho tuyến egress. Proxy không thay key, không tăng hạn mức của provider, và không được dùng để né điều khoản của nhà cung cấp.

Ngoài gọi model, proxy IP còn dùng nhiều trong thu thập dữ liệu web hợp lệ. Vai trò đó được phân tích ở bài Web Scraping proxy là gì.

Gateway trong container

Khi gateway chạy trong container, biến proxy phải được truyền vào container, không phải đặt ở máy chủ. Địa chỉ provider nội bộ và địa chỉ các dịch vụ trong cùng mạng container nên nằm trong NO_PROXY. Nếu không, request giữa các container cũng bị đẩy ra proxy công ty, vừa chậm vừa có thể lộ key.

Ghi lại cấu hình egress

Bảng kiểm egress nên được lưu cùng tệp cấu hình gateway. Mỗi lần nâng phiên bản LiteLLM, chạy lại các ca chính với provider giả. Bản 1.106.6 dùng aiohttp cho async, bản sau có thể đổi. Chỉ có phép đo mới cho biết hành vi còn đúng hay không.

Proxy cho HTTP provider nội bộ

Nếu provider nội bộ chỉ có HTTP, đừng cho request đi qua proxy dùng chung. Đặt địa chỉ provider vào NO_PROXY, hoặc bật TLS cho provider. Ca 3 cho thấy proxy đọc được key khi không có TLS.

Ai được đọc tệp môi trường

Key provider, master key và chuỗi proxy có xác thực thường cùng nằm trong một tệp môi trường của gateway. Người đọc được tệp đó có toàn quyền. Nên giới hạn quyền đọc tệp, dùng kho bí mật nếu có, và tách key provider của môi trường thử nghiệm khỏi môi trường thật.

Những gì lab chưa thử

Lab chưa thử proxy chặn TLS kiểu doanh nghiệp, chưa thử proxy có xác thực, chưa thử provider khác OpenAI như Anthropic hay Bedrock vốn có đường gọi riêng. Lab cũng chưa thử gateway có cơ sở dữ liệu và virtual key, nên chưa thấy mã 401 đúng nghĩa. Gateway chạy trong Docker có thể đọc biến môi trường khác với tiến trình chạy tay.

Checklist LiteLLM outbound proxy

Checklist

Checklist

Gọi đúng tên: gateway là reverse proxy, outbound proxy là forward proxy.
HTTPS_PROXY đặt ở tiến trình gateway, không đặt ở client.
Client có biến proxy thì thêm NO_PROXY cho địa chỉ gateway.
Provider luôn dùng HTTPS, kể cả provider nội bộ.
Kiểm cả lời gọi đồng bộ và bất đồng bộ.
Biết đường egress tới GitHub lúc import, cho phép hoặc tắt.
Không đặt DISABLE_AIOHTTP_TRUST_ENV trong tệp môi trường chung.
Tìm key trong log trước khi chia sẻ log.

Câu hỏi thường gặp về LiteLLM outbound proxy

LiteLLM Proxy có phải outbound proxy không?

Không. LiteLLM Proxy là gateway nhận request từ ứng dụng. Outbound proxy là proxy nằm giữa LiteLLM và provider.

LiteLLM có tôn trọng HTTPS_PROXY không?

Trên bản 1.106.6, có, cho cả lời gọi đồng bộ qua httpx và bất đồng bộ qua aiohttp, trừ khi đặt DISABLE_AIOHTTP_TRUST_ENV.

Proxy có thấy API key không?

Với provider HTTPS, proxy chỉ thấy tên máy qua CONNECT. Với provider HTTP, lab cho thấy proxy đọc được nguyên key.

Vì sao có kết nối tới GitHub?

LiteLLM tải bảng giá model lúc import. Đặt LITELLM_LOCAL_MODEL_COST_MAP bằng True để dùng bảng có sẵn trong gói.

Proxy chết thì LiteLLM báo lỗi gì?

Lab nhận InternalServerError với nội dung Connection error, không nhắc tới proxy.

Client gọi gateway có cần proxy không?

Thường là không. Lab cho thấy nếu client đi qua proxy, proxy thấy master key của gateway.

LiteLLM outbound proxy và những điều cần nhớ

LiteLLM outbound proxy là đoạn đường từ LiteLLM tới provider, tách khỏi gateway nhận request từ ứng dụng. Lab trên bản 1.106.6 cho thấy HTTPS_PROXY có hiệu lực với cả httpx lẫn aiohttp. Provider HTTP làm lộ key cho proxy, client đi qua proxy làm lộ master key, và lúc import có một kết nối tới GitHub ít ai để ý. Đo bằng provider giả trước khi nối provider thật là cách nhanh nhất để biết key đi đâu. Cần IP tĩnh cho tuyến egress của LiteLLM outbound proxy, liên hệ Proxy.vn - Nhà cung cấp dịch vụ proxy chất lượng hàng đầu Việt Nam.