GitLab Geo redirects to primary node's internal URL when accessing the secondary node

Description

When accessing a GitLab Geo secondary node, users are redirected to the internal URL of the primary node instead of staying on the secondary node.
Navigation attempts to the secondary node result in unexpected redirects to the primary node's internal URL, making the secondary node inaccessible.

Environment

Impacted offerings:

GitLab Self-Managed

Impacted versions:

GitLab Geo configured with primary and secondary nodes using Helm charts

Solution

Configure the NGINX Ingress of the primary node to use forwarded headers by setting use-forwarded-headers to true.
- If you are using the bundled NGINX ingress, you can enable the separate NGINX ingress for GitLab Geo:
  - The custom ingress is configured with use-forwarded-headers set to true
```
nginx-ingress-geo:
  enabled: true
gitlab:
  webservice:
    ingress:
    enabled: true
    useGeoClass: true  
  extraIngress:
    enabled: true
    useGeoClass: true
```
- If you are using your own ingress deployment, set use-forwarded-headers to true in your NGINX ingress.
Update the deployment.

Cause

The issue occurs because the GitLab Workhorse component on the primary node relies on the X-Forwarded-Host header to determine the correct URL to return in responses. When use-forwarded-headers is not set to true in the NGINX Ingress configuration, these headers are not properly passed to Workhorse.

As a result, when a request is proxied from the secondary node to the primary node, the primary node is unaware of the original host that was used to access the secondary node. Instead, it returns URLs based on its own internal service name, causing the redirect to an incorrect internal URL.

Additional Information

This might also happen on an Omnibus install if a reverse proxy that modifies X-Forwareded-Host is used in the Primary node.
The X-Forwarded-Host header is essential for proper functioning in multi-node setups like GitLab Geo.