Forward proxy support

Related Documentation
Minimum Version
AI Gateway - 2.0
Incompatible with
on-prem
Related Resources

What is forward proxy support?

In network-isolated deployments, AI Gateway cannot open direct outbound connections to LLM providers or auxiliary services. Forward proxy support lets you route outbound requests from AI Models and AI MCP Servers through a controlled HTTP forward proxy so that inference traffic, semantic operations, and guardrail checks continue to work behind a strict egress policy.

Outbound requests issued by an AI Model or MCP Server can be sent through the specified proxy host by setting a proxy record in their config that names the proxy host, port, scheme, excluded hosts, and optionally credentials. Existing capabilities such as load balancing, health checking, streaming, WebSocket, and HTTP/2 continue to work.

How forward proxy support works

AI Gateway sends three categories of outbound request. A proxy can be applied to all three, using a different mechanism depending on where the request originates.

The three request categories are:

  • Inference: Requests from clients to LLM providers, proxied by an AI Model through the AI Gateway. This is the majority of AI Gateway traffic. Load balancing, health checks, retries, streaming, WebSocket, and HTTP/2 all continue to function when forward proxy support is active. Upstream keepalive is disabled while the forward proxy is active, so inference connections are not reused across requests targeting different upstream peers.
  • Identity auth: Cloud identity authentication issued by provider SDKs. This includes, AWS Bedrock SigV4 signing, Azure and GCP managed identity token acquisition when targets require managed identity.
  • Auxiliary calls: Direct HTTP calls from semantic, RAG, guardrail, sanitizer, and compressor Policies to their external services. For example, an embeddings service, AWS Bedrock Guardrails, Azure Content Safety, Lakera, GCP Model Armor, or a configured custom endpoint.
 
flowchart LR
  Client --> AIModel
  Client --> Aux
  subgraph Gateway_Group[Kong AI Gateway]
    subgraph Policies[AI Entities]
      AIModel[AI Model]
      Aux[AI MCP Server]
    end
  end
  AIModel -- inference --> Proxy[Forward proxy]
  AIModel -- "identity auth" --> Proxy
  Aux -- "MCP calls" --> Proxy
  Proxy --> LLM[LLM providers]
  Proxy --> CloudAPI[Cloud platform APIs]
  Proxy --> AuxSvc[Upstream MCP]
  style Policies stroke-dasharray: 5 5
  

Figure 1: Outbound traffic from AI Gateway Policies routed through a forward proxy.

When proxy is set on an AI Model or MCP Server entity, every outbound request that entity issues goes through the configured proxy.

Relationship to the Forward Proxy Advanced plugin

Kong Gateway also provides the Forward Proxy Advanced plugin for routing non-AI upstream traffic through an intermediary HTTP proxy. For non-AI services use the Forward Proxy Advanced plugin.

The Forward Proxy Advanced plugin takes over the request before the balancer phase runs, which works for standard Gateway Services but not with behavior that AI Gateway depends on: upstream load balancing, health check reporting, retries, WebSocket upgrades, and HTTP/2 request bodies.

For AI Gateway traffic through an AI Model or MCP Server entity, you should use the native proxy configuration instead. This ensures the balancer phase continues to run normally. Load balancing across LLM targets, streaming, real-time API traffic, and HTTP/2 inference requests all remain functional when the forward proxy is active and you have configured proxy.

Proxy configuration fields

AI Models accept a proxy record at the top level of their config block. MCP Servers only accept it when their type is passthrough-listener. conversion-listener and listener type MCP Servers do not currently support forward proxy configuration at all.

Field

Type

Description

http_proxy object The forward proxy used for HTTP upstreams. An object with host and port fields.
https_proxy object The forward proxy used for HTTPS upstreams. An object with host and port fields.
proxy_scheme string Scheme used to connect to the forward proxy itself. Currently only http is supported. Defaults to http.
auth object Credentials for proxy authentication. An object with username and password fields. Both are optional and referenceable from an AI Vault.
no_proxy string Comma-separated list of hosts that should not be proxied.

Two validation rules apply to the record:

  • If http_proxy is set, both host and port must be set.
  • If https_proxy is set, both host and port must be set.

Supported Policies

You can also configure AI Policies to use your forward proxy by setting the same proxy records at the top level of their config block.

