

My ISP blocks incoming data to common ports unless you get a business account.
Oof, sorry, that sucks. I think you could still go the route I described though: For your domain example.com
and example service myservice
, listen on port :12345
and drop everything that isn’t requesting myservice.example.com:12345
. Then forward the matching requests to your service’s actual port, e.g. 23456
, which is closed to the internet.
Edit: and just to clarify, for service otherservice
, you do not need to open a second port; stick with the one, but in addition to myservice.example.com:12345
, also accept requests for otherservice.example.com:12345
, but proxy that to the (again, closed-to-the-internet) port :34567
.
The advantage here is that bots cannot guess from your ports what software you are running, and since caddy (or any of the mature reverse proxies) can be expected to be reasonably secure, I would not worry about bots being able to exploit the reverse proxy’s port. Bots also no longer have a direct line of communication to your services. In short, the routine of “let’s scan ports; ah, port x is open indicating use of service y; try automated exploit z” gets prevented.
TBH, it sounds like you have nothing to worry about then! Open ports aren’t really an issue in-and-on itself, they are problematic because the software listening on them might be vulnerable, and the (standard-) ports can provide knowledge about the nature pf the application, making it easier to target specific software with an exploit.
Since a bot has no way of finding out what services you are running, they could only attack caddy - which I’d put down as a negligible danger.