Gruxi Web Server

Appearance

Proxy ​

Proxy processor in a nutshell

The proxy processor is the reverse proxy component of Gruxi, allowing proxying to other servers and services. It handles forwarding client requests to backend servers and returning their responses to the clients.

The proxy processor allows Gruxi to act as a reverse proxy server, forwarding requests to backend servers and returning their responses to clients.

This is useful for load balancing and securing backend services.

Reverse proxy features in short

  • Reverse proxying to backend servers
  • Load balancing across multiple backend servers
  • Health checks for backend server availability
  • Supports HTTP, HTTPS, and WebSockets
  • Supports HTTP/1 and HTTP/2
  • TLS termination capabilities
  • Preserves the original Host header or forces a specific Host header

Configuration fields ​

The PHP Processor has these configuration fields in the admin portal:

Verify TLS Certificates ​

If your backend server is running TLS with a self-signed certificate, you can disable TLS certificate verification in the proxy processor configuration. This allows Gruxi to connect to the backend server without validating the certificate, which is necessary when using self-signed certificates.

Name ​

Name is just a label for the processor and can be set to anything you like and only uses for your reference in the admin portal.

URL Match Patterns ​

The proxy processor will only handle requests that match the URL patterns you specify, and it will pass other requests to the next processor in line. Default is * (match all requests), but you can make this more specific by using URL matching rules to only proxy requests from a specific path (for example, /api/*).

Proxy Type ​

Set the type of proxying you want to use. Currently supported type is HTTP which essentially is a standard reverse proxy for HTTP and HTTPS backend servers, with support for WebSockets and HTTP/2 when the backend supports it.

Load Balancing Strategy ​

When multiple backend servers are configured, you can choose the load balancing strategy to determine how requests are distributed among the backend servers. The default strategy is Round Robin, which distributes requests evenly across all backend servers in a circular order.

Upstream Servers ​

The processor can be configured with a list of one or more backend servers, which specifies where requests should be forwarded. It supports various protocols, including HTTP, HTTPS, WebSockets, and more. It can also be used to terminate TLS connections.

When working with multiple backend servers, load balancing is active and distributes requests between them. Health checks are built in: you supply a path to check, and backends that fail (or don’t respond) are removed from rotation until they are considered healthy again.

Timeout ​

The timeout (in seconds) is the maximum amount of time that Gruxi will wait for a response from the backend server before timing out. This is important to prevent hanging requests and to ensure that your server remains responsive. You can adjust this value based on the expected response time of your backend servers.

Health Check Path ​

The health check path is the URL path that Gruxi will use to perform health checks on the backend servers. Gruxi will periodically send requests to this path (based on Health Check Interval) on each backend server to determine if they are healthy and able to handle requests. The backend server is considered healthy if it responds with a 200 OK status code. If a backend server fails the health check (for example, it does not respond or returns an error status code), it will be removed from the load balancing rotation until it passes the health check again.

Health Check Interval ​

The health check interval (in seconds) is the frequency at which Gruxi will perform health checks on the backend servers. You can adjust this value based on how quickly you want Gruxi to detect and respond to changes in the health of your backend servers.

Health Check Timeout ​

The health check timeout (in seconds) is the maximum amount of time that Gruxi will wait for a response from a backend server during a health check before considering it a failure. This is important to ensure that health checks do not hang indefinitely and that unhealthy servers are detected in a timely manner. You can adjust this value based on the expected response time of your backend servers during health checks.

URL Rewrites ​

The proxy processor supports URL rewriting, allowing you to modify the request URL before forwarding it to the backend server. This is useful for scenarios where the backend server expects a different URL structure than what the client is using. For example, you can rewrite the incoming request path /api/ to /v1/ when forwarding to the backend server. This allows you to maintain a clean and consistent URL structure for clients while still being able to work with backend servers that have different URL requirements.

Preserve Host Header ​

Determines whether the original Host header from the client request should be preserved when forwarding to the backend server. B

Forced Host Header ​

You can also configure the proxy processor to force a specific Host header value, overriding the original value from the client request. This can be useful when a backend server expects a fixed Host header regardless of the client request. For example, if your backend server is configured to serve content based on a specific Host header, you can set this field to ensure that all requests forwarded to that backend have the correct Host header value.

Load balancing ​

The processor can be configured with a list of one or more backend servers, which specifies where requests should be forwarded. It supports various protocols, including HTTP, HTTPS, WebSockets, and more. It can also be used to terminate TLS connections.

When working with multiple backend servers, load balancing is active and distributes requests between them. Health checks are built in: you supply a path to check, and backends that fail (or don’t respond) are removed from rotation until they are considered healthy again.

Supported algorithms for load balancing:

  • Round Robin (default) - simple and effective, distributing requests evenly across all backend servers in a circular order.

Health checks ​

Health checks are built in: you provide a path to check, and backends that fail (or don’t respond) are removed from rotation.

You can configure the path and the interval between checks. The health check performs a simple GET request to the configured path and expects a 200 response to consider the backend healthy. The request times out after a configurable period.