Unable to Connect When Behind NGINX Reverse Proxy Manager

[RippyShark]

I was able to get a remote control session to work when using the basic docker-compose but as soon as I configure it to use a reverse proxy (specifically NPM) I cannot get a remote session. I am not the most technical user when it comes to Docker/Linux so I will be needing some hand holding if possible.

This is what happens when I attempt a remote connection over reverse proxy (I have reinstall the agent over the reverse proxy so the version should be up to date):

Here is my docker-compose:

These values need to be set. You can either define these environment variables

on the host or supply them here directly as string literals.

x-postgres-user: &pgUser ${ControlR_POSTGRES_USER:?error}
x-postgres-password: &pgPassword ${ControlR_POSTGRES_PASSWORD:?error}
x-aspire-browser-token: &aspireToken ${ControlR_ASPIRE_BROWSER_TOKEN:?error}

services:
controlr:
image: translucency/controlr:latest
container_name: controlr
restart: unless-stopped
depends_on:
- postgres
- aspire
ports:
- "5120:8080"
environment:
# ASPNETCORE variables should not be changed.
ASPNETCORE_ENVIRONMENT: Production
ASPNETCORE_HTTP_PORTS: 8080

 ControlR_POSTGRES_USER: *pgUser
 ControlR_POSTGRES_PASSWORD: *pgPassword
 ControlR_POSTGRES_HOST: "postgres"

 # Whether to make self-registration publicly available.
 ControlR_AppOptions__EnablePublicRegistration: false

 # Allows devices to self-register without requiring an installer key.
 ControlR_AppOptions__AllowAgentsToSelfBootstrap: false

 # Automatically obtain Cloudflare IPs from https://www.cloudflare.com/ips-v4
 # and add them to the KnownNetworks list for forwarded headers.
 ControlR_AppOptions__EnableCloudflareProxySupport: true

 # Add an Azure Monitor connection string to enable exporting of OpenTelemetry data to Azure.
 #ControlR_AzureMonitor__ConnectionString:

 # Add an OTLP endpoint URL to enable exporting of OpenTelemetry data to an OTLP endpoint.
 ControlR_OTLP_ENDPOINT_URL: "http://aspire:18889"

 # Set the minimum level for logs sent to OTLP exporter and/or Azure Monitor.
 ControlR_Logging__LogLevel__Default: Information

 # Whether to add HTTP logging services.
 # https://learn.microsoft.com/en-us/aspnet/core/fundamentals/http-logging
 ControlR_AppOptions__UseHttpLogging: false

 # The Gateway IP here must match the IP address used by the Docker gateway.
 ControlR_AppOptions__DockerGatewayIp: "::ffff:172.18.0.1"

 # The maximum allowed file size for transfers in the remote File System component.
 # Set to 0 or less for no limit. Default is 100MB.
 ControlR_AppOptions__MaxFileTransferSize: 104857600

 ControlR_AppOptions__RequireUserEmailConfirmation: true
 ControlR_AppOptions__SmtpDisplayName: "ControlR"
 ControlR_AppOptions__SmtpEmail: ""
 ControlR_AppOptions__SmtpHost: ""
 ControlR_AppOptions__SmtpLocalDomain: ""
 ControlR_AppOptions__SmtpCheckCertificateRevocation: true
 ControlR_AppOptions__SmtpPassword: ""
 ControlR_AppOptions__SmtpPort: 587
 ControlR_AppOptions__SmtpUserName: ""

 # Uncomment and add an entry for each proxy that will be forwarding traffic
 # to ControlR. The app will not work correctly if this isn't done or if the
 # forwarded headers are not in the correct format.
 # See the docs for more details:
 # https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/proxy-load-balancer
 ControlR_AppOptions__KnownProxies__0: "172.18.0.2"
 ControlR_AppOptions__KnownProxies__1: "172.18.0.1"
 ControlR_AppOptions__KnownProxies__2: "172.20.0.1"

 #ControlR_AppOptions__KnownNetworks__0:

 # If enabled, ControlR will attempt to use geolocation APIs to determine
 # the closest relay server to the viewer when starting a remote control
 # session. Otherwise, the local server will be used.
 ControlR_AppOptions__UseExternalWebSocketRelay: false
 #ControlR_AppOptions__ExternalWebSocketHosts__0__Label:
 #ControlR_AppOptions__ExternalWebSocketHosts__0__Origin:
 #ControlR_AppOptions__ExternalWebSocketHosts__0__Latitude:
 #ControlR_AppOptions__ExternalWebSocketHosts__0__Longitude:

 # To enable Microsoft account login, create an App Registration in Azure and
 # set the values below. Instructions can be found here:
 # https://learn.microsoft.com/en-us/aspnet/core/security/authentication/social/microsoft-logins
 #ControlR_AppOptions__MicrosoftClientId: ""
 #ControlR_AppOptions__MicrosoftClientSecret: ""

 # To enable GitHub login, create an OAuth app in GitHub set the values below.
 # Instructions can be found here:
 # https://docs.github.com/en/apps/oauth-apps/building-oauth-apps/authorizing-oauth-apps
 #ControlR_AppOptions__GitHubClientId: ""
 #ControlR_AppOptions__MicrosoftClientSecret: ""

postgres:
image: postgres:18
container_name: postgres
restart: unless-stopped
ports:
- "5432:5432"
volumes:
- postgres-data:/var/lib/postgresql
environment:
POSTGRES_USER: *pgUser
POSTGRES_PASSWORD: *pgPassword
POSTGRES_DB: controlr

aspire:
image: mcr.microsoft.com/dotnet/aspire-dashboard:9.2
container_name: aspire
restart: unless-stopped
ports:
- "18888:18888"
expose:
- "18889"
environment:
DOTNET_DASHBOARD_OTLP_ENDPOINT_URL: "http://aspire:18889"
Dashboard__Frontend__BrowserToken: *aspireToken

volumes:
postgres-data:
name: "postgres-data"

[ac2323]

I'm having the same issue using Cloudflare. My root domain A record is not proxied, though the CNAME subdomain ControlR uses is. Not having this issue using Remotely.

[bitbound]

I'm assuming this is due to Cloudflare caching. Also discussed here. You'll need to bypass the cache in Cloudflare for paths starting with /downloads.

If you send me agent and desktop client logs, I can verify that this is the case. Or run (after replacing the hostname with your own):

(Invoke-WebRequest -Uri https://{your-hostname-here}/downloads/win-x64/ControlR.DesktopClient.zip -Method Head).Headers["Content-Hash"]

If that doesn't return a hexadecimal-formatted string, then Cloudflare caching (or something in between the agent and server) has removed the header.

@ac2323

Not having this issue using Remotely.

I ended up doing the update checks differently in ControlR, in which it uses a custom header to compare the hash of the local bundle with the server's. Unfortunately, it wasn't until afterward that I found out that Cloudflare doesn't preserve the header when proxying.

I'll revisit this and add a fallback method. Or replace it. Either way, it will need to go through one update cycle with the above fix (assuming caching is the issue) before the new method will take effect. I'll have it in the next release, though.

[ac2323]

I'll revisit this and add a fallback method. Or replace it. Either way, it will need to go through one update cycle with the above fix (assuming caching is the issue) before the new method will take effect. I'll have it in the next release, though.

Bypassing caching fixed the issue indeed. Thanks!

[RippyShark]

Bypassing caching also fixed it for me too. Thank you!