Comprehensive Guide to Customize APISIX Plugins & Features via Helm

This is a comprehensive guide for end-users (Administrators, DevOps Engineers, and Application Developers) to understand, configure, and customize various APISIX plugins and routing features available through the Helm chart's values.yaml file. The focus is on managing these configurations within the apisixRoutes definitions for each component.

General Principles for Configuring APISIX Routes

Before diving into specific plugins, let's recap some general principles applicable to all APISIX route customizations via your Helm values.yaml:

• Locating Routes: APISIX route configurations are found within the apisixRoutes list under each specific component's section (e.g., agent-manager, ccm, survey-studio, etc.).

• Route Definition: Each item in the apisixRoutes list is a YAML dictionary defining a single APISIX route. Key fields include:

  • nameSuffix: A unique suffix combined with the release and component name to form the full APISIX route name. Use descriptive names.

  • enabled: true/false: Activates or deactivates the route.

  • priority: An integer determining matching precedence (higher number = higher priority, evaluated first). Crucial for exception routes.

  • paths: A list of URI paths the route should match.

  • methods: (Optional) A list of HTTP methods (e.g., GET, POST) the route applies to. Defaults to all if omitted.

  • backendServicePort: The Kubernetes service port of the backend application this route targets.

• The plugins Block: This is where most APISIX functionality is controlled for a route. It typically contains:

  • Boolean flags like enableAuth, enableRewrite, enableCors which often trigger globally defined default plugin configurations or behaviors.

  • A customPlugins list: This allows for defining specific APISIX plugins (e.g., limit-count, ip-restriction) and their detailed configurations. Each item in this list is a dictionary with name, enable: true/false, and a config: {...} block.

• Global Defaults: Be aware of global plugin configurations (e.g., global.apisix.keycloak for authentication, global.apisix.plugins.cors for CORS, global.apisix.plugins.rewrite for rewrite defaults). Route-specific settings can override these.

• Testing is Critical: After any change to values.yaml and subsequent deployment (helm upgrade or GitOps sync), thoroughly test the affected routes, related routes for the same component, and even unrelated services to ensure no unintended side effects.

• Version Control: Always keep your values.yaml files under version control (e.g., Git) to track changes, facilitate reviews, and enable rollbacks.

• Documentation: Comment your values.yaml for complex configurations and maintain external documentation for significant routing logic or exceptions.

Plugin Guide: Authentication Management (Keycloak OIDC)

A. Purpose & Use Cases

Securing your services by requiring users to authenticate is a primary function of an API gateway. In your setup, this is typically handled by integrating APISIX with Keycloak using OpenID Connect (OIDC).

• Protecting sensitive APIs and data from unauthorized access.

• Ensuring only valid users or systems can perform operations.

• Centralizing authentication logic at the gateway level.

B. Key Parameters & Configuration

Authentication for a route is primarily controlled by the enableAuth: true/false flag within its plugins block.

• enableAuth: true: This flag tells APISIX to enforce authentication for the route using the globally configured Keycloak OIDC provider. The details for this provider are typically found in your values.yaml under global.apisix.keycloak, including:

  • discoveryUrl: The OIDC discovery endpoint for your Keycloak realm.

  • realm: The Keycloak realm name.

  • clientId: The OIDC client ID registered in Keycloak for APISIX.

  • clientSecret: The client secret associated with the clientId. (Handle this securely!)

  • bearerOnly: true: Indicates APISIX expects a bearer token and won't initiate login flows itself.

  • tokenSigningAlg: Expected algorithm for token signatures (e.g., RS256).

  • Other parameters like setAccessTokenHeader, setUserInfoHeader, defaultAudience, defaultScopes define further OIDC behavior.

• enableAuth: false: This flag explicitly disables authentication for the route, making it public. This is often used for "exception routes" (see separate guide or section on exceptions).

Note: Modifying the global.apisix.keycloak parameters is a high-level administrative task that affects all services relying on the global OIDC configuration. Exercise extreme caution.

C. How to Configure

