When you build a web application, your server does not always communicate directly with the visitor's browser. Sometimes, other servers are placed between the user and your application. These servers are commonly called proxies and load balancers.
They can improve security, performance, and traffic management. However, they also change how your application receives information about a request.
In this article, we will learn what proxies and load balancers do, why they matter, and how to configure Inphinit to work correctly behind them.
1. What Is a Proxy?
A proxy is a server that receives a request from a client and forwards it to another server.
For example, imagine that a visitor opens your website:
Visitor → Proxy → Your Application
Your application receives the request from the proxy instead of directly from the visitor.
This can create two important differences:
- IP address: Your application may see the proxy's IP address instead of the visitor's IP address.
- Protocol: The visitor may use HTTPS, while the proxy communicates with your application using HTTP.
Proxies can send additional HTTP headers to share information about the original request.
Some common examples are:
-
X-Forwarded-For: The original client's IP address. -
X-Forwarded-Proto: The original protocol, such as HTTP or HTTPS. -
X-Forwarded-Host: The original hostname. -
X-Forwarded-Prefix: A path prefix used by the application.
2. What Is a Load Balancer?
A load balancer distributes incoming requests across multiple application servers.
For example, instead of sending every visitor to a single server, it can distribute traffic like this:
→ Server A
Visitor → Load Balancer → Server B
→ Server C
This helps applications handle more visitors and reduces the load on individual servers.
Like a proxy, a load balancer can also forward information about the original request through HTTP headers.
3. Why Does Inphinit Need Proxy Configuration?
When Inphinit runs behind a proxy or load balancer, it may not automatically know the visitor's original IP address or whether the original connection used HTTPS.
This information is important for several reasons:
- Recording the correct client IP in access logs.
- Generating URLs with the correct protocol and hostname.
- Redirecting visitors correctly.
- Applying security rules based on the visitor's IP address.
Inphinit supports forwarded request information, but you must configure which proxies are trusted.
4. How to Configure Inphinit
Let's configure a simple example.
Imagine your application is behind a proxy with this IP address:
10.0.0.5
Step 1: Enable Forwarded Information
In your environment configuration, add:
APP_FORWARDED=1
This enables Inphinit's forwarded information support.
Step 2: Register Your Trusted Proxy
Open system/main.php and register the proxy IP address:
$forwarded->setKnownProxies(array(
'10.0.0.5'
));
Now Inphinit knows that requests coming directly from this IP address can provide trusted forwarded information.
You can also register a network instead of individual IP addresses:
$forwarded->setKnownNetworks(array(
'10.0.0.0/24'
));
The /24 notation represents a range of IP addresses.
Important: Only add proxies or networks that you control and trust.
5. Getting the Original Client IP Address
After enabling the feature, you can use the $app->forwarded object to retrieve information about the original request.
For example:
$app->action('GET', '/client-ip', function ($app) {
$ip = $app->forwarded->getIp();
echo $ip;
});
The getIp() method returns the original client IP address provided by the trusted proxy.
You can also retrieve other information:
$ip = $app->forwarded->getIp();
$proto = $app->forwarded->getProto();
$host = $app->forwarded->getHost();
$prefix = $app->forwarded->getPrefix();
These methods return the client IP address, original protocol, original hostname, and path prefix, respectively.
6. Handling Applications With and Without a Proxy
Your application may run in different environments. For example, you might use a proxy in production but not during local development.
In this situation, you should handle both cases:
$app->action('GET', '/client-ip', function ($app) {
if ($app->forwarded) {
$ip = $app->forwarded->getIp();
} else {
$ip = $_SERVER['REMOTE_ADDR'];
}
echo $ip;
});
When forwarded information is available, the application uses it. Otherwise, it falls back to REMOTE_ADDR, which contains the address of the host directly connected to the application.
7. Building URLs Correctly
When an application runs behind a proxy, manually building URLs can cause problems.
For example, your application might generate an HTTP URL even though the visitor originally accessed the website using HTTPS.
Inphinit provides two constants to help:
INPHINIT_BASE_URL
INPHINIT_PATH
You can combine them to build a URL:
$url = INPHINIT_BASE_URL . INPHINIT_PATH;
These constants account for forwarded values, including the original protocol, hostname, and path prefix.
8. A Security Warning
Forwarded headers are not automatically trustworthy.
A visitor can send a fake X-Forwarded-For header to make a request appear to come from another IP address.
For this reason, never trust forwarded information from every incoming connection.
Follow these basic security practices:
- Register only trusted proxy IP addresses or networks.
- Avoid unnecessarily broad network ranges.
- Restrict direct access to your application whenever possible, using a firewall or security group.
- Make sure your proxy overwrites or correctly appends forwarded headers instead of blindly accepting values supplied by visitors.
If you use multiple proxies, such as Cloudflare followed by an AWS Application Load Balancer, register all trusted intermediate proxies.
Conclusion
Proxies and load balancers are common parts of modern web infrastructure. They help improve application performance, scalability, and security, but they can also change how your application sees incoming requests.
With Inphinit, configuring trusted proxies and enabling APP_FORWARDED allows your application to access the original request information correctly.
The most important rule is simple: only trust forwarded headers when they come from proxies you explicitly trust.
Top comments (0)