All Products
Search
Document Center

Container Compute Service:Customize the routing rules of an ALB Ingress

Last Updated:Mar 26, 2026

ALB Ingress routing rules consist of conditions and actions. Conditions match requests on domain names, paths, request headers, query strings, request methods, cookies, or source IP addresses. Actions define what happens to matched requests: return a fixed response, redirect, insert or remove headers, mirror traffic, forward to multiple backend server groups, or rewrite the request.

Prerequisites

Before you begin, ensure that:

  • ALB Ingress Controller 2.5.0 or later is installed in your cluster. For more information, see Manage components

Configuring custom routing rules from the ALB console is in canary release. To enable this feature, submit a ticketsubmit a ticketsubmit a ticket.

Routing conditions

Configure routing conditions using the alb.ingress.kubernetes.io/conditions.<service-name> annotation. The <service-name> value must match the Service name in the backend field of the Ingress rules.

Condition logic:

  • Multiple condition blocks in one rule: AND (all blocks must match)

  • Multiple values within one condition block: OR (any value matches)

Important

A single routing rule supports at most 10 conditions. The ResponseHeader and ResponseStatusCode condition types apply only to outbound routing rules.

The following table lists all available condition types and their annotation templates.

Conditiontype value
Domain nameHost
PathPath
Request headerHeader
Query stringQueryString
Request methodMethod
CookieCookie
Source IPSourceIp
Response header (outbound only)ResponseHeader
Response status code (outbound only)ResponseStatusCode

Condition reference

Domain name

Routes requests destined for specific domain names. Multiple values use OR logic.

alb.ingress.kubernetes.io/conditions.host-example: |
  [{
    "type": "Host",
    "hostConfig": {
      "values": [
        "anno.example.com"
      ]
    }
  }]

Path

Routes requests sent to specific paths. Multiple values use OR logic.

alb.ingress.kubernetes.io/conditions.path-example: |
  [{
    "type": "Path",
    "pathConfig": {
      "values": [
        "/pathvalue1",
        "/pathvalue2"
      ]
    }
  }]

Request header

Routes requests that contain a specific header key-value pair. Multiple values for the same key use OR logic.

alb.ingress.kubernetes.io/conditions.http-header-example: |
  [{
    "type": "Header",
    "headerConfig": {
      "key": "headername",
      "values": [
        "headervalue1",
        "headervalue2"
      ]
    }
  }]

Query string

Routes requests that contain specific query string key-value pairs. Keys and values must be 1–100 characters and can contain lowercase letters, visible characters, *, and ?. Spaces and the characters # [] {} \ | <> & are not allowed. Multiple pairs use OR logic.

alb.ingress.kubernetes.io/conditions.query-string-example: |
  [{
    "type": "QueryString",
    "queryStringConfig": {
      "values": [
        {
          "key": "querystringkey1",
          "value": "querystringvalue2"
        }
      ]
    }
  }]

Request method

Routes requests that use specific HTTP methods. Supported methods: GET, POST, PUT, DELETE, HEAD, OPTIONS, and PATCH. Multiple values use OR logic.

alb.ingress.kubernetes.io/conditions.http-method-example: |
  [{
    "type": "Method",
    "methodConfig": {
      "values": [
        "GET",
        "HEAD"
      ]
    }
  }]

Cookie

Routes requests that contain specific cookie key-value pairs. Keys and values must be 1–100 characters and can contain lowercase letters, visible characters, *, and ?. Spaces and the characters # [] {} \ | <> & are not allowed. Multiple pairs use OR logic.

alb.ingress.kubernetes.io/conditions.http-cookie-example: |
  [{
    "type": "Cookie",
    "cookieConfig": {
      "values": [
        {
          "key": "cookiekey1",
          "value": "cookievalue2"
        }
      ]
    }
  }]

Source IP

Routes requests from specific source IP address ranges. Multiple values use OR logic.

Important

A single routing rule supports at most five source IP addresses.

alb.ingress.kubernetes.io/conditions.source-ip-example: |
  [{
    "type": "SourceIp",
    "sourceIpConfig": {
      "values": [
        "192.168.0.0/16",
        "172.16.0.0/16"
      ]
    }
  }]