The following AI Policies are supported:

Traffic

Policies

Proxied destination

Embeddings and semantic operations The configured embeddings service
Prompt compression and sanitization The configured compressor_url or sanitizer_url
Guardrail services Managed or custom guardrail service

Configuration

Set up a forward proxy

You can use Squid to create a simple forward proxy for testing.

Squid runs as its own Docker container, separate from the AI Gateway data plane container. In the following examples, the data plane reaches Squid through host.docker.internal, the special hostname that Docker Desktop and OrbStack resolve to the host machine from inside any container. This works because the compose file below publishes Squid’s port to the host, so any container — including the AI Gateway data plane, which runs in its own separate Docker network — can reach it via the host machine, without needing to share a Docker network or edit your machine’s hosts file.

In a production deployment your forward proxy should authenticate users, including AI Gateway. To do this. set auth_username and auth_password. You can reference secrets from an AI Vault.

  1. Create a minimal config file for Squid:

     echo '
     # Allow your local machine. Different container runtimes (Docker Desktop, OrbStack, Colima)
     # allocate bridge networks in different private ranges, so this allows all of them.
     acl localnet src 10.0.0.0/8
     acl localnet src 172.16.0.0/12
     acl localnet src 192.168.0.0/16
    
     acl SSL_ports port 443
     acl Safe_ports port 80 443
    
     http_access deny !Safe_ports
     http_access allow localnet
     http_access allow localhost
     http_access deny all
    
     http_port 3128
    
     access_log /var/log/squid/access.log combined
     cache_log /var/log/squid/cache.log
     ' > squid.conf
  2. Create a docker compose file:

     echo '
     services:
       squid:
         image: ubuntu/squid
         container_name: squid
         ports:
           - "3128:3128"
         volumes:
           - ./squid.conf:/etc/squid/squid.conf:ro
     ' > docker-compose.yml
  3. Run Squid using docker:

     docker compose up -d

AI Gateway

To create a new AI Gateway using Konnect, do the following:

  1. Create a new personal access token from the Konnect PAT page by selecting Generate Token.
  2. Export your token as an environment variable:

    export KONNECT_TOKEN='YOUR_KONNECT_PAT'
  3. Run the AI Gateway quickstart script to automatically provision a control plane in Kong Konnect and a local data plane:

    curl -Ls https://get.konghq.com/ai | bash -s -- -k $KONNECT_TOKEN

This sets up a AI Gateway control plane named ai-quickstart, provisions a local data plane, and prints out the following environment variables export:

export AI_GATEWAY_ID=your-gateway-id
export DECK_KONNECT_TOKEN=$KONNECT_TOKEN
export DECK_KONNECT_CONTROL_PLANE_NAME=quickstart
export KONNECT_CONTROL_PLANE_URL=https://us.api.konghq.com
export KONNECT_PROXY_URL='http://localhost:8000'

Copy and paste these into your terminal to configure your session.

AI Model

Create a model and provider

Generate an Anthropic API key, then export it as an environment variable:

export ANTHROPIC_API_KEY='YOUR_ANTHROPIC_API_KEY'

Create an AI Provider entity to define your LLM service and store authentication credentials:

kongctl apply -f - --auto-approve --pat "$KONNECT_TOKEN" << 'EOF'
ai_gateway_model_providers:
  - ref: generic-anthropic
    ai_gateway: !lookup {id: !env AI_GATEWAY_ID}
    name: generic-anthropic
    display_name: "generic-anthropic"
    type: anthropic
    config:
      auth:
        type: basic
        headers:
          - name: x-api-key
            value: !secret {source: !env ANTHROPIC_API_KEY}
EOF

Create an AI Model entity and specify your forward proxy host:

kongctl apply -f - --auto-approve --pat "$KONNECT_TOKEN" << 'EOF'
ai_gateway_models:
  - ref: my-claude
    ai_gateway: !lookup {id: !env AI_GATEWAY_ID}
    name: my-claude
    display_name: "my-claude"
    type: model
    formats:
      - type: anthropic
    config:
      route:
        paths:
          - /
        model:
          body_param: model
          values:
            - my-claude
      proxy:
        http_proxy:
          host: host.docker.internal
          port: 3128
        https_proxy:
          host: host.docker.internal
          port: 3128
        proxy_scheme: http
    targets:
      - name: claude-opus-4-8
        provider: generic-anthropic
        config:
          type: anthropic
    policies: []
    capabilities:
      - generate
