proxify
poixeai/proxify加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
微信扫码咨询客服
POMOAI — 让开源 AI 即刻运行
加载项目详情…
本应用为开源项目，仅供学习研究，请遵守其开源协议。
想象这样一个场景：你正在开发一个 AI 应用，需要同时调用 OpenAI 的 GPT-4 来写文案、Anthropic 的 Claude 来做代码审查、Google 的 Gemini 来做多模态理解。每换一个大模型，代码里就要改一次 baseURL，配一次 API Key，还要处理不同平台各自迥异的请求格式。更头疼的是，你们公司的服务器在国内，直接访问这些海外 API 时不时就被墙，或者延迟高得离谱。
有没有一种方式，能让你只改一行配置，就把整个应用切换到不同的 AI 提供商？甚至更进一步——把国内便宜的 DeepSeek、硅基流动等服务，用同样的接口暴露给所有业务线？
Proxify 正是为解决这些问题而生。
2023-2024 年间，随着 GPT-4、Claude 3、Gemini 等大模型相继开放 API，AI 应用开发迎来了爆发期。然而，繁荣的背后是接口碎片化的噩梦：OpenAI 用 https://api.openai.com/v1/chat/completions，Anthropic 用 https://api.anthropic.com/v1/messages，Google 用 https://generativelanguage.googleapis.com/v1beta/models/...。请求格式不同、认证方式不同、流式响应处理方式也不同。
与此同时，中国开发者还面临另一重困境：直接访问海外 API 存在网络限制，而国内各大云厂商的 API 端点又互不兼容。一套代码想在国内厂商之间切换，几乎需要重写。
Proxify 由 AI 工程团队 Poixe AI 开发，核心思路很直接——在业务代码和各个 AI 提供商之间，加一层统一入口的反向代理。开发者只需要把 baseURL 指向自己部署的 Proxify 服务，剩下的路由、协议转换、流式优化全部由网关处理。
Proxify 的路由规则定义在 routes.json 中，支持任意多个上游目标。以 /openai 开头的请求，自动转发到 api.openai.com；以 /deepseek 开头的请求，转发到 api.deepseek.com；以 /claude 开头的请求，转发到 api.anthropic.com。
关键设计在于路由热加载：修改 routes.json 后，网关会自动感知变化并生效，无需重启服务。这对于需要频繁切换上游的场景（比如 A/B 测试不同模型商）非常友好。
每个路由还支持 model_map 配置，即请求级别的模型名重写。比如可以把用户请求的 gpt-4o 自动映射为 gpt-4o-mini，实现成本更低的降级方案，而业务代码完全无需感知。
LLM 输出是 token by token 逐字生成的，但直接代理到上游时，客户端可能遇到"一股脑收到一堆文字"或者"连接超时中断"的问题。Proxify 在流式响应上做了三层优化：
这三项优化通过环境变量 STREAM_SMOOTHING_ENABLED 和 STREAM_HEARTBEAT_ENABLED 独立控制，可按需开启。
Proxify 支持两层可选的访问控制：
AUTH_IP_WHITELIST 支持单个 IP、CIDR 网段以及多个逗号分隔的规则，防止未授权的外部访问。AUTH_TOKEN_HEADER 和 AUTH_TOKEN_KEY 配置，客户端请求中携带指定 Header 才允许通过。注意网关要求 Token 长度不少于 16 位，否则拒绝启动。项目预置了 10+ 个常用 AI 服务商的路由配置，涵盖 OpenAI、Azure OpenAI、DeepSeek、Claude、Gemini、Grok、火山引擎（豆包）、阿里云百炼、硅基流动、月之暗面（Moonshot）、Cerebras 等。开发者基本上不需要从零配置，复制 routes.json.example 后即可直接使用。
从代码结构看，Proxify 采用了典型的 Go 微服务架构，按职责分层清晰：
main.go 负责初始化配置加载、日志系统、路由监控和 Gin 引擎注册；static.go 将前端 React 构建产物以内嵌文件系统（//go:embed）的方式打包进二进制，确保前后端版本一致。proxy.go 实现核心代理逻辑——构建目标 URL、构造新请求、复制 Header、通过 http.Client 转发到上游、处理响应流；routes.go 提供路由列表查询接口；home.go 处理首页请求。model_rewrite.go）、请求提取器、异常恢复等拦截器。config/ 负责解析 .env 和 routes.json；logger/ 集成 zap 日志；watcher/ 监听配置文件变化并触发热加载；stream/ 处理 SSE 流式响应的平滑转发；response/ 定义统一错误码。代理流程的核心实现在 controller/proxy.go 中的 ProxyHandler：首先从 Gin Context 中提取目标端点（TargetEndpoint）和子路径（SubPath），拼接出完整的 targetURL；然后向上游发起新请求，原样复制原始请求的所有 Header；根据响应 Content-Type 和 Transfer-Encoding 判断是否为流式响应——若是，则根据配置决定走 stream.Smoothing()（平滑输出）还是直接 streamCopy()；若否，则 io.Copy 直接转发整个响应体。
流式判断逻辑（isStreamResponse）覆盖了以下 Content-Type：text/event-stream、application/octet-stream、application/x-ndjson、application/stream+json，以及 Transfer-Encoding 包含 chunked 且非 application/json 的情况，覆盖了主流 LLM 流式 API 的响应模式。
Proxify 附带一套基于 React 19 的管理面板（web/），技术栈包括：
面板功能覆盖路由列表查看、基础 URL 配置等，嵌入 Go 二进制后通过 Gin 的静态文件服务对外提供（/assets 路径）。
Proxify 的部署难度极低。官方推荐 Docker 部署方式，整个流程只需三步：
routes.json 和 .env（从示例文件复制，修改关键配置如端口和 Token）docker run 或 docker-compose up -dbaseURL 改为 http://<proxify-ip>:7777/<route>硬件需求方面，网关本身不需要 GPU，内存仅需 512MB，磁盘 200MB 即够用——轻量级 0.5GB RAM 的 VPS 也能流畅运行。Go 的高并发特性和 Gin 的轻量框架设计，使得 Proxify 可以在极低资源下处理大量并发代理请求。
项目还提供了构建脚本 build.sh，支持将前后端合并构建为单一 Docker 镜像，内含完整的前端静态资源和 Go 二进制，部署后端点即完整可用。
Proxify 并非万能网关，以下几点值得注意：
1. Token 鉴权长度要求：网关强制要求 Token 长度 ≥ 16 位，短于此长度会拒绝启动。虽然提升了安全性，但如果部署环境本身已有防火墙保护，这一要求可能带来运维摩擦。
2. 路由热加载基于文件监听：配置文件变更通过 fsnotify 监听文件修改生效。如果容器内路径挂载有延迟，或者文件系统为网络挂载（NAS 等），可能存在热加载失效的风险，建议配合 restart: unless-stopped 使用。
3. 预置路由不含认证信息：routes.json.example 中的路由只配置了目标 URL 和路径，没有内置 API Key 或认证 Header。如果上游 API 需要特殊认证头，需要自行在 routes.json 扩展配置（目前暂不支持按路由设置 Header 覆盖，这是一处可改进的空间）。
4. 无内置限流/配额管理：Proxify 目前没有请求频率限制、配额管理或用量统计功能。在多人共用实例的场景下，建议配合 Nginx 或 API 网关层实现流量控制。
在 Proxify 出现之前，AI 网关赛道的主要玩家是 Kong、APISIX、Nginx 等通用反向代理，以及 Cloudflare Workers AI、Portkey AI 等商业 SaaS 产品。前者配置复杂、LLM 流式优化不足，后者有供应商锁定风险且不适合对数据隐私有高要求的场景。
Proxify 的定位介于两者之间——足够简单，足够专注。Go 语言带来的高性能和低资源占用，加上开箱即用的 LLM 流式优化和预置路由，使其成为个人开发者、中小团队自建 AI 基础设施的性价比之选。随着开源社区持续贡献新路由（目前已有 10+ 主流服务商），Proxify 有望成为一个不断壮大的 AI 接口路由生态。
图1：Proxify 官方部署示例界面
图2：Proxify 官网首页背景