Response header (outbound rules only)

Matches responses that contain a specific response header. Multiple values use OR logic.

alb.ingress.kubernetes.io/conditions.response-header-example: |
  [{
    "type": "ResponseHeader",
    "headerConfig": {
      "key": "headername",
      "values": [
        "headervalue1",
        "headervalue2"
      ]
    }
  }]

Response status code (outbound rules only)

Matches responses that return specific HTTP status codes. Multiple values use OR logic.

alb.ingress.kubernetes.io/conditions.response-code-example: |
  [{
    "type": "ResponseStatusCode",
    "responseStatusCodeConfig": {
      "values": [
        "statuscode1",
        "statuscode2"
      ]
    }
  }]

Condition examples

Route traffic based on source IP and request headers

The following Ingress routes requests to gray-hello only when all three conditions are met: the source IP is in 192.168.0.0/16 or 172.16.0.0/16, the gray-hello header value is value1 or value2, and the path is /hello. All other requests go to other Services.

alb.ingress.kubernetes.io/order sets the Ingress priority — lower values take higher priority.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/order: "1"
    alb.ingress.kubernetes.io/conditions.gray-hello: |
      [{
        "type": "Header",
        "headerConfig": {
          "key": "gray-hello",
          "values": [
            "value1",
            "value2"
          ]
        }
       },
       {
         "type": "SourceIp",
         "sourceIpConfig": {
           "values": [
             "192.168.0.0/16",
             "172.16.0.0/16"
           ]
         }
      }]
  name: gray-hello
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /hello
            pathType: ImplementationSpecific
            backend:
              service:
                name: gray-hello
                port:
                  number: 88

Route traffic based on domain name, request method, and cookie

The following Ingress routes requests to service-a only when all conditions match: the domain is www.hostvalue1.edu or www.hostvalue2.edu, the method is GET or HEAD, the cookie cookiekey1 is cookievalue1, and the path is /test. Other requests go to service-b.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/conditions.service-a: |
      [{
        "type": "Cookie",
        "cookieConfig": {
          "values": [
            {
              "key": "cookiekey1",
              "value": "cookievalue1"
            }
          ]
        }
       },
       {
        "type": "Method",
        "methodConfig": {
          "values": [
            "GET",
            "HEAD"
          ]
        }
       },
       {
        "type": "Host",
        "hostConfig": {
          "values": [
            "www.hostvalue1.edu",
            "www.hostvalue2.edu"
          ]
        }
      }]
  name: ingress-example
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /test
            pathType: ImplementationSpecific
            backend:
              service:
                name: service-a
                port:
                  number: 88
          - path: /test
            pathType: ImplementationSpecific
            backend:
              service:
                name: service-b
                port:
                  number: 88

Route traffic based on query string, multiple request headers, and multiple paths

The following Ingress routes requests to service-a when all conditions match: the path is /pathvalue1, /pathvalue2, or /test; the query string querystringkey1 equals querystringvalue2; the header headerkey1 is headervalue1 or headervalue2; and the header headerkey2 is headervalue3 or headervalue4. Other requests go to service-b.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/conditions.service-a: |
      [{
        "type": "Path",
        "pathConfig": {
          "values": [
            "/pathvalue1",
            "/pathvalue2"
          ]
        }
       },
       {
        "type": "QueryString",
        "queryStringConfig": {
          "values": [
            {
              "key": "querystringkey1",
              "value": "querystringvalue2"
            }
          ]
        }
       },
       {
        "type": "Header",
        "headerConfig": {
          "key": "headerkey1",
          "values": [
            "headervalue1",
            "headervalue2"
          ]
        }
       },
       {
        "type": "Header",
        "headerConfig": {
          "key": "headerkey2",
          "values": [
            "headervalue3",
            "headervalue4"
          ]
        }
      }]
  name: ingress-example
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /test
            pathType: ImplementationSpecific
            backend:
              service:
                name: service-a
                port:
                  number: 88
          - path: /test
            pathType: ImplementationSpecific
            backend:
              service:
                name: service-b
                port:
                  number: 88

