Proxy Templates
Last updated
Last updated
Reblaze acts as a proxy; it receives requests from clients (web visitors, API clients, etc.), blocks hostile traffic, and passes legitimate requests to the backend.
Proxy Templates define Reblaze's behavior as a proxy. They are templates for creating new sites (i.e., Server Groups) within Reblaze.
When new sites are created, they remain linked to their underlying templates. Revising a Proxy Template will automatically update all sites that are based upon it.
A Proxy Template consists of the following:
General parameters for administration
Frontend settings, defining Reblaze's interaction with clients
Backend settings, defining Reblaze's interaction with backend servers
Trusted Sources, defining trusted sources of traffic (e.g., load balancers and CDNs)
A name to be used within the Reblaze interface.
Information about this Template, to be used within the Reblaze interface.
Defines one or more header fields within which Reblaze can find the client's IP address. When Reblaze receives an incoming request from a client, the request will have passed through a load balancer on its way to Reblaze. This means that the header will contain the client's IP and the load-balancer IP. These two IPs are usually found within the X-Forwarded-For field (which is the default entry here). In this situation, Reblaze knows how to extract the client IP from this field. In other situations, a different field name might be necessary. For example, if the Reblaze customer is using Akamai CDN, the incoming request will have the client IP in a field named True-Client-IP instead.
You can place limits on the amount of data that users can upload to the system. The defaults usually work well; however, if your application accepts user-generated content or other large files, then changes to these settings might be necessary.
Please note that if you increase these settings within Reblaze, then the upstream server should also be configured to accept and store the quantity of data that Reblaze will (potentially) pass through.
Specifies the maximum accepted body size of a client request, as indicated by the request header Content-Length. Size in MBs.
These settings allow you to limit the amount of resources consumed by an IP address. Reblaze can limit consumption by the average number of requests per second, while also allowing temporary bursts at a higher rate.
When a requestor exceeds any of these thresholds, subsequent requests will be answered with error code 503 (Service Unavailable).
Note that this rate limiting applies across the entire application. For example, if one IP address is submitting requests to multiple URLs within a web application, all the requests are combined when determining if rate limits have been violated. If you need more flexibility, consider using Rate Limit Rules instead.
Sets the allowable request rate per IP, per second: i.e., the allowable per-second average of incoming requests, enforced on an incremental basis (where "increment" refers to the number of milliseconds allowed for one request).
Example: This is set to 100. Thus, 100 requests are allowed per second. However, the system does not enforce rate limits on a per-second basis; it used a granularity of milliseconds. Therefore, it will allow one request every 10 milliseconds. (100 r/s, divided by 1000 ms/s, equals 1r/10ms.)
Sets the allowable additional burst rate per IP, per second. The additional requests are accepted and placed into a queue.
Example: Let's say that the previous field (Requests per second per IP address) is set to 100. Without burst limits—i.e., if this field were set to zero—the system will reject every request that was received less than 10ms after the previous one. However, the burst limit is set to 20 instead. This means that Reblaze will accept 21 requests (1 original plus 20 additional) per 10 milliseconds. In other words, when a request is received, up to 20 more can be received and accepted within the following 10 ms. If instead 25 total requests are received during that time, the last four requests will be denied with a 503 error.
The Timeout settings allow the system to monitor the time required to serve resources to each client. Any connection that exceeds the specific limits will be dropped.
Why timeouts are important
Some DDoS tools (e.g., R-U-Dead-Yet, or RUDY) send a relatively small quantity of traffic requests, but do so as slowly as possible (often with each byte sent separately). While a legitimate request can be resolved in milliseconds, a single RUDY client can tie up server resources for several minutes. Even a few hundred of these machines attacking a server can be very destructive.
The Timeout settings allow Reblaze to block unresponsive requestors, whether their unresponsiveness is malicious or not. For most Reblaze deployments, the default timeout settings work well. They are sufficient to filter out hostile traffic, while still accommodating even those users with low bandwidth.
All times are specified in seconds.
If the body is not obtained in one read-step, this timeout begins. If the timeout expires and the client has still sent nothing, the Reblaze Gateway returns error Request time out (408).
The timeout for keep-alive connections with the client. The Reblaze Gateway will close connections after this time. This setting increases server efficiency; it allows the server to re-use browser connections and save resources. When changing this value, special care should be taken; in some cases, it depends on specific cloud vendor and load balancer settings.
How long to wait for the client to send a request header. If the header is not received within this time, Reblaze returns error 408 (Request Timeout).
Specifies the response timeout to the client. This timeout does not apply to the entire transfer but, rather, only between two subsequent client-read operations. Thus, if the client has not read any data for this amount of time, the Reblaze Gateway shuts down the connection.
For more info on the header size settings below, see this and this.
The multiple of Large header size and Large header buffers should not exceed load balancer limitations.
The maximum buffer size for accepting client request headers.
The default buffer size for accepting client request headers.
The maximum number of buffers for accepting client request headers.
The maximum buffer size for accepting the client body.
The time (in seconds) for Reblaze to wait, before treating a connection with the backend as having failed.
The time (in seconds) for Reblaze to wait, before treating a data transfer attempt to the backend as having failed.
The time (in seconds) for Reblaze to wait, before treating a downstream (toward Reblaze) data transfer attempt as having failed.
Defines the value of the Host header passed to the backend. The default value ($host) sets it equal to the Host header in the incoming request (in other words, the Host header is passed upstream unchanged).
Defines the field name that contains the client's IP address. Reblaze is a proxy, and it passes incoming client requests to the upstream server. This means that the server will receive request headers which contain Reblaze's cloud IP address as the "client" IP. Usually, this is not useful; almost always, the server will need the IP of the actual client instead. To facilitate server logging, analytics, and so on, Reblaze adds the IP address of the originating client to the headers that it sends to the server. The Real IP Header Name defines the name of the field within which this information is passed.
This list defines the ranges of IP addresses which are trusted for providing forwarded IP addresses: for example, the load balancers in front of Reblaze, or the CDN.