EOF

Validate

  1. Send a chat request. This will be forwarded through your proxy service to Anthropic:

    curl -X POST "$KONNECT_PROXY_URL/v1/messages" \
         --no-progress-meter --fail-with-body  \
         -H "Accept: application/json"\
         -H "Content-Type: application/json"\
         -H "Authorization: Bearer $ANTHROPIC_API_KEY" \
         --json '{
           "model": "my-claude",
           "max_tokens": 100,
           "messages": [
             {
               "role": "user",
               "content": "Say this is a test!"
             }
           ]
         }'
  2. Examine the Squid logs to verify your requests:

     docker exec -it squid tail -f /var/log/squid/access.log

AI MCP Server

  1. Run the Swagger Petstore sample API in its own Docker container:

     docker run -d \
       --name swagger-petstore-forward-proxy \
       -p 8080:8080 \
       swaggerapi/petstore3:latest
  2. Create an AI MCP Server entity that exposes the Petstore API through a single MCP tool:

    curl -X POST "https://us.api.konghq.com/v1/ai-gateways/$AI_GATEWAY_ID/mcp-servers" \
         --no-progress-meter --fail-with-body  \
         -H "Authorization: Bearer $KONNECT_TOKEN"\
         -H "Content-Type: application/json"\
         -H "Accept: application/json, application/problem+json" \
         --json '{
           "display_name": "Petstore API (forward proxy)",
           "name": "petstore-forward-proxy-mcp",
           "type": "conversion-listener",
           "enabled": true,
           "policies": [],
           "access": {
             "acl_attribute_type": "consumer",
             "acls": {
               "allow": []
             },
             "default_tool_acls": {
               "deny": []
             }
           },
           "config": {
             "url": "http://host.docker.internal:8080/api/v3",
             "route": {
               "paths": [
                 "/petstore-forward-proxy"
               ]
             },
             "logging": {
               "payloads": false
             },
             "server": {
               "timeout": 60000
             }
           },
           "tools": [
             {
               "name": "get-pet-by-id",
               "description": "Get a pet by ID",
               "method": "GET",
               "path": "/petstore-forward-proxy/pet/{petId}",
               "parameters": [
                 {
                   "name": "petId",
                   "in": "path",
                   "required": true,
                   "schema": {
                     "type": "integer"
                   },
                   "description": "ID of the pet to retrieve"
                 }
               ]
             }
           ]
         }'
  3. Use MCP Inspector CLI to verify that the MCP server exposes get-pet-by-id as a tool:

    npx -y @modelcontextprotocol/inspector@0.22.0 --cli \
      http://localhost:8000/petstore-forward-proxy \
      --transport http --method tools/list | jq -r '.tools[].name'

    You should see the following output:

     get-pet-by-id
  4. This MCP Server does not route through your forward proxy, since conversion-listener doesn’t support it. Calling get-pet-by-id reaches Petstore directly:

    npx -y @modelcontextprotocol/inspector@0.22.0 --cli \
      http://localhost:8000/petstore-forward-proxy \
      --transport http --method tools/call \
      --tool-name get-pet-by-id \
      --tool-arg path_petId=7 | jq -r '.content[0].text' | jq -c '.'

    You should see the following response:

     {"id":7,"category":{"id":4,"name":"Lions"},"name":"Lion 1","photoUrls":["url1","url2"],"tags":[{"id":1,"name":"tag1"},{"id":2,"name":"tag2"}],"status":"available"}

Limitations

  • Connections to vector databases (such as pgvector, Redis Vector, or Pinecone) use native database protocols rather than HTTP and are not routed through the forward proxy. If these connections must traverse a forward proxy, you should handle it at the network layer.
  • The AI Request Transformer, AI Response Transformer, and AI LLM as a Judge Policies keep their existing flat proxy fields (http_proxy_host, http_proxy_port, https_proxy_host, https_proxy_port) and do not accept a proxy record. They do not expose auth_username, auth_password, proxy_scheme, or https_verify, so proxy authentication and HTTPS-scheme proxies are unavailable for their traffic.

Help us make these docs great!

Kong Developer docs are open source. If you find these useful and want to make them better, contribute today!