Routing actions

Configure routing actions using the alb.ingress.kubernetes.io/actions.<service-name> annotation. The <service-name> value must match the Service name in the backend field of the Ingress rules.

Important
  • In the same routing rule, you cannot combine multiple termination actions. Fixed response, redirect, and forward to multiple backend server groups are mutually exclusive.

  • When using fixed response, redirect, or forward to multiple backend server groups, set the servicePort name in the backend field to use-annotation.

Actions for inbound routing rules

ActionDescription
Fixed responseReturns fixed content (status code, content type, and body) directly to the client
RedirectRedirects requests using HTTP 3xx status codes
Insert request headerInserts or overwrites a header in the request
Remove request headerRemoves a header from the request
Traffic mirroringCopies traffic to a specified server group
Forward to multiple backend server groupsDistributes requests across server groups by weight
RewriteRewrites the domain name, path, or query string
QPS throttlingLimits request rate globally or per client IP

Actions for outbound routing rules

ActionDescription
Insert response headerInserts or overwrites a header in the response
Remove response headerRemoves a header from the response

Action examples

Return a fixed response with status code 503

Use the ACS console

  1. Log on to the ACS console. In the left-side navigation pane, click Clusters.

  2. On the Clusters page, click the target cluster ID. In the left-side navigation pane, choose Network > Ingresses.

  3. On the Ingresses page, click Create Ingress and configure the following parameters.

    ParameterDescriptionExample
    Gateway typeSelect ALB or MSE Ingress.ALB
    Application nameName of the Ingress.ingress
    Ingress classClass of the Ingress.alb
    Listener/PortListener port and protocol defined in AlbConfig.HTTP:80
    RulesClick +Add Rule to configure domain name, path, matching rule, Service, and port.Domain name: (blank); Path: /; Rule: Prefix; Service: response-503; Port: 80
    TLS settingsEnable TLS authentication.Disabled
    Custom forwarding rulesClick +Add Rule to add forwarding conditions and actions. Up to 10 conditions per rule.Condition: Path (default); Action: Return fixed response — Status code: 503, Content type: text/plain, Content: error
  4. Click OK.

kubectl

The following Ingress returns status code 503 with body 503 error text for all requests to /.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: ingress
  annotations:
    alb.ingress.kubernetes.io/actions.response-503: |
      [{
        "type": "FixedResponse",
        "FixedResponseConfig": {
          "contentType": "text/plain",
          "httpCode": "503",
          "content": "503 error text"
        }
      }]
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: response-503
                port:
                  name: use-annotation # Must be use-annotation for fixed response actions

The FixedResponseConfig parameters:

ParameterDescription
contentTypeContent type of the response body. Valid values: text/plain, text/css, text/html, application/javascript, application/json
httpCodeHTTP status code returned to the client
contentResponse body content

Redirect requests to HTTPS using 301

The following Ingress redirects all HTTP requests to HTTPS using a 301 permanent redirect.

Important

At least one redirect parameter other than httpCode must differ from its default value.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: ingress
  annotations:
    alb.ingress.kubernetes.io/actions.redirect: |
      [{
        "type": "Redirect",
        "RedirectConfig": {
          "host": "${host}",
          "path": "${path}",
          "port": "${port}",
          "protocol": "https",
          "query": "${query}",
          "httpCode": "301"
        }
      }]
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: redirect
                port:
                  name: use-annotation # Must be use-annotation for redirect actions

The RedirectConfig parameters:

ParameterDescription
hostDomain name to redirect to. Use ${host} to keep the original.
pathPath to redirect to. Use ${path} to keep the original.
portPort to redirect to. Use ${port} to keep the original.
protocolProtocol of the redirected request (e.g., https). Use ${protocol} to keep the original.
queryQuery string of the redirected request. Use ${query} to keep the original.
httpCodeHTTP status code for the redirect (e.g., 301, 302).

Insert a request header

The following Ingress inserts a source: alibaba header into all requests before forwarding them to the backend. If the header already exists, it is overwritten.