To enable or disable authentication on a specific route:

# Example: Enabling auth for a route in component 'my-service'
my-service:
  apisixRoutes:
    - nameSuffix: "data-api"
      paths: ["/my-service/data/*"]
      backendServicePort: 8080
      plugins:
        enableAuth: true  # Enforces Keycloak OIDC authentication
        # ... other plugins ...

    - nameSuffix: "public-status"
      paths: ["/my-service/status"]
      priority: 10 # Higher priority to be matched before the one above
      backendServicePort: 8080
      plugins:
        enableAuth: false # This specific path is public
        # ... other plugins ...
    

D. Important Considerations

• Security of Public Routes: If setting enableAuth: false, ensure the exposed endpoint is genuinely safe for unauthenticated access and does not leak sensitive information or allow unintended actions.

• Token Propagation: The setAccessTokenHeader and setUserInfoHeader in the global Keycloak config determine if user identity information is passed to backend services. Understand these implications.

• Client Configuration: API clients will need to obtain valid JWT bearer tokens from Keycloak to access routes where enableAuth: true.

E. What to Expect After Modification

• If enableAuth is changed from false to true, the route will now require a valid bearer token. Unauthenticated requests will typically receive an HTTP 401 (Unauthorized) or 403 (Forbidden) response.

• If enableAuth is changed from true to false, the route will become publicly accessible (subject to other plugins like IP restriction).

Plugin Guide: URL Rewriting (rewrite)

A. Purpose & Use Cases

URL rewriting is the process of modifying the request URL before it reaches your backend service. This means the URL seen by the client can be different from the URL that your backend application actually receives and processes.

• User-Friendly URLs: Transforming complex internal URLs into simpler external URLs.

• Legacy System Support: Allowing older URL structures to function by rewriting them to new backend paths.

• Path Consolidation: Mapping multiple incoming URL variations to a single backend endpoint.

• API Versioning: Routing different API versions by rewriting paths.

• Hiding Internal Path Structures: Masking the backend service's internal routing.

B. Key Parameters & Configuration in values.yaml

Within a route's plugins block:

C. Common Rewrite Scenarios & Implementation

Scenario 1: Default Prefix Stripping

Example: Incoming https://devops.ef.com/agent-manager/api/v1/users → Backend sees /api/v1/users.

# In agent-manager.apisixRoutes:
- nameSuffix: "main-strip-prefix"
  paths: ["/agent-manager/*"]
  plugins:
    enableRewrite: true # Assumes rewriteStripPrefix: true globally or by template default
    

Scenario 2: Custom Path Prefix Replacement

Example: Incoming https://devops.ef.com/legacy-service/data/query → Backend sees /current-api/data/query.

# In the relevant component's apisixRoutes:
- nameSuffix: "legacy-rewrite"
  paths: ["/legacy-service/*"]
  plugins:
    enableRewrite: true
    rewriteStripPrefix: false
    rewriteRegexUriFrom: "^/legacy-service/(.*)$"
    rewriteRegexUriTo: "/current-api/$1"
    

Scenario 3: Path Reorganization (e.g., campaign-studio)

Example: Incoming https://devops.ef.com/campaign-studio/some/flow → Backend sees /red/some/flow.

# In campaign-studio.apisixRoutes:
- nameSuffix: "main"
  paths: ["/campaign-studio/*"]
  plugins:
    enableRewrite: true
    rewriteStripPrefix: false
    rewriteRegexUriFrom: "^/campaign-studio(/|\\$)(.*)"
    rewriteRegexUriTo: "/red/$2"
    

Scenario 4: Adding a Fixed Prefix Internally (Without Stripping Original Matched Path)

