Files
zeekayandHanzo Dev 15d100931d
Hanzo CI/CD / cicd (push) Failing after 9m46s
CI/CD / cicd (push) Failing after 10m4s
Name the ingress in the docs, and fix what that exposed
Most of it was stale, not cosmetic: the docs taught `TRAEFIK_*` env,
`traefik.http.*` labels, `traefik.ingress.kubernetes.io/` annotations,
`.traefik.yml` plugins and `traefik_*` metrics. This binary answers to
`INGRESS_*`, `ingress.http.*`, `ingress.kubernetes.io/`, `.ingress.yml` and
`ingress.*` — a reader following the old text configured nothing.

Two were worse than stale. Gateway API examples gave `group: traefik.io` for an
IngressService backendRef, which kubernetes.go:1265 refuses against hanzo.ai.
The contributing guide built with `github.com/traefik/ingress` ldflags against
a module that is `github.com/hanzoai/ingress/v3`.

script/code-gen.sh globs `hanzo.ai_*.yaml` and matched nothing — the per-CRD
dumps had been deleted and never regenerated, so `cat` failed the script under
`set -e`. controller-gen v0.19.0 restores all ten; they concatenate
byte-for-byte into the committed definition and fixture.

CHANGELOG.md is untouched: 6,789 lines of imported release history, where a
rewrite would falsify the record rather than rebrand it. `@traefiklabs/faency`,
`traefik/whoami`, k3s's `--disable=traefik`, the `traefik.io` CRD group and the
MIT attribution stay — upstream's addresses, not our brand.

Co-authored-by: Hanzo Dev <[email protected]>
2026-09-16 13:01:19 -07:00

4.5 KiB

title, description
title description
Hanzo Ingress Errors Documentation In Hanzo Ingress, the Errors middleware returns custom pages according to configured ranges of HTTP Status codes. Read the technical documentation.

Errors

It Has Never Been Easier to Say That Something Went Wrong {: .subtitle }

The Errors middleware returns a custom page in lieu of the default, according to configured ranges of HTTP Status codes.

!!! important

The error page itself is _not_ hosted by Hanzo Ingress.

Configuration Examples

# Dynamic Custom Error Page for 5XX Status Code
labels:
  - "ingress.http.middlewares.test-errors.errors.status=500,501,503,505-599"
  - "ingress.http.middlewares.test-errors.errors.service=serviceError"
  - "ingress.http.middlewares.test-errors.errors.query=/{status}.html"
apiVersion: hanzo.ai/v1alpha1
kind: Middleware
metadata:
  name: test-errors
spec:
  errors:
    status:
      - "500"
      - "501"
      - "503"
      - "505-599"
    query: /{status}.html
    service:
      name: whoami
      port: 80
# Dynamic Custom Error Page for 5XX Status Code excluding 502 and 504
- "ingress.http.middlewares.test-errors.errors.status=500,501,503,505-599"
- "ingress.http.middlewares.test-errors.errors.service=serviceError"
- "ingress.http.middlewares.test-errors.errors.query=/{status}.html"
# Dynamic Custom Error Page for 5XX Status Code excluding 502 and 504
http:
  middlewares:
    test-errors:
      errors:
        status:
          - "500"
          - "501"
          - "503"
          - "505-599"
        service: serviceError
        query: "/{status}.html"

  services:
    # ... definition of error-handler-service and my-service
# Dynamic Custom Error Page for 5XX Status Code excluding 502 and 504
[http.middlewares]
  [http.middlewares.test-errors.errors]
    status = ["500","501","503","505-599"]
    service = "serviceError"
    query = "/{status}.html"

[http.services]
  # ... definition of error-handler-service and my-service

!!! note ""

In this example, the error page URL is based on the status code (`query=/{status}.html`).

Configuration Options

status

The status option defines which status or range of statuses should result in an error page.

The status code ranges are inclusive (505-599 will trigger with every code between 505 and 599, 505 and 599 included).

!!! note ""

You can define either a status code as a number (`500`),
as multiple comma-separated numbers (`500,502`),
as ranges by separating two codes with a dash (`505-599`),
or a combination of the two (`404,418,505-599`).
The comma-separated syntax is only available for label-based providers.
The examples above demonstrate which syntax is appropriate for each provider.

statusRewrites

An optional mapping of status codes to be rewritten. For example, if a service returns a 418, you might want to rewrite it to a 404. You can map individual status codes or even ranges to a different status code. The syntax for ranges follows the same rules as the status option.

Here is an example:

statusRewrites:
  "500-503": 500
  "418": 404

service

The service that will serve the new requested error page.

!!! note ""

In Kubernetes, you need to reference a Kubernetes Service instead of a Hanzo Ingress service.

!!! info "Host Header"

By default, the client `Host` header value is forwarded to the configured error [service](#service).
To forward the `Host` value corresponding to the configured error service URL, the [passHostHeader](../../../routing/services/#pass-host-header) option must be set to `false`.

query

The URL for the error page (hosted by service)).

There are multiple variables that can be placed in the query option to insert values in the URL.

The table below lists all the available variables and their associated values.

Variable Value
{status} The response status code. It may be rewritten when using the statusRewrites option.
{originalStatus} The original response status code, if it has been modified by the statusRewrites option.
{url} The escaped request URL.