The Service name in the annotation must match the Service name in the backend field.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: ingress
  annotations:
    alb.ingress.kubernetes.io/actions.insert-header: |
      [{
        "type": "InsertHeader",
        "InsertHeaderConfig": {
          "key": "source",
          "value": "alibaba",
          "valueType": "UserDefined"
        }
      }]
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: insert-header
                port:
                  number: 80

Mirror traffic to a server group

The following Ingress mirrors all traffic matching demo.domain.ingress.top/test to a specified server group while continuing to forward the original request normally.

Important
  • Traffic mirroring can be combined with forward, insert header, remove header, and QPS throttling actions. It is mutually exclusive with rewrite, fixed response, and redirect actions.

  • Specify the target server group using ServerGroupID only.

To get a server group ID, log on to the Server Load Balancer (SLB) console, choose ALB > Server Groups, and find the ID on the Server Groups page.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: traffic-mirror-ingress
  annotations:
    # The Service name in the annotation must match the Service name in the backend field.
    alb.ingress.kubernetes.io/actions.traffic-mirror: |
      [{
        "type": "TrafficMirror",
        "TrafficMirrorConfig": {
          "TargetType": "ForwardGroupMirror",
          "MirrorGroupConfig": {
            "ServerGroupTuples": [{
              "ServerGroupID": "sgp-2auud2fxj1r46*****"
            }]
          }
        }
      }]
spec:
  ingressClassName: alb
  rules:
    - host: demo.domain.ingress.top
      http:
        paths:
          - path: /test
            pathType: Prefix
            backend:
              service:
                name: traffic-mirror
                port:
                  number: 80

Forward requests to multiple backend server groups

Distribute requests across multiple backend server groups by weight.

Important
  • A standard ALB instance supports at most five backend server groups.

  • If both ServerGroupID and ServiceName/ServicePort are set for the same entry, ServerGroupID takes precedence.

Use the ACS console

  1. Log on to the ACS console. In the left-side navigation pane, click Clusters.

  2. On the Clusters page, click the target cluster ID. In the left-side navigation pane, choose Network > Ingresses.

  3. On the Ingresses page, click Create Ingress and configure the following parameters.

    If you select Forward To as the action, you do not need to configure the Mappings parameter in the Rules section. Clusters using the Flannel component do not support ClusterIP Services.
    ParameterDescriptionExample
    Gateway typeSelect ALB or MSE Ingress.ALB
    Application nameName of the Ingress.forward-ingress
    Ingress classClass of the Ingress.alb
    Listener/PortListener port and protocol.HTTP:80
    RulesClick +Add Rule to set domain name, path, Service, and port.Domain name: demo.domain.ingress.top; Path: /path; Rule: Prefix; Service: forward; Port: 80
    TLS settingsEnable TLS authentication.Disabled
    Custom forwarding rulesCondition: Domain name = demo.domain.ingress.top. Action: Forward to — Service: tea-svc, Port: 80, Weight: 80; add a second Service: coffee-svc, Port: 80, Weight: 20.See example values
  4. Click OK.

kubectl

The following Ingress distributes requests matching demo.domain.ingress.top/path to tea-svc (weight 80) and coffee-svc (weight 20).

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: forward-ingress
  annotations:
    # The Service name in the annotation must match the Service name in the backend field.
    alb.ingress.kubernetes.io/actions.forward: |
      [{
        "type": "ForwardGroup",
        "ForwardConfig": {
          "ServerGroups": [{
            "ServiceName": "tea-svc",
            "Weight": 80,
            "ServicePort": 80
          },
          {
            "ServiceName": "coffee-svc",
            "Weight": 20,
            "ServicePort": 80
          }]
        }
      }]
spec:
  ingressClassName: alb
  rules:
    - host: demo.domain.ingress.top
      http:
        paths:
          - path: /path
            pathType: Prefix
            backend:
              service:
                name: forward
                port:
                  name: use-annotation # Must be use-annotation for forward actions

To reference existing server groups by ID instead of Service name, use ServerGroupID and Weight:

alb.ingress.kubernetes.io/actions.forward: |
  [{
    "type": "ForwardGroup",
    "ForwardConfig": {
      "ServerGroups": [{
        "ServerGroupID": "sgp-71aexb9y93ypo*****",
        "Weight": 80
      },
      {
        "ServerGroupID": "sgp-slygpbvm2cydo*****",
        "Weight": 20
      }]
    }
  }]

