Hosting behind Cloudflare Proxy

[j0nathanr]

As per the bug report guidelines, I'm creating a discussion to aid myself and others in hosting ControlR specifically behind Cloudflare Proxy.

Try as I might, I've been unsuccessful in initiating a remote session to an agent behind Cloudflare Proxy despite all other features working. I have an nginx server acting as the reverse proxy for Control R, below is the error reported in the browser console and aspire when attempting to start a remote session:

warn: ControlR.Web.Client.Services.ViewerHubConnection[0]
      Failed result. Reason: Failed to request a streaming session from the agent. dotnet.runtime.ew19f13umk.js:3:171638

The error is only produced when Cloudflare is proxying the connection, if I set the real IP of my nginx reverse proxy in the agent's hosts file, remote sessions work without issue. I've ensured websockets are enabled in Cloudflare and I've added all known proxies\enabled Cloudflare proxy support in the docker compose. The public IP of the agents are all correct and I don't see any unknown proxy errors in aspire or the docker container logs either.

[bitbound]

My personal server and the public one at https://controlr.app are using Cloudflare proxy. I'm using Caddy, though.

I had to configure Caddy to trust the Cloudflare IP ranges using the trusted_proxies directive in the Caddyfile. The result looks like this:

{
  local_certs

  servers {
    trusted_proxies static 173.245.48.0/20 103.21.244.0/22 103.22.200.0/22 103.31.4.0/22 141.101.64.0/18 108.162.192.0/18 190.93.240.0/20 188.114.96.0/20 197.234.240.0/22 198.41.128.0/17 162.158.0.0/15 104.16.0.0/13 104.24.0.0/14 172.64.0.0/13 131.0.72.0/22 2400:cb00::/32 2606:4700::/32 2803:f800::/32 2405:b500::/32 2405:8100::/32 2a06:98c0::/29 2c0f:f248::/32
  }
}

[bitbound]

While I was looking at this, I realized that the UI wasn't being updated properly. In the next release, an alert will be displayed here when it fails to start the session.

For thrown exceptions, though, you'll still need to look at the server or agent logs to see the exact error message.

[j0nathanr]

So I took a look at the agent logs and it looks the hash verification is failing when behind Cloudflare Proxy. What's interesting is if I set "real_ip_header CF-Connecting-IP;" than I get a warning in the console "unknown proxy" with the agent's public IP with port 0.

I suspect this is relevant as then?

warn: Microsoft.AspNetCore.HttpsPolicy.HttpsRedirectionMiddleware[3]

      Failed to determine the https port for redirect.

With Cloudflare Proxy:

2025-09-16 14:43:37.672 -07:00 [WRN] Failed result. Reason: Failed to get desktop client file hash. { SourceContext: "ControlR.Agent.Common.Services.DesktopClientUpdater", Scope: ["IsRemoteHashDifferent"], ThreadId: 39 }

2025-09-16 14:43:37.723 -07:00 [ERR] Error result. Reason: Error while ensuring remote control latest version. { SourceContext: "ControlR.Agent.Common.Services.DesktopClientUpdater", Scope: ["EnsureLatestVersion"], ThreadId: 39 }
System.UnauthorizedAccessException: Access to the path 'Avalonia.Base.dll' is denied.
   at System.IO.FileSystem.RemoveDirectoryRecursive(String fullPath, WIN32_FIND_DATA& findData, Boolean topLevel)
   at System.IO.FileSystem.RemoveDirectory(String fullPath, Boolean recursive)
   at ControlR.Agent.Common.Services.DesktopClientUpdater.EnsureLatestVersion(CancellationToken cancellationToken)

2025-09-16 14:43:48.898 -07:00 [ERR] Desktop client process in session 1 has exited immediately after launch. { SourceContext: "ControlR.Agent.Common.Services.Windows.DesktopClientWatcherWin", ThreadId: 11 }

[Pattern repeats continuously...]

Without Cloudflare Proxy:

2025-09-16 15:48:45.735 -07:00 [INF] Comparing local desktop client archive hash (xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx) to remote (xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx). { SourceContext: "ControlR.Agent.Common.Services.DesktopClientUpdater", ThreadId: 11 }

2025-09-16 15:48:45.735 -07:00 [INF] Versions match.  Continuing. { SourceContext: "ControlR.Agent.Common.Services.DesktopClientUpdater", ThreadId: 11 }

2025-09-16 15:48:50.177 -07:00 [INF] Received IPC client identity attestation for process 11236. { SourceContext: "ControlR.Agent.Common.Services.Windows.IpcServerInitializerWindows", ThreadId: 16 }

2025-09-16 15:49:45.996 -07:00 [INF] Creating streaming session.  Session ID: "7ab97590-42f3-4d47-ac02-d1adc3aabce8", Viewer Connection ID: 6yTldmp-25Z06f3YT4QJeg, Target System Session: 2, Process ID: 11244 { SourceContext: "ControlR.Agent.Common.Services.AgentHubClient", ThreadId: 16 }

2025-09-16 15:49:46.013 -07:00 [INF] Streaming session created successfully for process ID 11244. { SourceContext: "ControlR.Agent.Common.Services.AgentHubClient", ThreadId: 9 }

[bitbound]

Sorry, I missed the notification for this reply. Just saw it today.

Failed to determine the https port for redirect.

This message is normal if you're hosting behind a reverse proxy. You can configure Kestrel (the ASP.NET Core web server) to serve both HTTP and HTTPS directly to the internet, in which case it automatically redirect HTTP traffic to HTTPS. When a reverse proxy is handling HTTPS, though, Kestrel is only configured for the HTTP port and emits this warning.