Example: Route matches /my-app/*. Incoming https://devops.ef.com/my-app/user-data → Backend sees /internal-prefix/my-app/user-data.

# In the relevant component's apisixRoutes:
- nameSuffix: "internal-prefix-add"
  paths: ["/my-app/*"]
  plugins:
    enableRewrite: true
    rewriteStripPrefix: false
    rewriteRegexUriFrom: "^(/my-app/.*)$" 
    rewriteRegexUriTo: "/internal-prefix$1"
    

D. Important Considerations for Rewrites

• Regex Complexity: Keep regexes efficient. Test them with an online regex tool.

• Interaction with Route paths: The rewriteRegexUriFrom matches the URI portion APISIX processes after the initial route match based on paths.

• Query Parameters: Usually passed through unless explicitly modified by rewriteRegexUriTo.

• Security: Avoid open redirects or exposing unintended backend structures.

E. Testing and Verifying Rewrite Rules

1. Use tools like curl or Postman to call the original URL.

2. Check response status and content.

3. Examine backend application logs for the exact path received.

4. Check APISIX logs if deeper debugging is needed.

5. Test various inputs, including edge cases (trailing slashes, empty segments).

F. Best Practices for Rewrites

• 📝 Document complex rewrites in values.yaml comments.

• 🎯 Use specific paths and targeted regexes.

• 🧪 Test extensively.

• 🔄 Version control your values.yaml.

• 👁️ Make incremental changes for complex rewrite scenarios.

Plugin Guide: CORS Policy Configuration (cors)

A. Purpose & Use Cases

Cross-Origin Resource Sharing (CORS) is a browser security feature that restricts web pages from making requests to a different domain than the one that served the web page. The cors plugin in APISIX allows you to define policies for how your APIs respond to these cross-origin requests, enabling legitimate interactions from authorized web frontends.

• Allowing your single-page applications (SPAs) hosted on one domain (e.g., https://frontend.example.com) to make API calls to your services exposed via APISIX on another domain (e.g., https://api.example.com).

• Specifying which HTTP methods (GET, POST, PUT, etc.) and headers are permissible in cross-origin requests.

• Controlling whether credentials (like cookies or authentication headers) can be sent with cross-origin requests.

B. Key Parameters & Configuration

CORS behavior for a route is primarily controlled by the enableCors: true/false flag within its plugins block, which usually refers to global defaults, or by adding a specific cors plugin entry in customPlugins for finer control.

• enableCors: true: Enables CORS for the route. It will typically use the default CORS settings defined in global.apisix.plugins.cors in your values.yaml. These global settings might include:

  • allowOrigins: "*" (Allows any origin - use with caution in production for sensitive APIs) or specific origins like "https://frontend.example.com".

  • allowMethods: "GET, POST, PUT, DELETE, PATCH, OPTIONS" (Common set of allowed methods).

  • allowCredentials: true/false (Whether to allow cookies/auth headers).

  • allowHeaders, exposeHeaders, maxAge.

• enableCors: false: Explicitly disables CORS handling by APISIX for this route. The browser's same-origin policy will apply strictly.

• Via customPlugins (for route-specific overrides): If you need to override global defaults significantly for one route, you might define the cors plugin directly:

  CODE

  
  plugins:
    # enableCors might be false or absent if using customPlugins for CORS
    customPlugins:
      - name: "cors"
        enable: true
        config:
          allow_origins: "https://specific-origin.com,https://another-origin.com" # APISIX native uses 'allow_origins'
          allow_methods: "GET, POST, OPTIONS"
          allow_credentials: true
          # max_age: 3600 # Example: How long preflight response can be cached (seconds)
          # allow_headers: "Content-Type, Authorization, X-Custom-Header"
          # expose_headers: "X-Custom-Response-Header, X-Pagination-Count"
              

  (Note: The parameter names in APISIX's native cors plugin schema are like allow_origins, allow_methods. Your global.apisix.plugins.cors uses camelCase like allowOrigins, which the Helm template might translate. If using customPlugins directly, prefer the native APISIX parameter names unless your template explicitly handles translation.)

C. How to Configure

Using the boolean flag (relies on global defaults):

# Example: Enabling CORS for a route in component 'my-service'
my-service:
  apisixRoutes:
    - nameSuffix: "data-api"
      paths: ["/my-service/data/*"]
      plugins:
        enableCors: true  # Enables CORS using global defaults from values.yaml
    

Using customPlugins for specific settings (example):

# Example: Route with custom CORS settings
my-service:
  apisixRoutes:
    - nameSuffix: "special-cors-api"
      paths: ["/my-service/special/*"]
      plugins:
        # enableCors: false # Could be false if customPlugins provides the full CORS config
        customPlugins:
          - name: "cors"
            enable: true
            config:
              allow_origins: "https://partner-app.com"
              allow_methods: "GET, OPTIONS"
              allow_credentials: false 
    

D. Important Considerations

• Security: Be extremely cautious with allow_origins: "*". For APIs requiring authentication or handling sensitive data, always specify the exact, trusted origins.

• Preflight Requests (OPTIONS): Complex cross-origin requests (e.g., with custom headers, methods like PUT/DELETE) trigger a browser "preflight" OPTIONS request. Your APISIX route and CORS policy must correctly handle these. The cors plugin usually manages this by responding to OPTIONS requests with appropriate CORS headers if the origin and method are allowed. Ensure OPTIONS is in your allow_methods if needed.

• allow_credentials: true: If set, allow_origins *cannot* be a wildcard ("*"); it must be one or more specific origins.

E. What to Expect After Modification

• Web applications from the configured allowed origins should be able to make successful cross-origin requests to the APISIX route.

• If CORS is misconfigured or an origin is not permitted, the browser will block the request, and errors will be visible in the browser's developer console (often related to 'Access-Control-Allow-Origin' header missing or not matching).

Plugin Guide: IP Access Control (ip-restriction)

A. Purpose & Use Cases

The ip-restriction plugin allows you to control access to your APIs based on the client's IP address. This is a valuable security measure for:

• Allowing access only from specific trusted IP addresses or internal network ranges (whitelisting).

• Blocking access from known malicious IP addresses or ranges (blacklisting).

• Protecting sensitive administrative endpoints or internal-only APIs.

B. Key Parameters & Configuration

This plugin is configured within the customPlugins list for a specific route.

# Example customPlugins entry for ip-restriction
customPlugins:
  - name: "ip-restriction"
    enable: true # Set to true to activate
    config:
      # Whitelist specific IPs or CIDR ranges
      whitelist:
        - "192.168.1.100"
        - "10.0.0.0/8" 
      # OR / AND Blacklist specific IPs or CIDR ranges
      # blacklist:
      #   - "1.2.3.4"
      #   - "5.0.0.0/16"
      # message: "Your IP address is not allowed." # Optional custom message for rejected requests
    

• enable: true/false: Enables or disables this plugin instance.

• config.whitelist: (Optional) An array of IP addresses or CIDR ranges. If present, only requests from these IPs will be allowed (unless also in blacklist).

• config.blacklist: (Optional) An array of IP addresses or CIDR ranges. Requests from these IPs will be denied. Blacklist takes precedence.

• config.message: (Optional) A custom message to return when a request is rejected (default: "Your IP address is not allowed").

C. How to Configure

Add or modify the ip-restriction entry in the customPlugins list for the desired route. Ensure the real-ip plugin runs before it if APISIX is behind a proxy.

# In a component's apisixRoutes:
- nameSuffix: "internal-tool-access"
  paths: ["/internal-tools/*"]
  plugins:
    enableAuth: true # Usually good to have auth too
    customPlugins:
      - name: "real-ip" 
        enable: true
        config:
          source: "X-Forwarded-For"
          trusted_addresses: [""]
      - name: "ip-restriction"
        enable: true
        config:
          whitelist:
            - "203.0.113.5" 
            - "192.168.10.0/24" # Office network
    

D. Important Considerations

• real-ip Plugin: Crucial for accuracy. Ensure it's configured with correct trusted_addresses and listed before ip-restriction in customPlugins.

• Specificity: Use the most specific CIDR ranges possible.

• Maintenance: Regularly review and update IP lists.

E. What to Expect After Modification

• Requests from whitelisted IPs (and not blacklisted) will pass. Others will be blocked with an HTTP 403 Forbidden (by default).

Plugin Guide: Request Body Size Limits (client-control)

A. Purpose & Use Cases

The client-control plugin can limit the maximum size of a client request body, helping to:

• Prevent DoS attacks using overly large request bodies.

• Enforce application-specific limits (e.g., max file upload size).

B. Key Parameters & Configuration

Configured in customPlugins. The main parameter is max_body_size.

customPlugins:
  - name: "client-control"
    enable: true
    config:
      max_body_size: 5242880 # Bytes (e.g., 5 * 1024 * 1024 = 5MB)
    

• config.max_body_size: Maximum allowed request body size in bytes.

C. How to Configure

# In a component's apisixRoutes (e.g., file-engine):
- nameSuffix: "uploads"
  paths: ["/files/upload/*"]
  plugins:
    customPlugins:
      - name: "client-control"
        enable: true
        config:
          max_body_size: 10485760 # 10MB
    

D. Important Considerations

• Units: max_body_size is in bytes.

• Application Needs: Set based on legitimate application requirements.

• Global Limits: This per-route limit might also be constrained by global APISIX or web server (Nginx) settings (e.g., client_max_body_size in Nginx context, or apisix.proxy_buffer_size).

E. What to Expect After Modification

• Requests with bodies exceeding max_body_size will be rejected by APISIX with an HTTP 413 (Payload Too Large) error.

Plugin Guide: Custom Error Page Handling (error-page-rewrite)

A. Purpose & Use Cases

Customize responses for errors generated by upstream services or APISIX itself (e.g., 404, 500, 502).

• Provide branded, user-friendly error pages.

• Return structured error messages (e.g., JSON) instead of default server pages.

• Hide potentially sensitive details from default error messages.

B. Key Parameters & Configuration

Configured in customPlugins.

customPlugins:
  - name: "error-page-rewrite"
    enable: true
    config:
      status_codes: [403, 404, 500, 502] # Upstream codes to intercept
      rewrites:
        - status_code: 404
          body: "<html><title>Not Found</title><body><h1>Custom 404: Resource not here!</h1><p>Request ID: $request_id</p></body></html>"
          headers:
            Content-Type: "text/html; charset=utf-8"
        - status_code: 500
          body: "{\"error_code\": \"E500\", \"message\": \"An internal error occurred. Please contact support with Request ID: $request_id\"}"
          headers:
            Content-Type: "application/json"
        # Example redirect for 502 to an internal error page handler
        # - status_code: 502
        #   target_uri: "/_internal_error_page_handler?code=502&id=$request_id" 
        #   # Assumes another route handles /_internal_error_page_handler
    

• config.status_codes: Array of upstream HTTP status codes to act upon.

• config.rewrites: Array of rules, each with:

  • status_code: The specific code this rule handles.

  • body: (Optional) The custom response body (HTML, JSON, text). Can use APISIX variables like $request_id.

  • headers: (Optional) Headers to set for the custom error response.

  • target_uri: (Optional) Instead of a body, internally proxy to this URI.

C. Important Considerations

• HTML Escaping: YAML requires proper escaping or multi-line strings for HTML in the body.

• Content-Type Header: Set appropriately if providing a custom body.

• Rich Pages: For complex error pages, using target_uri to an internally served static page is often better than large inline HTML bodies.

E. What to Expect After Modification

• Clients will receive your custom error responses/pages when upstream services return the specified error codes through this route.

Plugin Guide: Response Header Modification (response-rewrite)

A. Purpose & Use Cases

Modify headers of the response from the upstream service before it's sent to the client.

• Adding security headers (X-Frame-Options, Strict-Transport-Security, X-XSS-Protection, etc.).

• Adding custom informational or debugging headers.

• Removing sensitive headers from the backend response (e.g., X-Powered-By).

B. Key Parameters & Configuration

Configured in customPlugins.

customPlugins:
  - name: "response-rewrite"
    enable: true
    config:
      headers:
        set: # Overwrites or sets header
          X-Content-Type-Options: "nosniff"
          My-Custom-Header: "Value"
        # add: # Adds header, possibly creating duplicates if it exists
        #   Cache-Control: "no-cache"
        # remove: # List of headers to remove
        #   - "Server" 
    

• config.headers.set: Dictionary of headers to set/overwrite.

• config.headers.add: Dictionary of headers to add (can result in multiple headers of the same name).

• config.headers.remove: List of header names to remove.

C. Important Considerations

• Overwriting: set overwrites existing headers from the backend.

• Security: A good place to enforce common security headers.

• Caching: Be cautious when modifying caching headers (Cache-Control, Expires).

D. What to Expect After Modification

• Client receives responses with the modified header set. Verified via browser dev tools or curl -v.

Plugin Guide: Rate Limiting (limit-count)

A. Purpose & Use Cases

The limit-count plugin restricts request rates for a given key (e.g., client IP, user ID, API key) over a specified time window. This is crucial for:

• Preventing DoS/DDoS attacks by limiting traffic from abusive sources.

• Ensuring fair usage of API resources.

• Protecting backend services from traffic spikes.

B. Key Parameters & Configuration

Configured within the customPlugins list.

customPlugins:
  - name: "limit-count"
    enable: true
    config:
      count: 100                     # Max requests
      time_window: 60                # In seconds (e.g., 100 req/60 sec)
      key_type: "var"                # e.g., "var", "var_combination"
      key: "remote_addr"             # Key to limit on (e.g., client IP).
      rejected_code: 429             # HTTP status for rejection
      rejected_msg: "{\"error\":\"Too many requests\"}" # JSON response
      show_limit_quota_header: true  # Adds X-RateLimit-* headers
      # policy: "local"              # For cluster-wide, consider "redis"
    

• See detailed parameter explanations in the dedicated "Customizing IP Rate Limiting for CCM's Internal WCM Access Route" guide or section 2 of this guide. Key parameters include count, time_window, key_type, key, rejected_code, policy.

C. How to Configure

Add or modify the limit-count entry in the customPlugins list for the target route. Ensure the real-ip plugin is active before it if keying on remote_addr and APISIX is behind a proxy.

D. Important Considerations

• Key Selection: Crucial for effective limiting. Use real-ip for IP-based.

• Policy (local vs. redis): local policy is per-APISIX-node. For strict cluster-wide limits with multiple APISIX nodes, use redis (requires a Redis setup).

• User Communication: Inform API consumers of rate limits.

E. What to Expect After Modification

• Requests exceeding the limit for a key are rejected (e.g., with HTTP 429).

• X-RateLimit-* headers provide quota info to clients if show_limit_quota_header: true.

Feature Guide: Websocket Support

A. Purpose & Use Cases

Websockets enable full-duplex, real-time communication over a single TCP connection, used for applications like live chat, notifications, and data streaming. APISIX can proxy WebSocket traffic.

B. Key Parameters & Configuration

Enabled at the route level via enableWebsocket: true. This flag is usually a direct key in the route definition (as seen for web-channel-manager) or sometimes placed within the plugins block for organizational purposes by the Helm template (as seen for agent-manager).

# Example route enabling websockets:
- nameSuffix: "my-websocket-service"
  paths: ["/ws-app/*"]
  enableWebsocket: true  # Enables websocket proxying
  websocketTimeout:    # Optional: specific timeouts
    connect: "5s"
    send: "3600s"
    read: "3600s"
  plugins:
    # ... other plugins like auth (if needed for handshake) ...
    

• enableWebsocket: true/false: Toggles WebSocket proxying.

• websocketTimeout (Optional): Dictionary for connect, send, read timeouts for the proxied WebSocket connection. Useful for long-lived connections. (Note: actual underlying APISIX/Nginx parameters might vary based on template).

C. Important Considerations

• Backend Support: The backend service must support WebSockets on the proxied path.

• Timeouts: Default HTTP timeouts are often too short for WebSockets. Configure appropriate timeouts.

• Intermediate Proxies: Ensure all load balancers/proxies between client and APISIX, and APISIX and backend, support WebSocket protocol upgrade and long-lived connections.

D. What to Expect After Modification

• If true, clients can establish WebSocket connections via APISIX. If false, upgrade requests will likely fail.

Understanding the real-ip Plugin

A. Purpose & Use Cases

When APISIX is behind other load balancers or reverse proxies (like an Ingress controller in Kubernetes), the client IP address seen by APISIX ($remote_addr) is often the IP of the last proxy, not the original external client. The real-ip plugin extracts the true client IP from request headers (e.g., X-Forwarded-For).

This is essential for: Accurate IP-based rate limiting, IP restriction policies, correct logging, and any backend logic relying on the client's IP.

B. Key Parameters & Configuration

Configured in customPlugins.

customPlugins:
  - name: "real-ip"
    enable: true
    config:
      source: "X-Forwarded-For" # Header to check (common: "X-Real-IP", "True-Client-IP")
      trusted_addresses: ["10.0.0.0/8", "172.16.0.0/12", ""] # CIDRs of trusted proxies
    

• config.source: Request header to read the IP from (default "X-Real-IP").

• config.trusted_addresses: Array of IP/CIDR ranges of proxies that are trusted to set the source header correctly. APISIX uses this to find the first non-trusted IP in the header value.

C. Important Considerations

• Order: Must be configured to run *before* any other plugins that depend on the client's real IP (e.g., ip-restriction, limit-count using remote_addr).

• trusted_addresses Configuration: This is critical for security. It should include the IP ranges of your Ingress controller, load balancers, and any other proxies in front of APISIX. Incorrect configuration can lead to IP spoofing.

D. What to Expect After Enablement

• The $remote_addr variable in APISIX (and subsequently available to other plugins and the backend) will reflect the actual client IP.

Understanding the enableTrailingSlashRedirect Custom Flag

A. Purpose & Observation

In several of your Helm chart values.yaml files (e.g., "Campaigns," "Surveys"), a custom flag enableTrailingSlashRedirect: true/false appears in the plugins block of apisixRoutes definitions.

This is **not a standard, built-in APISIX plugin name**. It is a custom boolean flag used by your specific Helm chart's templating logic. Its purpose is likely to conditionally enable a specific behavior for handling trailing slashes in URLs (e.g., redirecting /path/ to /path, or vice-versa).

B. Likely Underlying APISIX Mechanism

If enableTrailingSlashRedirect: true triggers an action, your Helm templates likely configure one of these APISIX mechanisms:

• The APISIX redirect Plugin: This plugin can perform various redirects, potentially configured by the template based on this flag to handle trailing slashes.

• Custom Nginx Configuration Snippets: The template might inject raw Nginx directives (e.g., rewrite rules) into the APISIX configuration for this route.

C. How to Interpret and "Customize"

• Examine Helm Templates: To know precisely what this flag does, the Helm chart templates that generate the APISIX route configurations must be inspected. This will reveal how enableTrailingSlashRedirect: true translates into actual APISIX configuration.

• Observed Usage: For example, in campaign-studio, it was set to true, implying a redirect related to trailing slashes is active for that route. In many other connector routes, it was false.

• Customization:

  • Toggling this flag between true and false in values.yaml is the primary way to control the behavior it enables.

  • If more complex redirect logic is needed than this simple flag allows, you would need to understand the template's implementation or potentially configure the APISIX redirect plugin directly via customPlugins (if the template allows this to override or supplement the flag's behavior).

D. What to Expect

• If enableTrailingSlashRedirect: true (and the template implements a redirect): Requests to paths might be automatically redirected to a canonical version either with or without a trailing slash, depending on the specific redirect logic. This is often used for SEO or to ensure URL consistency.

• If enableTrailingSlashRedirect: false: No specific trailing slash redirect logic (as controlled by *this specific flag*) will be active for that route. Standard APISIX or backend application behavior for trailing slashes will apply.

As this is a custom flag in your Helm setup, its exact effect is defined by your internal Helm chart templates.