CDN Proxy
Proxy rules can be configured to route traffic back to your origin server(s) while maintaining a cache in our edge content delivery network.
This is effectively a traditional CDN, however there are many additional options available such as static failover, header overrides, alert injection, image optimization, and web-application firewall.
Configuration overview
Section titled “Configuration overview”
- Proxy address: is your backend/origin server. This may be a FQDN or IP address and should include the protocol.
- Host header: should be a valid Host header to send to the origin server.
- Basic authentication: provide a username and password if the origin server is protected by basic authentication.
- Cache lifetime: optionally override the cache lifetime of the proxied response in Quant. Leave blank to inherit the cache headers sent by your backend server.
- Disable TLS verification: may be used if the server is using a self-signed (or other invalid) certificate.
- Only on 404: will serve from the Quant static edge if content exists, else proxy.
- Failover mode: will serve from the Quant static offload only if the origin server shows sign of duress, or returns an unexpected response. More detail below.
- Include injected alert: allows you to alter the markup response and include the sitewide alert banner. This can be useful to allow widespread alert messaging to be presented to end users without the need for application-level change.
You may use the wildcard captures in your proxies, simply include a capture value in the proxy address. For example: a match on /api/* with a proxy address: https://api.example.com/v1/$1.
The proxy address is used exactly as written. Quant does not add the request path for you, so https://origin.example.com sends every matched request to the origin’s /. To keep the request path, use https://origin.example.com$*. The query string is added automatically. See wildcard matches and captures.
Settings in detail
Section titled “Settings in detail”| Setting (API field) | Behaviour |
|---|---|
Host header (host) |
Sent to the origin. When empty, the visitor’s host name is sent |
Cache lifetime (cache_lifetime) |
A string, in seconds. Empty or -1: the origin’s Cache-Control header is kept. "0": Quant sets Cache-Control: no-store, so nothing is cached. A positive value such as "600": Quant sets Cache-Control: public, max-age=600 |
Origin timeout (origin_timeout) |
A string, in milliseconds. When unset, 30 seconds. "90" means 90 ms; use "90000" for 90 seconds |
Only on 404 (only_proxy_404) |
Quant serves its static content when the path exists, and proxies only when it does not. Proxied responses carry the header quant-404-proxied: true |
Request headers (inject_headers) |
Added to the request sent to the origin |
Strip headers (proxy_strip_headers, proxy_strip_request_headers) |
Removed from the response, or from the request sent to the origin |
Origin errors and the 502 Proxy Error page
Section titled “Origin errors and the 502 Proxy Error page”If the origin does not answer within the origin timeout, or the connection fails, Quant returns its own 502 page with the title Proxy Error and the text “An error occurred when communicating with a backend origin service.” This page comes from Quant, not from your origin.
- A request that timed out is not retried.
- After repeated failures in a short time, Quant returns the
502for a short cool-down period without contacting the origin. - To show your own page, enable “Use static error pages” on the proxy rule, list
502, and publish a page at_quant502(see custom error pages).
Failover mode
Section titled “Failover mode”
When failover mode is enabled Quant is configured as a static failover service. In this mode, requests will be proxied back to your origin server unless signs of distress are detected.
For example, if your origin server takes more than 10 seconds to return a response, or returns an unexpected status code.
In this mode you may receive notifications when a failover mode is triggered. You may also specify a failover cache lifetime, which will ensure traffic is kept away from your origin server for a defined period.
Request headers
Section titled “Request headers”You may optionally inject extra request headers to your origin server. This is useful to provide an extra layer of security, e.g: pass a shared key back to your origin server to protect direct origin server access.
You may also optionally strip response headers. This is useful to exclude certain origin headers from the response sent back to your end users. For example, this may be useful for excluding headers that contain mention of versions of software running on your origin server to improve security posture.