The agent logs are interesting. The first warning you're seeing is because the Content-Hash header is missing. This gets set by the ContentHashHeaderMiddleware middleware for all requests to files in the /downloads/ folder. My guess is either the header is getting stripped (either by Cloudflare or something else in between), or the middleware isn't getting called.

For example, if the ControlR site is hosted at a subdirectory instead of a subdomain (e.g. "https://example.com/controlr" vs "https://controlr.example.com"), I think this might be possible.

But if the only difference is having the "proxied" toggle in Cloudflare, then I'd have to assume that Cloudflare is stripping it.

Maybe try bypassing the cache in Cloudflare's Cache Rules for the downloads folder and see if that helps?

As for the error after that, I'm not sure what's going on. If there were running processes of the Desktop Client, you'd so info-level log entries of the agent attempting to kill them before the update. So I'm guessing something else is locking the file and preventing deletion. While stepping through the code, I did find a race condition where the process could get relaunched right after getting killed and before deleting the file, but I haven't seen it happen in practice. I'll still fix the potential issue, but I doubt it could happen consecutively.

Let me know if the cache bypass works, and we'll go from there. :)

Edit: ContentHashHeaderMiddleware only adds the header to HEAD requests. So normal GET requests to download the file won't have it. That detail might be pertinent to troubleshooting any Cloudflare involvement.

[bitbound]

Well, it turns out that I already had rules that were bypassing the cache for downloads. After disabling them, I encountered the same issue as you described. So I'm pretty confident that this is it.

I'll add it to the documentation.

Edit: Tired typos.

[j0nathanr]

Can confirm that fixed it on my side, thanks for investigating

[kouhei-ioroi]

This topic relates to Cloudflare Proxy, so I'll post it here.

Cloudflare has an upload limit of 100MB per file for both free and Pro users.
While this isn't a problem when downloading files from the ControlR agent device, uploading files larger than 100MB from the ControlR web UI to the agent device results in an error.

blazor.web.js:1  Uncaught (in promise) Error: System.ArgumentException: There is no tracked object with id '4'. Perhaps the DotNetObjectReference instance was already disposed. Arg_ParamName_Name, dotNetObjectId
   at Microsoft.JSInterop.JSRuntime.GetObjectReference(/device-access/Int64 )
   at Microsoft.JSInterop.Infrastructure.DotNetDispatcher.BeginInvokeDotNet(/device-access/JSRuntime , DotNetInvocationInfo , String )
    at w.endInvokeDotNetFromJS (blazor.web.js:1:3158)
    at Object.zr [as endInvokeDotNetFromJS] (blazor.web.js:1:165450)
    at dotnet.runtime.st3wwc8rqy.js:3:33879
    at Fc (dotnet.runtime.st3wwc8rqy.js:3:172343)
    at 00b5ba72:0x1f1e1
    at 00b5ba72:0x1c8c7
    at 00b5ba72:0xea32
    at 00b5ba72:0x1d442
    at 00b5ba72:0xf1178
    at 00b5ba72:0xc6ca7
dotnet.runtime.st3wwc8rqy.js:3  fail: ControlR.Web.Client.Components.Pages.DeviceAccess.FileSystem[0]
      Error uploading file example.mp4
System.IO.IOException: Supplied file with size 396331845 bytes exceeds the maximum of 104857600 bytes.
   at Microsoft.AspNetCore.Components.Forms.BrowserFile.OpenReadStream(/device-access/Int64 , CancellationToken )
   at ControlR.Web.Client.Components.Pages.DeviceAccess.FileSystem.UploadSingleFile(/device-access/IBrowserFile file)

I'm confident that implementing chunked uploads would significantly improve the user experience.

[kouhei-ioroi]

After posting this, I noticed a couple of additional issues:

• When downloading files or folders containing 2-byte characters (such as Japanese characters), the browser returns an ERR_INVALID_RESPONSE error.
• When downloading a folder, a file with the folder name (without an extension) is downloaded. Is this a raw byte stream?

Apologies for deviating from the original topic.

[bitbound]

@kouhei-ioroi Thanks for reporting these!

Cloudflare has an upload limit of 100MB per file for both free and Pro users.

This is actually a hard-coded limit in ControlR. I was in a rush to get release 0.14.1 out during a two-week break between jobs, and I took some shortcuts where it made sense. This was one of them. I used ASP.NET Core's IFormFile API for uploaded files, which is convenient, but causes the whole file to get buffered in memory. I capped the size to avoid over-consumption of memory on my demo server.

I made a feature issue for improving it. I have some other small improvements that I personally want and will probably include with it.

When downloading a folder, a file with the folder name (without an extension) is downloaded. Is this a raw byte stream?

This is a bug. My bad. 🙂 It's supposed to have a ".zip" extension. I made another issue for it.

When downloading files or folders containing 2-byte characters (such as Japanese characters), the browser returns an ERR_INVALID_RESPONSE error.

Not sure what's going on here. I might be able to look into it, but to be totally honest, I don't think I'll ever have time to support other regions/languages/keyboards unless this somehow became a full-time job. But after what happened with Remotely, my hopes of that occurring are pretty slim.

You can subscribe to those issues for notification on when they get merged in. I'm not sure what the turn-around time will be, though. Day job and family occupies most of my time. But they will get fixed! 🙂

[kouhei-ioroi]

Thank you @bitbound .
If I have the time, I would also like to contribute to your amazing project.
I can't make any promises, but I will also look into the issue regarding double-byte characters.