There are a number of advanced HTTP options provided for rarely used but quite useful use cases. Most people should not need these configuration options. The configuration for these settings can be found on the HTTP action link from the Proxy Port page.

Allowed Methods

The list of methods that will be forwarded to the backend server. Reasonable defaults have been provided for you.

You may chose from:

  • GET
  • POST
  • HEAD
  • PUT
  • DELETE
  • OPTIONS
  • PATCH

Backend SNI & Pooling

If your backend server is using HTTPS you may need to configure the Backend SNI option in the HTTP Options section of the port configuration. This is required if your backend server uses SNI to determine which certificate to present (for example if you are hosting multiple HTTPS websites on a single IP address). If your backend server does not validate Host name headers and their match to SNI names then you can disable this for a slight performance increase for services with many domain/subdomain names on a single backend.

Our default is to enable this option for compatibility with Apache 2 (for more information see the Website Setup page) which as of version 2.4.65+ enforces SNI matching on HTTPS connections.

The modes available for this setting are:

  • Disabled: Do not send SNI information to the backend server. This is the default for HTTP (only) backends.
  • Send SNI (HTTPS backend only): Send SNI information matching the Host header to the backend server but allow future requests to any domain name configured on the port to be sent to the backend server. This is useful if your webserver validates on the first request to match the SNI name to the Host header but you have many domain names on a single backend IP as it allows your pool of backend connections to be reused for all domain names.
  • SNI Pool/Pool: Send SNI information matching the Host header to the backend server and only allow future requests to the same domain name to be sent to the backend server over that connection. This is useful if your webserver validates on every request to match the SNI name to the Host header but you have many domain names on a single backend IP as it allows your pool of backend connections to be reused for all domain names. This is the default for HTTPS backends and required for Apache 2.4.65+ compatibility.

On HTTP backends a "Pool" mode which can optionally be enabled for a similar Host based pooling effect. But this is not required for compatibility with any known common web server. In the case of that configuration connections (keepalive) will be reused only for requests to the same Host header (the same as SNI Pool, but without SNI). This is not recommended unless you have a specific need for it as it reduces the effectiveness of connection reuse.

Real IP Headers

A Real IP Header (aka Forwarded-For header) allows for upstream proxies to send along the IP address of connecting clients to the next service in line. In this case this option is provided to allow for a situation where we are used in the middle.

Note: this does not exempt the connecting host from any DDoS protection rules and is generally not a recommended configuration.

An option to override the Backend Real IP header (defaults to X-Real-IP) is also provided.

UUID Header

Every request (successful or an error) is assigned a request UUID. This UUID is shown on non customised error pages (for more information see the Error Pages documentation) and can be used to identify a specific request. This UUID is also sent to the backend server in a header defined by you if enabled (off by default).

If enabled with the header of X-Request-Id you should expect to see a request similar to the following made to your backend server:

GET / HTTP/1.1
Accept-Encoding: deflate,gzip
Host: [...]
X-Real-IP: [...]
X-Scheme: https
X-Source: TEST_LAX1
X-Request-Id: 45dd4b87-7722-85b5-080b-8ac5080b235a
[...]

Host Translation

An option is provided that allows you to specify a custom HTTP host to be sent to the backend server different to what the client provides. This custom hostname can also include the $host variable. This configuration is especially useful for white-labeling software and allowing for dynamic configurations of domains that the backend software may not easily provide.

Example configurations:

  • $host: This is the default configuration. There is no need to change or enable the setting for this.
  • $host.domain.com: the connecting domain name would be provided as a subdomain to your supplied domain name suffix. domain.com - "domain.com" will always be sent to the backend server regardless of the host header received.
  • _: A single underscore denotes a special mode where no HTTP header will be sent.

Performance Tracing headers

Experiencing slower performance of your website than expected? Want data on how fast your backend server responds to requests? Performance Tracing (Server-Timing) headers can do this. Performance tracing headers are sent on all requests served by your backend when enabled and are disabled by default.

NOTE: Performance tracing headers should only be enabled if required as they do slightly reduce the performance of the page and size of the request.

When enabled using Chrome Developer tools you can retreive metrics on: - The time it takes for a connection to your backend to be made (0ms if a pooled keepalive connection is used) accurate to within +/- 10ms. This includes TLS negotiation time and any DNS lookups as necessary. - The time it takes for the response headers to be generated and then received from your backend (accurate to within +/- 10ms)

Chrome Server-Timing view

If multiple backends are used to serve a single reques (such as if a backend is down) only the time for used in the request to the first backend is used.

If you are troubleshooting an issue relating to peformance you also might want to: - Check caching settings if migrating from another proxy / web accelerator, we are conservative by default and place control in the hands of you (the customer). - Check error log for any issues connecting to your backend, or with your configuration (such as ratelimits). - Check routes both to/from your server and the backend communication IP and between your clients and our network - Check the content of the page being served for any issues that may be causing the page to load slowly, there is only so much caching and acceleration can do to speed up a poorly developed site / page.

Other Headers

By default we send a number of headers to the backend server. These headers are used to identify the request and provide information to the backend server. These headers are:

  • X-Source: The datacenter the request was received in.
  • X-Scheme: The scheme of the request (http or https).
  • X-Real-IP: The IP address of the client that connected to our network.
  • X-Request-Id: The UUID of the request for tracing / logging purposes