版本：1.6.0

透传路由

透传路由（passthrough route）将匹配到的请求转发到一个上游目标，不转换请求正文。它适用于 AISIX 尚未建模为一等路由的服务提供方原生端点，也适用于携带原始 Host 请求头的正向代理流量。

每条路由定义流量如何匹配、发送到何处、AISIX 如何认证调用方，以及 AISIX 是注入服务提供方凭证还是转发调用方凭证。AISIX 仍可围绕中继流量实施调用方访问控制、请求限制、护栏和遥测。

必须显式配置路由

每个透传路径或主机都必须由显式路由认领。未被任何路由认领的 /passthrough/* 路径遵循普通的空正文 404 处理流程。请先创建并验证路由，再迁移客户端流量。

透传路由不会改写模型标识符。如果服务提供方原生请求在正文、路径、查询参数或请求头中指定模型，请发送该服务提供方预期的标识符。

准备工作

请准备以下内容：

一个 AISIX 部署：
- 对于 AISIX Cloud，需要一个已挂载网关的环境和具备写入权限的管理员 Token。
- 对于开源 AISIX 网关，需要一个已配置为加载声明式资源文件的网关。
inject 路由所需的上游服务提供方凭证。示例使用 OpenAI；forward_client 路由则会中继调用方的上游凭证。
curl 和 jq。

了解透传流程

AISIX 保留请求正文，同时处理网关身份认证、目标构造、有意的请求头过滤、护栏和遥测：

每个匹配请求只会尝试一次上游调用。遇到传输故障或上游 5xx 响应时，AISIX 不会重试透传请求。路由不会解析模型，因此路由失败也不会让任何已配置模型进入冷却状态。

URL 重写先于路由匹配执行。下面两个阶段均使用重写后的路径；重写规则的可选 hosts 条件可以让其他主机的路径保持不变。之后，路由匹配分两个阶段进行：

入站 Host 命中某条路由 hosts 白名单的请求，会在网关的类型化路由之前分发。这样，正向代理便可中继 /v1/messages 之类的上游路径，而不会被网关当作自身端点处理。
路径前缀匹配在类型化路由之后运行，因此纯路径路由无法遮蔽网关的 /v1、/mcp 或 /a2a 端点。

多条路由同时匹配时，主机名匹配优先于纯路径匹配，较长的匹配前缀优先于较短的前缀。

配置服务提供方原生路由

以下示例在 /passthrough/openai/v1/models 暴露 OpenAI 的原生模型列表端点。AISIX 注入已配置的 OpenAI 凭证，并要求调用方 Key 已获得 openai-tunnel 授权。

AISIX Cloud

导出 AISIX Cloud 连接信息和服务提供方凭证：

# AISIX_CP 包含 /api，且不含尾部斜杠
# 本地私有化部署快速入门使用 http://localhost:8080/api
export AISIX_CP="YOUR_AISIX_CLOUD_ADMIN_API_URL"
export AISIX_TOKEN="YOUR_ADMIN_TOKEN"
export ENV_ID="YOUR_ENVIRONMENT_ID"
export OPENAI_API_KEY="YOUR_OPENAI_API_KEY"

创建一个可供该环境使用的 OpenAI 服务提供方 Key：

PROVIDER_KEY_ID=$(curl --fail-with-body -sS -X POST \
  "$AISIX_CP/provider_keys" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "OpenAI passthrough",
    "provider": "openai",
    "api_key": "'"${OPENAI_API_KEY}"'",
    "api_base": "https://api.openai.com/v1",
    "allowed_environments": ["'"${ENV_ID}"'"]
  }' | jq -er '.provider_key.id')

使用服务提供方 Key ID 创建路由：

ROUTE_RESPONSE=$(curl --fail-with-body -sS -X POST \
  "$AISIX_CP/environments/$ENV_ID/passthrough_routes" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "openai-tunnel",
    "path_prefix": "/passthrough/openai",
    "target_url": "https://api.openai.com/v1",
    "credential_mode": "inject",
    "provider_key_id": "'"${PROVIDER_KEY_ID}"'"
  }')

export ROUTE_ID=$(printf '%s' "$ROUTE_RESPONSE" | jq -er '.passthrough_route.id')
printf '%s' "$ROUTE_RESPONSE" | jq '.warnings // []'

保留 ROUTE_ID，以便更新路由或挂载路由作用域的护栏。

创建专用调用方 Key，并在同一请求中授予该路由。明文 Key 只返回一次：

CALLER_RESPONSE=$(curl --fail-with-body -sS -X POST \
  "$AISIX_CP/environments/$ENV_ID/api_keys" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "OpenAI passthrough caller",
    "allowed_models": [],
    "allowed_routes": ["openai-tunnel"]
  }')

export AISIX_API_KEY=$(printf '%s' "$CALLER_RESPONSE" | jq -er '.plaintext')
printf '%s' "$CALLER_RESPONSE" | jq '.warnings // []'

控制面会将服务提供方 Key、路由和调用方授权下发到已挂载的网关。上线前请检查返回的所有兼容性警告。警告仅供参考，因此请通过每个网关验证流量。在控制台中，可分别通过 Provider keys、环境的 Passthrough Routes 以及调用方 Key 的 Passthrough route access 部分完成相同操作。

如果改为授权现有调用方，请包含其应保留的全部路由授权。更新 allowed_routes 字段时，AISIX Cloud Admin API 会替换完整列表。

开源 AISIX 网关

在完整资源文件中准备一个 openai-prod 服务提供方 Key，然后选择一个专用调用方凭证：

export PASSTHROUGH_CALLER_KEY="YOUR_CALLER_API_KEY"

将路由和调用方条目添加到相应集合中。保持服务提供方 Key 和其他资源不变：

resources.yaml（路由和调用方 Key）
passthrough_routes:
  - name: openai-tunnel
    path_prefix: /passthrough/openai
    target_url: https://api.openai.com/v1
    provider_key: openai-prod

api_keys:
  - display_name: passthrough-caller
    key_env: PASSTHROUGH_CALLER_KEY
    allowed_models: []
    allowed_routes: [openai-tunnel]

AISIX 加载文件时，会将 provider_key 名称解析为服务提供方 Key 的派生 ID。未知名称会导致验证失败。allowed_routes 中的精确条目也会根据文件中定义的路由进行检查；允许使用通配符模式。

加载前，验证组装好的完整文件：

aisix validate --resources resources.yaml

由于本示例引入了 PASSTHROUGH_CALLER_KEY，请在网关进程环境中设置该变量，然后启动或重新创建网关。加载完成后，使用同一个值进行验证请求：

export AISIX_API_KEY="$PASSTHROUGH_CALLER_KEY"

验证路由

导出末尾不带斜杠的网关源地址：

# AISIX_PROXY 不含尾部斜杠或端点路径
# 本地快速入门使用 http://127.0.0.1:3000
export AISIX_PROXY="YOUR_AISIX_GATEWAY_URL"

通过 AISIX 请求 OpenAI 的原生模型列表：

curl --fail-with-body -sS \
  "$AISIX_PROXY/passthrough/openai/v1/models" \
  -H "Authorization: Bearer $AISIX_API_KEY"

该路由会剥离其 path_prefix，避免重复添加 target_url 中已有的 /v1 路径段，注入 OpenAI 服务提供方凭证，并中继上游响应。

比较 Cloud 与资源文件引用

大多数路由字段在两种管理方式中使用相同名称。服务提供方凭证和调用方凭证的引用方式有所不同：

用途	AISIX Cloud Admin API	推荐的资源文件字段	资源文件接受的显式 ID
注入的服务提供方凭证	`provider_key_id`（UUID）	`provider_key`（`display_name`）	`provider_key_id`
匿名调用方主体	`anonymous_key_id`（UUID）	`anonymous_key`（`display_name`）	`anonymous_key_id`

资源文件中的名称引用在加载时会受到更严格的检查，引用未知时还会给出候选名称。应优先使用名称引用，而非显式 ID。AISIX Cloud 会验证服务提供方 Key 对该环境可见，并验证匿名调用方 Key 属于该环境。

在 AISIX Cloud 中，路由 name 创建后便固定不变。在资源文件中，更改名称会改变路由身份，因此必须同时更新每个调用方的 allowed_routes 条目。

配置参考

字段	行为
`name`	路由身份，由调用方的 `allowed_routes` 模式引用，并记录在用量事件中。
`path_prefix`	网关路径前缀，按路径段边界匹配。`target_url` 路由会先剥离前缀，再将剩余路径拼接到目标；`preserve_host` 路由则保留完整路径。纯路径路由不能占用 `/v1`、`/mcp`、`/a2a`、`/admin`、`/livez`、`/readyz` 或 `/metrics`；同时匹配 `hosts` 的路由可以使用这些归上游所有的路径。
`hosts`	入站 `Host` 白名单，不区分大小写并忽略端口。前导 `*.` 通配符匹配一个额外标签，且必须保留至少两个字面标签。
`target_url`	显式上游基础 URL。必须且只能配置一种目标形式：`target_url` 或 `preserve_host: true`。
`preserve_host`	将 `https://<matched-host>` 推导为目标。仅可与 `hosts` 一同配置，由 `hosts` 限定推导出的目的地。
`auth_mode`	`gateway_key`（默认）、`header_key` 或 `anonymous`。
`auth_header_name`	`header_key` 模式下包含网关凭证的小写专用请求头。除非 `forward_client_headers` 完整写出它的名称，否则 AISIX 会在转发前将其剥离；`x-*` 这类通配符触及不到它。`authorization`、`proxy-authorization`、`cookie`、`set-cookie` 和 `x-api-key` 会被拒绝。
`source_cidrs`	客户端来源白名单。`anonymous` 模式要求该列表非空；其他模式可将其作为可选的安全加固措施。
`credential_mode`	`inject`（默认）或 `forward_client`。
`forward_client_headers`	即使该路由本会剥离，也仍要中继给上游的入站客户端请求头，取值为精确名称或含一个 `` 的通配符，匹配不区分大小写。默认为空。PATCH 会整体替换已存储的列表；发送 `null` 可清空。在控制台中，它是 Advanced* 下的 Forward client headers，每行一个条目。参见上游请求头。
`identity_header`	可选的小写设备注入身份请求头。AISIX 将长度受限的值记录为 `client_identity`，并在转发前剥离该请求头（除非 `forward_client_headers` 完整写出它的名称；`x-*` 这类通配符触及不到它）。仅应在可信设备之后配置，并由该设备删除并替换客户端提供的任何值。`authorization`、`proxy-authorization`、`cookie`、`set-cookie` 和 `x-api-key` 会被拒绝。
`timeout_ms`	限制上游响应头和非 SSE 正文的读取时长。对于 SSE，它限制等待第一个原始上游正文块的时间，以及相邻原始正文块之间的等待时间。它不限制健康中继的总生命周期，也不要求在该间隔内组装完整的 SSE 帧。省略时，路由使用 `upstream.stream_timeout_ms`，再回退到 `upstream.timeout_ms`。
`enabled`	停用的路由不匹配任何请求。默认值：`true`。

必须至少配置一个匹配维度：path_prefix 或 hosts。同时配置两者时，请求必须同时满足两项条件。

网关身份认证模式

gateway_key 从 Authorization: Bearer 或 x-api-key 读取标准网关凭证。
header_key 从 auth_header_name 读取网关凭证，从而将 Authorization 留给调用方的上游凭证。这是正向代理中 forward_client 的标准搭配。
anonymous 不接收网关凭证。请求以配置的调用方 Key 主体运行，并且必须来自 source_cidrs 范围内。

解析出的任一主体仍须通过 allowed_routes 获得路由名称授权；* 授予全部路由。有效 Key 缺少匹配授权时会收到 403。

在 AISIX Cloud 中，已适用于解析后调用方的预算会在分发前检查。透传用量目前不携带模型 ID，按零成本记录，也不会增加这些预算的支出。开源 AISIX 网关没有本地预算资源。

上游凭证模式

inject 剥离入站凭证请求头，并注入已配置的服务提供方 Key。对于 Anthropic，AISIX 使用 x-api-key 和 anthropic-version；对于其他服务提供方，则使用 Authorization: Bearer。服务提供方 Key 上配置的请求头剥离规则和 TLS 设置也会生效。
forward_client 在网关凭证通过 header_key 传入或路由为匿名模式时，转发调用方的上游凭证。使用 gateway_key 时，AISIX 会删除 Authorization 和 x-api-key，因为任一请求头都可能携带网关凭证。

路由默认中继调用方的其他请求头，只剥离一小部分：逐跳请求头和传输请求头、host、content-length、x-aisix-* 命名空间、proxy-authorization，以及调用方的 W3C 链路请求头。AISIX 会使用有效的 W3C 上下文建立自身的 OTLP 链路，并向上游发送网关请求 ID。

forward_client_headers 会覆盖该剥离行为，也是把路由本会移除的请求头放回去的唯一方式。因此，在 auth_mode: gateway_key 下点名 authorization，会中继调用方自己的凭证——正是网关刚刚用来认证该调用方的那个请求头——取代注入的那份；这就是让按最终用户授权的内网服务能够继续这样工作的方式。无论模式如何，host、content-length、逐跳请求头和 x-aisix-* 都会被剥离；凭证或链路上下文请求头必须精确点名，通配符不会匹配到它们。路由自己的 auth_header_name 和 identity_header 同理：AISIX 会消费掉这两个请求头，因此通配符触及不到，完整写出名称才会转发它。路由剥离的其他任何名称，通配符都足以放回去，包括服务提供方密钥 strip_headers 里的条目——不过该列表四个默认值中有三个（authorization、cookie、x-api-key）属于凭证槽位，仍需单独点名，只有 set-cookie 是通配符能放回的默认项。

凭证不存在回退机制：inject 路由没有可解析的服务提供方 Key 时会拒绝请求，forward_client 路由则不能携带服务提供方 Key 引用。

信封识别与用量

AISIX 识别请求形态仅用于提取；识别不会改变中继的正文。如果出现多个可识别的载体字段，则按以下顺序识别：

messages，用于 OpenAI 兼容聊天或 Anthropic Messages 流量。
字符串或数组形式的 input，用于 OpenAI Responses 形态。
prompt，用于旧式 completions 或 fill-in-the-middle 流量。
其余所有正文均按不透明内容处理，包括 JSON-RPC、REST、非 JSON 和空正文。

识别结果还会决定特定协议的 Token 字段和安全护栏内容规则。有关异常、不透明和补充内容的安全边界，请参阅安全护栏扫描范围。

各请求形态记录的用量

有两种原始请求形态仍会读取用量：rerank 正文和阿里云 DashScope 原生正文。用量识别不会转换任何一种正文：AISIX 只读取其 model 字段以及缓冲 JSON 响应中的 Token 数量。安全护栏会检查这些 JSON 正文中已解码的字符串值：

请求正文	缓冲响应	SSE 响应
按上述规则识别出的聊天、Responses 或 completions	响应 `usage` 对象中所有受支持的 Token 字段。	流自身事件上报的用量。
Rerank：顶层 `query` 加 `documents` 数组。适用于 Cohere、Jina 和阿里云百炼的兼容 rerank API。	输入 Token 取自 `usage.prompt_tokens`、`usage.input_tokens` 或 `usage.total_tokens`，或 Cohere 的 `meta.billed_units.input_tokens`，读取方式与 rerank 端点相同。	按不透明流规则。
DashScope 原生：顶层 `model` 字符串加 `input` 对象。适用于原生 rerank、文本与多模态向量，以及原生生成。	见 DashScope 原生 Token 计数。	按不透明流规则。
其他任何正文	不记录。不透明的缓冲响应不会进行推测性 Token 提取。	按不透明流规则。

按不透明流规则，流可通过任一帧中的顶层 usage 对象（按标准字段名读取），或服务端标记为 event: usage / event: token_usage 的帧中的扁平 Token 报告来上报用量。

无论正文形态如何，透传用量事件的操作类型都是 passthrough，参见区分请求类型。对于可识别的形态，requested_model 是请求正文中的 model 值，即调用方发送的上游模型 ID，而不是 AISIX 模型别名，因为路由不解析模型。其他正文不记录模型。model_id 始终为空，因此透传用量按零成本记录：计价以 AISIX 模型为键。

DashScope 原生 Token 计数

对于 DashScope 原生正文，AISIX 按以下方式读取响应的顶层 usage 对象：

输出 Token 取自 output_tokens 或 completion_tokens。
存在 total_tokens 时，输入 Token 为 total_tokens 减去输出 Token。
没有 total_tokens 时，输入 Token 为 input_tokens（或 prompt_tokens）加上顶层的 image_tokens。嵌套的 input_tokens_details.image_tokens 已包含在 input_tokens 中，不会再累加。
缓存命中输入 Token 和推理 Token 按标准字段名从同一对象读取，例如 prompt_tokens_details.cached_tokens 和 output_tokens_details.reasoning_tokens。

这样无论服务把图片 Token 计入 input_tokens 之内还是之外，都只会计算一次：

服务	上游 `usage`	记录的输入	记录的输出
原生多模态 rerank，`qwen3-vl-rerank`	`input_tokens: 146`、`image_tokens: 64`、`total_tokens: 210`	210	0
多模态向量，`multimodal-embedding-v1`	`input_tokens: 4`、`image_tokens: 128`	132	0
原生多模态生成	`input_tokens: 79`、`image_tokens: 66`、`output_tokens: 14`、`total_tokens: 93`	79	14

示例：计量阿里云原生 Rerank

以下 AISIX Cloud 示例通过 /passthrough/dashscope 中继中国内地地域的 DashScope 原生 API。为 DashScope 凭证创建一个 alibaba-cn 服务提供方密钥。国际地域请使用 alibaba 服务提供方和 https://dashscope-intl.aliyuncs.com/api/v1。服务提供方密钥的 api_base 不影响这条路由，因为上游由路由的 target_url 决定：

export DASHSCOPE_API_KEY="YOUR_DASHSCOPE_API_KEY"

DASHSCOPE_KEY_ID=$(curl --fail-with-body -sS -X POST \
  "$AISIX_CP/provider_keys" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "display_name": "DashScope native",
    "provider": "alibaba-cn",
    "api_key": "'"${DASHSCOPE_API_KEY}"'",
    "allowed_environments": ["'"${ENV_ID}"'"]
  }' | jq -er '.provider_key.id')

curl --fail-with-body -sS -X POST \
  "$AISIX_CP/environments/$ENV_ID/passthrough_routes" \
  -H "Authorization: Bearer $AISIX_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "dashscope-native",
    "path_prefix": "/passthrough/dashscope",
    "target_url": "https://dashscope.aliyuncs.com/api/v1",
    "credential_mode": "inject",
    "provider_key_id": "'"${DASHSCOPE_KEY_ID}"'"
  }' | jq '.warnings // []'

在资源文件中声明同一条路由时，将 provider_key 设为某个 alibaba-cn 服务提供方密钥的 display_name。服务提供方密钥条目的写法见 Qwen：

resources.yaml（路由）
passthrough_routes:
  - name: dashscope-native
    path_prefix: /passthrough/dashscope
    target_url: https://dashscope.aliyuncs.com/api/v1
    provider_key: dashscope-cn

按照配置服务提供方原生路由中的方式，在调用方 Key 的 allowed_routes 中授予 dashscope-native。然后使用上游模型 ID 发送原生 rerank 请求：

curl --fail-with-body -sS \
  "$AISIX_PROXY/passthrough/dashscope/services/rerank/text-rerank/text-rerank" \
  -H "Authorization: Bearer $AISIX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "gte-rerank-v2",
    "input": {
      "query": "What does a passthrough route record?",
      "documents": [
        "A passthrough route relays provider-native requests.",
        "Usage events carry token counts and the route name."
      ]
    },
    "parameters": {"top_n": 2}
  }'

AISIX 剥离前缀，携带注入的凭证将正文中继到 https://dashscope.aliyuncs.com/api/v1/services/rerank/text-rerank/text-rerank，并原样返回 DashScope 的响应。正文的顶层 model 和 input 对象使其被识别为 DashScope 原生正文，因此用量事件将 gte-rerank-v2 记录为 requested_model，并将响应的 usage.total_tokens 记录为输入 Token。

限流

调用方 API Key、团队和成员的请求限制会在分发前生效。在 inject 路由上，如果顶层 JSON model 解析为同一服务提供方下已配置的 AISIX 模型，还会预留该模型的请求限制。forward_client 路由不执行此模型查找。

AISIX 会强制执行请求数维度限制（rps、rpm、rph 和 rpd）。当适用的 tpm 或 tpd 计数器已经耗尽时，AISIX 也会拒绝请求，但透传 Token 用量不会增加这些计数器。记录的用量应只用于遥测，而不是透传 Token 配额执行。

并发检查在向上游分发之前执行。每个匹配的 SSE 并发预留都会在整个流的生命周期内保持。Redis 支持的限制会从获取预留开始续约，直到流结束，并使用 concurrency_ttl_secs 回收不再续约的预留。如果 Redis 报告某个活跃预留已不存在，AISIX 会结束中继。此时调用方已收到 200，而最终用量事件记录状态 429、error_class="rate_limit_lease_lost" 和 error_message="distributed concurrency lease was lost"。有关故障和发布行为，请参阅 Redis 支持的并发租约。

透传路由没有限流字段或策略作用域。若要对不同路由应用不同的请求限制，请将路由授予不同的调用方 Key，并为这些调用方身份配置限制。

护栏与流式传输

在 AISIX Cloud 中，可以通过选择 Passthrough routes 作用域，将护栏挂载到一条透传路由。挂载使用路由 UUID。环境、调用方 Key 和团队护栏也可同时生效。

开源资源文件通过 guardrail_attachments 集合声明挂载关系，因此文件中定义的安全护栏只有在绑定将其作用域覆盖到透传流量时才会生效：可以使用 scope_type: env 覆盖整个环境，也可以使用 scope_type: passthrough_route 并指定该路由。

输入护栏在向上游分发前运行。拦截会返回 422，且不会联系上游。缓冲响应在交付前检查。SSE 响应一旦开始，拦截会以 SSE content_filter 错误帧结束流，无法再将 HTTP 状态码改为 422。

除非安全护栏暂存帧以进行检查，否则 SSE 响应会增量中继。AISIX 不会改写服务提供方原生正文来应用脱敏。对于内置 pii 护栏，仅配置掩码动作时，匹配内容会在不掩码的情况下转发，并记录为 mask_unsupported（监控模式下为 would_mask_unsupported）；如果匹配内容不得发送到上游，请使用拦截动作。Presidio 和 Lakera 等其他护栏类型在透传没有回写通道时，会改为拦截可掩码的结果。参见无法执行脱敏的接入面。

护栏扫描范围

安全护栏使用协议感知提取。对于成功解码的请求，它们还会检查与协议规范字段一起转发的普通 JSON 字符串，包括嵌套值。响应覆盖范围仍特定于协议，并且仅限于下表列出的字段。

工具调用 ID 是不透明的句柄，不是调用方内容，因此请求扫描会在可识别的信封中跳过它们：

Chat 和 Anthropic Messages：每个工具调用的 id、call_id、tool_use_id 和 tool_call_id，以及 tool 消息的 tool_call_id。
Responses：每个输入项上的 call_id 和 approval_request_id；任何 *_call 或 *_call_output 项，以及 item_reference、mcp_approval_request 或 reasoning 项的 id；以及 reasoning 项的 encrypted_content。因此，透传的 Responses 正文与 /v1/responses 请求的扫描方式相同。

函数名称、参数和工具结果仍会被扫描，下文列出的响应侧字段也从不包含 ID。只匹配上述某个值内部文本的护栏规则不会触发。其他任意正文一行不受影响，仍会读取每个已解码的字符串。

如果 AISIX 识别出信封但无法解码，它不会回退到扫描原始正文。顶层 model 是路由元数据，而不是调用方内容。类型化的不透明内容不会被重新解释为文本，包括图像、音频、文档和文件载荷，以及 redacted_thinking 数据。因此，Chat 行同时覆盖 OpenAI 兼容的 Chat 和 Anthropic Messages 流量：

信封	请求	响应
Chat 或 Anthropic Messages	消息文本和承载文本的内容块、Anthropic 顶层 `system`、`tool_result` 内容、Chat `tool_calls`，以及回放的 `tool_use` 输入、`thinking` 和 `reasoning_content`。	Chat 消息文本和 refusal，以及 function 和 custom tool 的名称与参数。对于 Anthropic，缓冲回复会扫描 `text` 块、`tool_use` 名称和输入；流会扫描 `tool_use` 开始事件，以及 `text` 和 `partial_json` delta。
Responses	`/v1/responses` 端点读取的每一个输入项，包括回放工具调用的名称、参数和输入。	输出文本、refusal 和工具调用：消息文本与 refusal 片段；`function_call` 和 `mcp_call` 的名称与参数；以及缓冲回复中 `custom_tool_call` 的名称和输入。流式载体包括对应的 delta 和 done 事件、内容片段和输出项快照，以及最终响应快照。
Completions	`prompt` 和 `suffix`。	补全 `text`。
其他任意正文	JSON 正文中每个已解码的字符串值；非 JSON 时为文本正文。	缓冲 JSON 正文提供其已解码的字符串值；其他缓冲文本直接扫描。不透明 SSE 流只能扫描单独的 JSON 字符串。其他承载内容的载荷形态无法评估，因为 AISIX 无法可靠地将其文本与之前的流内容关联。

在可识别的 Responses 信封中，已知媒体、推理和未知输出项仍按不透明内容处理。格式错误的可识别缓冲输出无法评估，并按已配置的失败策略处理。未知的 Responses 流事件仍不透明。

模型生成的推理内容（例如 reasoning_content、Anthropic thinking 和 Responses 推理摘要）在响应侧不会被扫描，但仍计入被保留流的 max_buffer_bytes。

审计捕获

对于成功中继的流量，配置了 content_mode: full 的可观测性导出器会以字符串形式接收请求正文，并受导出器内容上限约束。缓冲响应与受支持的提取形态匹配时记录提取出的文本，否则将正文记录为文本。流式响应记录累积的提取文本；不透明数据载荷保留为文本。捕获的内容仅发送给导出器，绝不会通过 AISIX Cloud 遥测路径发送。

用量事件包含路由名称、调用方、记录的 Token 数量和 client_identity。外部导出器可以公开这些值。当前 AISIX Cloud Request Logs UI 显示调用方和 Token 元数据，但不显示 passthrough_route_name 或 client_identity。

错误

状态码或信号	含义
`401`	按路由身份认证模式缺失或提供了无效的网关凭证。
`403`	解析出的调用方 Key 未授予该路由，或客户端来源不在 `source_cidrs` 范围内。
`404`	未被认领的 `/passthrough/*` 路径进入普通的空正文未找到处理流程。
`422`	护栏在分发前拦截了请求，或在交付前拦截了缓冲响应。
SSE `content_filter` 帧	护栏在流开始后拦截了内容。
`429`	网关请求限制或预算检查拒绝了请求，或上游返回了被中继的 `429`。
SSE 开始后的最终用量状态 `429`	调用方收到 `200` 后，Redis 支持的并发租约消失。用量事件记录 `error_class="rate_limit_lease_lost"`；请参阅在响应头之后失败的流。
其他上游状态码	AISIX 过滤响应头后，中继上游状态码和正文。

未匹配的 404 响应正文为空。AISIX 生成的其他失败使用网关错误信封；上游错误状态码和正文经过响应头过滤后中继。

下一步

使用主机名匹配路由接收经 TLS 终止的 IDE 流量：IDE AI 流量正向代理。
配置护栏行为：护栏行为。
导出请求和响应内容：可观测性导出器。

准备工作​

了解透传流程​

配置服务提供方原生路由​

AISIX Cloud​

开源 AISIX 网关​

验证路由​

比较 Cloud 与资源文件引用​

配置参考​

网关身份认证模式​

上游凭证模式​

信封识别与用量​

各请求形态记录的用量​

DashScope 原生 Token 计数​

示例：计量阿里云原生 Rerank​

限流​

护栏与流式传输​

护栏扫描范围​

审计捕获​

错误​

下一步​