Running SimpleHelp Server behind Cloudflare Proxy

Hey all,

I had mentioned this topic months ago, but then it was a nginx proxy, but i guess mostly its the same. (See Setting up SimpleHelp behind Nginx reverse proxy)

I have switched recently to Cloudfare to use their Proxy for all my services to hide my Public IP.
The only thing i can not migrate to make it work with the Proxy is SimepleHelp :smiley:

I know that SimpleHelp is NOT only using 443 (or custom HTTPS Port). I know it uses TCP UDP etc also for Connections:

Is it not possible for the Devs of SimpleHelp to add support to run SimpleHelp behind a proxy? Maybe add an option to FORCE run SimpleHelp only via HTTPS? (I know there is an connection option to run the session via HTTP, so maybe that as workaround?

The reasoning for the proxy is that im running a Simplehelp Server at my home and the switch to cloudflare proxy has the intention to hide my public ip from the internet.


I asked recently about running SimpleHelp behind a NGINX reverse proxy and the answer was it wasn’t possible. I think because SimpleHelp uses UDP? CloudFlare might fare better. My install of SimpleHelp is on a Windows server where port 80 is already in use so it’s using port 8008. This port is sometimes blocked and asking users to remember to type in :8008 in the URL is tricky. Hence the requirement to proxy through NGINX.

It’s a shame… I would hope SimpleHelp move towards a more simple HTTPS implementation.

@Furkan and @Rob_Nicholson - the issue is the same, a proxy is meant to handle http/https traffic, SimpleHelp uses more protocols then that across those ports, so it will never work to proxy your SimpleHelp ports.

Cloudflare “Tunnel” , or maybe “Magic WAN” may be able to do what both of you are looking for, but I’ve never used either, so feel free to take a look. I believe both services are free as well.

Which is why I said “I would hope SimpleHelp move towards a more simple HTTPS implementation” - or at least offer it as an option.

Maybe the word should be “standard HTTPS implementation”.

You aren’t getting it, there is no way to move “towards a more simple https implementation” because it isn’t only https, so there isn’t a way to simplify it. “offering it as an option” would mean them reworking everything in the way that the server and clients communicate, plus having to deal with all the issues that come with tcp over udp. They would also need to introduce a server in the middle of your remote connections (and then charge an ongoing additional fee for them to run that) because there are always going to need to me more protocols than http(s) incoming into the server. It’s just the way the technology is. Look at something like rustdesk, or sunshine, or meshcentral. These are all self-hosted remote access programs, and they all require other ports to be open.

They’ve chosen to use 80 and 443 because they are the least often closed ports on the client side, so it presents the least issues with remote machines poking out through firewalls. Maybe what you are looking for, or should be asking for, is for them to split out the all the ports beyond http(s) to be customizeable so that you can choose to put them elsewhere.

I’d imagine that this isn’t high on the list though because it seems like there’s only a hand full of people choosing to host their server on the same ip that they have other http(s) on instead of just getting more IPs or hosting on a cheap cloudserver.

1 Like