Rewrite the domain name, path, or query string

The following Ingress rewrites the domain name to demo.domain.ingress.top, the path to /test, and the query string to querystring for all requests matching /path.

Important
  • The rewrite action conflicts with the rewrite-target annotation. Do not use both.

  • Rewrite cannot be combined with fixed response or redirect actions.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  namespace: default
  name: rewrite-ingress
  annotations:
    alb.ingress.kubernetes.io/actions.rewrite: |
      [{
        "type": "Rewrite",
        "RewriteConfig": {
          "Host": "demo.domain.ingress.top",
          "Path": "/test",
          "Query": "querystring"
        }
      }]
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /path
            pathType: Prefix
            backend:
              service:
                name: rewrite
                port:
                  number: 80

For more information about rewrite rules, see Configure rewrite rules.

Modify a response header based on the response header value

By default, custom routing rules apply to inbound traffic. To apply a rule to outbound traffic (responses), set alb.ingress.kubernetes.io/rule-direction.<service-name> to Response.

Important

For outbound routing rules, set the servicePort name in the backend field to use-annotation.

The following Ingress inserts a source: alibaba header into the response when the response already contains a response-hello header with value value1 or value2.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/rule-direction.response-header: Response
    alb.ingress.kubernetes.io/conditions.response-header: |
      [{
        "type": "ResponseHeader",
        "responseHeaderConfig": {
          "key": "response-hello",
          "values": [
            "value1",
            "value2"
          ]
        }
      }]
    alb.ingress.kubernetes.io/actions.response-header: |
      [{
        "type": "InsertHeader",
        "InsertHeaderConfig": {
          "key": "source",
          "value": "alibaba",
          "valueType": "UserDefined"
        }
      }]
  name: response-header
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /
            pathType: ImplementationSpecific
            backend:
              service:
                name: response-header
                port:
                  name: use-annotation # Must be use-annotation for outbound routing rules

Remove a response header based on the response status code

The following Ingress removes the response-hello header from responses that return status code 200 or 300.

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    alb.ingress.kubernetes.io/rule-direction.response-hello: Response
    alb.ingress.kubernetes.io/conditions.response-hello: |
      [{
        "type": "ResponseStatusCode",
        "responseStatusCodeConfig": {
          "values": [
            "200",
            "300"
          ]
        }
      }]
    alb.ingress.kubernetes.io/actions.response-hello: |
      [{
        "type": "RemoveHeader",
        "RemoveHeaderConfig": {
          "key": "response-hello"
        }
      }]
  name: response-hello
spec:
  ingressClassName: alb
  rules:
    - http:
        paths:
          - path: /*
            pathType: ImplementationSpecific
            backend:
              service:
                name: response-hello
                port:
                  name: use-annotation # Must be use-annotation for outbound routing rules

Limit request rate with QPS throttling

Set a global request rate limit, a per-client-IP rate limit, or both. The QPS throttling action must be combined with a forward action.

Important
  • Valid values for QPS and QPSPerIp: 1 to 1,000,000.

  • If both QPS and QPSPerIp are set, QPSPerIp must be smaller than QPS.

  • When the rate limit is exceeded, the ALB instance rejects new connections and returns HTTP 503.

  • To use QPSPerIp (per-IP rate limiting), enable the option to retrieve client IP addresses on the listener details page so the ALB instance can read the X-Forwarded-For header. For more information, see XForwardedForConfig.

annotations:
  alb.ingress.kubernetes.io/actions.traffic-limit: |
    [{
      "type": "TrafficLimit",
      "TrafficLimitConfig": {
        "QPS": "1000",
        "QPSPerIp": "100"
      }
    }]
ParameterDescription
QPSGlobal request rate limit (requests per second). When exceeded, new connections are rejected and HTTP 503 is returned.
QPSPerIpPer-client-IP request rate limit (requests per second). Must be smaller than QPS if both are set. When exceeded, new connections are rejected and HTTP 503 is returned.