this post was submitted on 06 Jun 2023
19 points (100.0% liked)
Technology
37712 readers
248 users here now
A nice place to discuss rumors, happenings, innovations, and challenges in the technology sphere. We also welcome discussions on the intersections of technology and society. If it’s technological news or discussion of technology, it probably belongs here.
Remember the overriding ethos on Beehaw: Be(e) Nice. Each user you encounter here is a person, and should be treated with kindness (even if they’re wrong, or use a Linux distro you don’t like). Personal attacks will not be tolerated.
Subcommunities on Beehaw:
This community's icon was made by Aaron Schneider, under the CC-BY-NC-SA 4.0 license.
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I mean, if you already have nginx OR apache, you could set up a vhost with the other domain name and do a proxy_pass or similar thing to the other one?
They don't need to be the same host software, you'd just need to configure one of them to know how to route it to the other instance. It's just plain HTTP(s) after all.
Reverse proxying is a feature in both nginx and apache after all. Though I'd recommend using nginx for that.
OK ; this reply gets traction with me... YES; I can get either site up; right now the bitwarden.domain1.com is live, and the domain2.com isn't getting ports - but I could switch that around... making domain2.com active/live - then yer saying I could use apache2 vhosts to route bitwarden.domain2.com traffic to a different local IP? Thats exactly what would work easiest for me - I can figure out apache2 vhosts... only I only have experience routing to two sites on the ONE apache2 instance; if I can pass that bitwarden.domain1.com traffic to an external local IP [another proxmox VM running the bitwarden container] that would be perfect.
You could use apache2 vhosts to route bitwarden.domain2.com traffic to wherever the heck you want. Even to another server on the internet.
Think of a vhost as uh... another set of apache server configuration that ONLY applies if the incoming traffic is for that domain/hostname.
That's determined by the Host header in the request, or the TLS SNI value if you're using HTTPS.
Then in that vhost, you'd just configure it like you would any apache instance, like say, for the root location, have it do a proxy_pass, etc.