AISIX 0.7.1

Release date: July 31, 2026

This release makes the gateway deployable on networks it could not previously reach. Outbound connections gain a trust configuration, so a model endpoint, guardrail, or MCP upstream whose certificate is signed by a private or enterprise authority can be dialed without a process-wide workaround, either deployment-wide or per endpoint on the provider key that declares it. A data plane running on a separate host and addressed by an IP address can now complete the mutual TLS handshake and join its control plane. Requests that a caller abandons, and requests the gateway refuses before dispatch, are no longer invisible in the access log and metrics.

Behavior Changes

• A streaming response that the caller abandons mid-delivery is now recorded as 499 rather than 200. The usage event previously reported a completed delivery, so a caller that closed the connection halfway through a stream could not be told apart from one that read the stream to the end. Reports and dashboards that select on status 200 will see these requests move to 499. See Metrics and Logs.

New Features

Outbound TLS

• A new upstream.tls setting configures the trust the gateway uses on every connection it dials out on, through ca_file, client_cert_file, client_key_file, and verify. It applies to provider endpoints, all guardrail providers, MCP and A2A upstreams, passthrough routes, JWKS and OIDC discovery, and OpenTelemetry export. An upstream behind a private certificate authority previously failed with a generic connection error, and the only workaround was the process-wide SSL_CERT_FILE environment variable, which several outbound paths did not honor. See TLS and mTLS.
• A provider key can carry its own tls block, with an inline ca_cert and a verify flag, so a deployment facing more than one private authority declares trust where it declares the endpoint. The certificate is supplied inline rather than as a file path, because whoever configures a provider key has no way to place a file on the gateway host. In AISIX Cloud, the dashboard exposes this as an Endpoint TLS section on the provider key form.
• A rediss:// cache or rate-limit backend takes its own tls block with the same fields, since it usually sits inside your own deployment and is issued by a different authority than the model endpoints. Two limits are documented rather than silently ignored: Amazon Bedrock supports ca_file but neither client certificates nor verify: false, and Redis Sentinel mode supports verify but not ca_file.

Improvements

• Requests refused before dispatch now appear in the access log and in aisix_requests_total. A body over request_body_limit_bytes returned a correct 413 and otherwise left no trace, which made a client reporting a rejection the gateway had no record of indistinguishable from a request that never arrived. The 400 for conflicting Content-Length headers had the same gap. These rejections are refused before authentication, so they carry no usage event and do not appear on the logs page in AISIX Cloud.
• Requests abandoned before the response head are recorded instead of vanishing. Such a request was previously absent from the access log, the usage events, and the metrics at the same time, which hid the case operators most want to see: a caller giving up during a long time to first token. A new counter, aisix_proxy_client_cancelled_requests_total, labeled by endpoint, counts them. See Metrics and Logs.

Fixes

• A data plane on a separate host, pointed at its control plane by an IP address, can complete the mutual TLS handshake and join. The data-plane manager issued a server certificate whose subject alternative names came only from its listen address and from the server name the client sent, and in a container neither yields the control plane's external address: the listener is bound to all interfaces, so there is no host to read, and a client dialing an IP address sends no server name at all. The advertised endpoint is now passed to the data-plane manager, which issues the certificate for that host, so an IP address works as well as a DNS name. Set it through AISIX_CLOUD_DPMGR_BASE_URL, or api.dpmgrBaseURL in the Helm chart. See On-Premises Deployment.