TL;DR: Pretty much zero chance.
This is the implication of NAT (Network Address Translation). Your internet service provider assigns customers, in the vast majority of circumstances, only one IP address. But only having one IP address can be a problem; how do the multiple devices in your home communicate on the internet if they can’t all have IP addresses?
Enter NAT. You have the public internet on one side (the WAN side) of your router, and a private internet on the other (the LAN side). When your device on the LAN talks to a server on the internet, all the traffic goes through your router, and the server is effectively receiving requests and replying directly to your router, which is translating that back to your device.
It’s fairly easy for NAT to handle multiple devices trying to talk to servers on the internet - the outgoing connections can be given specific ports for this purpose automatically so the router can keep track of which reply traffic is for which device.
But how does an external client (your Tinycam app when you’re away from home) communicate with specific hosts on your private internet / LAN? Well… it can’t. You’ve only got one IP address, and it’s for your router.
But you do have multiple ports on that router. Enter port forwarding - you can manually configure your router to tell it that when someone on WAN tries to connect to a specific port, all that traffic should go to one specific host.
You’ve done this with Caddy. And you’ve come to this thread hoping that you can have Caddy handle the distribution of connections after that point. But there are two major issues with this approach. Firstly, Caddy’s HTTP server only has four metrics by which to decide how to handle an incoming request:
- Scheme (i.e. HTTP or HTTPS)
- Hostname (e.g.
- Port (e.g.
- Path (e.g.
Since you can’t change the hostname or the path, you’re left with port or scheme. Caddy can’t multiplex HTTP and HTTPS on the same port, so you’re left with only one meaningful differentiator, of which you have two options, for a maximum of two cameras (one configured on HTTP/80, one configured on HTTPS/443). Caddy could proxy to a different camera on each.
That doesn’t solve your RTSP problem, though. Caddy’s HTTP server doesn’t speak RTSP, and while Caddy’s net server does, the net server naturally can’t use any of the above differentiators for an incoming connection, other than port. Which leaves us with only two potential connections - really, only one camera, because each camera uses two ports (HTTP and RTSP).
The router is the choke point for ports, because it’s the gateway to the internet at large, and because port forwarding has to be one port mapped to one LAN destination. You can open up more ports, and point them at Caddy’s net server, but why do that? Caddy’s net server acts effectively as a port forwarder anyway, the cool part about it is that it can leverage the
tls directive. You might as well just have your router do it.