Hello All,

I have a problem, for which I need some guidance..... Here is the scenario.

Internet --> Router --> [my required s/w ?!?!] --> 3 web servers.

the router which I have has limited capabilities. It can jus forward incoming requests only IP based, and not even to to any specific ports...So thats a bottleneck.

To overcome this, I plan to use a very very minimal linux VM, that will take in requests from this router and forward to 3 or more web servers behind.

my required s/w, functionality must be like this..
if the incoming request is for...
a.mysite.com goto ServerA at port x1
b.mysite.com goto ServerA at port x2
c.mysite.com goto ServerB at port x3
.... so on...

I hope u get an idea.

Now, I am not an advanced user of Linux, and a networking expert either. So please be kind...

I can do this with Apache vhosts thing, but I prefer to run separate apache servers, to avoid single point of failure.

I was looking at these router and firewall linux distro's.... (very fascinating), to get my job done, but I don't think they have exactly what I look for....I tried (monowall, smoothwall, untangle, zeroshell..etc) or maybe, I didn't look at the right place.

Or I was wondering if squid proxy wud do this job for me. If yes, I have no clue on how to write the directives...an example wud be gr8....

If u have any better ideas, I am all ears....

Thank You

Antonio....

Dani AI

Generated

As others in the thread already suggested, the cleanest solution is to run a small Linux VM as an HTTP(S) reverse proxy/content switch that accepts all traffic from the router and forwards to backend servers by hostname or URL path. That keeps each webserver running independently (no single Apache instance) while letting the proxy map Host headers and URIs to different internal IP:port combinations. (Thanks to for pointing to the reverse-proxy approach, for the Pound mention, and for the proxy idea.)

Two practical, commonly used choices:

  • nginx — simple, lightweight, excellent L7 routing and header handling; easy to map host/path -> backend.
  • HAProxy — more featureful for high concurrency, advanced health checks, stickiness and TCP passthrough (useful for some SSL scenarios).

Minimal examples (adapt backend IPs/ports to your network):

# nginx - host/path → backend ports
upstream appA { server 192.168.1.10:8080; }
upstream appB { server 192.168.1.11:8081; }

server {
  listen 80;
  server_name mysite.com;
  location / { proxy_pass http://appA; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; }
  location /app2 { proxy_pass http://appB; }
}
# HAProxy - host/path ACLs
frontend http-in
  bind *:80
  acl is_app2 path_beg /app2
  use_backend app2 if is_app2
  default_backend appA

backend appA
  server s1 192.168.1.10:8080 check

backend app2
  server s2 192.168.1.11:8081 check

Operational notes and cautions: the proxy itself is a potential single point of failure — run two proxies with VRRP/keepalived for a floating VIP if uptime is important. Decide SSL strategy: terminate at the proxy (simpler certificate management) or do SNI/TLS passthrough if backends must see original TLS. Ensure the proxy forwards client IPs (X-Forwarded-For or PROXY protocol) so logs on backend servers remain useful. Finally, add health checks on backends and firewall/NAT rules on the router so the VM receives the traffic to act as the content switch.

Recommended Answers

All 4 Replies

Thank You...Thank You...Thank You...Thank You...

That was ridiculously goooood......exactly what I was looking for...

Absolutely PERFECT!!!!

Thank u Again!!!!

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.