Does TR7 Load Balancer require code changes in my application?

Short answer

No; there is no need to change the application code. TR7 works as a reverse proxy in front of the application, and all configuration is done from the TR7 interface. Since the application now receives requests from TR7 rather than directly from the client, a server-side setting may be required on three topics: seeing the real client IP (X-Forwarded-For and the web server reading this header, or SNAT → Use Client IP), HTTPS being terminated on TR7 (X-Forwarded-Proto) and the session being kept in server memory (persistence).

How Does It Work?

When TR7 is placed in between, three things that the application sees change:

1. The connection comes from TR7. In HTTP and L7 TCP vServices, TR7 establishes the connection to the Backend Service; by default, the server sees TR7's IP, not the client's (with SNAT Default, this address is the Interface IP of the interface that goes to the server in the Backend Service's route table, located in the same subnet as the server (or as the gateway, if the server is reached through a gateway)).
2. HTTPS can be terminated on TR7. If the certificate is on the vService and SSL Service is off on the Backend Service, the request reaches the Backend Service unencrypted (HTTP); the application does not know that the request actually came over HTTPS.
3. Requests are distributed across multiple servers. Without persistence, consecutive requests of the same user can go to different servers.

None of these makes changing the application code mandatory; the table below shows how each of them is handled.

Application-Side Checklist

Situation	Effect	What is done
The client IP is used in the logs or in the application (HTTP)	The server sees TR7's IP	Add X-Forwarded-For Header is turned on in the vService; the web server is configured to read this header as the client IP and to trust only TR7's IP: in Nginx, ngx_http_realip_module (set_real_ip_from + real_ip_header X-Forwarded-For), in Apache, mod_remoteip (RemoteIPHeader X-Forwarded-For + RemoteIPInternalProxy), and in IIS 8.5 and later, X-Forwarded-For is added to the W3C log as a custom field. Alternatively, SNAT → Use Client IP is selected on the Backend Service; in this case, the server's response must return through TR7
The client IP is needed, and the server is a TCP service (L7 TCP)	The server sees TR7's IP	If the server supports the PROXY protocol, Proxy or Proxy v2 is selected in the Proxy field of the Backend Service and PROXY protocol acceptance is enabled on the server; if it does not support it, SNAT → Use Client IP is used
HTTPS is terminated on TR7	The application sees the request as HTTP; its own HTTPS redirect can enter a loop, and it can generate http:// links on the pages	The HTTP → HTTPS redirect is done on TR7 (Protocol → HTTP → HTTPS). TR7 does not add the X-Forwarded-Proto header on its own; if needed, it is added with the Set HTTP Header action, and the application is configured to behave according to this header
The session is kept in the server's memory	When the user lands on another server, the session is lost	Persistence is enabled in the vService; with New Cookie, TR7 generates and reads its own cookie, and with Current Cookie, it uses the application's session cookie
The domain name points directly to the server	Traffic never reaches TR7	The DNS record is directed to the address that the vService listens on
Network vService, Direct Server Return mode	The destination address of the packet does not change	On the server, the vService address is defined as a local address (loopback), and ARP replies for this address are turned off (details)

It is not mandatory to open a special address (e.g. /health) in the application for the health check; a TCP or HTTP check works with the existing port. A simple page that verifies that the application is actually working, however, makes the HTTP check more meaningful.

Common Misconceptions

• "When X-Forwarded-For is turned on, the logs are fixed on their own." TR7 adds the header; the web server needs to be configured to read this header as the client IP.
• "TR7 itself informs the application that the request is HTTPS." The X-Forwarded-Proto header is not added automatically; it is added with an action. If the application's own HTTP → HTTPS redirect is enabled, an infinite redirect loop can occur.
• "Use Client IP works in every network." The response traffic of the Backend Service must return through TR7; if it does not, the connections are not completed.
• "The web server can trust every X-Forwarded-For value." The server is configured to take into account only the header coming from TR7's IP (set_real_ip_from, RemoteIPInternalProxy); otherwise, the client can write a fake IP.

How it is done in the documentation

• HTTP vService · X-Forwarded-For
• Backend Services · Use Client IP
• Backend Services · Proxy
• Set HTTP Header · Scenario 2: Forwarding the Protocol Information After SSL Offloading
• Load Balancer - ADC · Typical Setup Flow

Related questions

• Why do my backend servers see all requests as coming from TR7's IP?
• After switching to HTTPS, pages show a "mixed content" warning; how do I fix it?
• An infinite redirect loop occurred; why?
• How do I know whether my application needs persistence?