Page Rules - Proxy

# Overview

The proxy section in OpenResty Edge’s page rules configures request proxy behavior. This includes selecting upstream servers, load balancing strategies, timeout settings, and more.

# Configuration Description

The proxy configuration is an optional part of page rules. It contains the following main fields:

# upstream and backup_upstream Configuration

Both upstream and backup_upstream are lists of upstream servers; each server configuration includes:

http represents a regular upstream within the HTTP application. http_k8s represents a Kubernetes upstream within the HTTP application. global represents a global regular upstream. global_k8s represents a global Kubernetes upstream.

# balancer Configuration

The balancer configures the load-balancing strategy:

# sticky Configuration

sticky is used to configure session persistence, ensuring requests from the same client are always sent to the same upstream server or group of servers:

# Configuration Example

proxy:
  retries: -1
  upstream:
  - cluster_type: http
    cluster_name: app_upstream_name1
  - cluster_type: http
    cluster_name: app_upstream_name2
  backup_upstream:
  - cluster_type: http_k8s
    cluster_name: app_k8s_upstream_name2
  balancer:
    algorithm: roundrobin
  upstream_el_code: ''
  connect_timeout: 6
  sticky:
    enable: true
    mode: none
    ttl: 1
    key: Edge-Sticky
    level: upstream
  retry_condition:
  - error
  - timeout
  - invalid_header
  - http_500
  - http_502
  - http_504
  send_timeout: 6
  read_timeout: 6

This configuration defines a proxy rule using two HTTP upstream servers as primary servers and one Kubernetes upstream server as a backup. It uses a round-robin algorithm for load balancing, enables session persistence, and sets various timeouts and retry conditions.

# Notes

1. cluster_type can be “http”, “http_k8s”, “global”, or “global_k8s”, corresponding to application HTTP upstream, application Kubernetes upstream, global HTTP upstream, and global Kubernetes upstream respectively.

2. cluster_name must match the previously defined upstream name.

3. When retries is set to -1, it indicates retrying based on the number of gateway servers in the upstream.

4. The sticky configuration allows you to implement session persistence, ensuring requests from the same client are always sent to the same upstream server.

5. retry_condition lists the conditions triggering a retry, including errors and specific HTTP status codes.

6. Timeout settings (connect_timeout, send_timeout, read_timeout) are in seconds.

7. upstream_el_code allows you to use EdgeLang code to dynamically select upstream servers, which is not used in this example (empty string).

# Related Documents

• Application Upstreams
• Global Upstreams
• Application Kubernetes Upstreams
• Global Kubernetes Upstreams