[Feature proposal] Wild card forwarding on a subdomain (80+443 traffic) e.g. with Caprover

boringproxy
1

It will be awesome if we could define a wild card to be forwarded from server to client. For instance *.sub.example.com

Use case would be, for instance, to be able to install a Caprover server locally and forward automatically services created by it.

The local installation is straightforward this way:

echo  "{\"skipVerifyingDomains\":\"true\"}" >  /captain/data/config-override.json
docker run -e MAIN_NODE_IP_ADDRESS=127.0.0.1 -p 80:80 -p 443:443 -p 3000:3000 -v /var/run/docker.sock:/var/run/docker.sock -v /captain:/captain caprover/caprover

But then we need to do the port forwarding properly as described in documentation:

All you need to do is to enable port forwarding on your router:

port 80 of router => port 80 of 192.168.1.12
port 443 of router => port 80 of 192.168.1.12

Now use your regular DNS provider and map *.domain.com to the public IP address of your network.

Now, like a normal installation, just login to http://192.168.1.12:3000 and update the root domain to domain.com

At this point, your instance should be accessible from http://captain.domain.com. You can enable HTTPS and deploy your apps.

Source: Run Locally · CapRover

Or should I ask if it’s already possible in a specific way?

2

Correct, this functionality does not currently exist.

However, I’m implementing it as part of my work on an open tunneling protocol:

https://forum.indiebits.io/t/toward-an-open-tunneling-protocol/30

The goal is to design a protocol that will allow client and server software beyond just boringproxy to be compatible with each other. I’ve already made a lot of progress with the initial prototype for boringproxy, but it’s turned into a bit of a different rabbit hole.

I’m hoping this will be resolved in the next month or two, but no guarantees.

3

See also https://github.com/boringproxy/boringproxy/issues/15

4

Such a shame on me… Sorry I didn’t even noticed the Github issue.

It shows some interest… we would say.

Is there a Github repo/branch where you’re working on the new protocol?

5

Nothing currently public for you to track. And I don’t have a timeline for when I expect this to be done, sorry.

6

No problem it was more in a way if I can provide some help in development, in case of good first PR.

7

For those stucking on this topic and until a nice out-of-the-box solution will be provided by BoringProxy, I recommand this well documented solution:

DISCLAIMER: very techy one