Can Two Reverse Proxies Share Ports 80 and 443 on One Home Server?

Not on the same IP and protocol at the same time unless one proxy is the single front door and forwards selected traffic to the other, or each binds a different IP.

This becomes a real compatibility question when two proxy containers both publish host ports 80 and 443 for separate app stacks on one machine. Start with a disposable path or account, keep the previous working state available, and judge the design by the original workload rather than by a one-time connection test.

Identify Who Owns the Shared Resource

The supported branch is one listener per IP-port pair with routing behind it. The competing branch is two independent listeners competing for the same socket. Record versions, identities, addresses, mount paths, permissions, and the current observable state before changing either branch.

The relevant socket binding rules defines the first compatibility boundary. Use it to constrain the claim, then verify the same behavior on this exact home server instead of treating a documented feature as proof that the full design works.

Write the decision rule before testing: success must produce only the intended front proxy owns each public socket and every hostname reaches the correct upstream with the expected certificate; failure includes startup reports address in use, traffic reaches the wrong proxy, or TLS terminates with another site's certificate. This prevents a partial connection or clean command exit from being misread as end-to-end compatibility.

Change One Listener or Route at a Time

Use one controlled discriminator: list current listeners, bind each proxy to a distinct test IP or move one behind the other, then test Host, SNI, WebSocket, and certificate routing. Hold the client, workload, file set, account, and timing constant so the changed component is the only plausible explanation.

Use published port behavior to choose the second observation that matters for this path. Capture both sides of the transaction: resolver or route, negotiated protocol, process identity, exit status, latency, transferred bytes, and any recovery event.

Repeat the test after the lifecycle event named in the title—recreation, reconnect, remount, restart, failover, or client change. A design that works only while old sockets, caches, or credentials remain warm has not passed.

ss -ltnp '( sport = :80 or sport = :443 )'
docker ps --format '{{.Names}} {{.Ports}}'

Use Observable Routing Evidence to Decide

PASS: only the intended front proxy owns each public socket and every hostname reaches the correct upstream with the expected certificate. Save the exact versions and topology that produced this state, because the conclusion applies to those conditions rather than every implementation of the protocol.

FAIL: startup reports address in use, traffic reaches the wrong proxy, or TLS terminates with another site's certificate. Check shared dependencies such as DNS, MTU, identity, firewall state, storage latency, and cached sessions before declaring either primary branch responsible.

EXCEPTION: stop the second public bind, restore the last working listener, and choose one front door or separate host addresses. Do not widen privileges, delete source data, weaken transport security, or replace working storage until a repeatable observation identifies which boundary failed.

Featured

ZimaCube 2 Personal Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Recheck Isolation Before Production Traffic Returns

Apply only the action matched to the observed branch, then rerun the original workload. Keep the design only when only the intended front proxy owns each public socket and every hostname reaches the correct upstream with the expected certificate across two relevant lifecycle cycles and under the expected concurrent load.

Use the dedicated proxy networks to verify the closest dependent workflow. Its access, timing, and recovery behavior must remain unchanged while the new design is active.

Stop and return to the saved state if startup reports address in use, traffic reaches the wrong proxy, or TLS terminates with another site's certificate. Escalate with timestamps, exact versions, route or mount evidence, and the smallest reproduction rather than adding another workaround.

Cross-check the result against the reverse-proxy DNS overrides so risk is not merely moved into another network, identity, backup, or storage layer.

For dual reverse-proxy port ownership, the qualified answer is therefore the opening judgment—not an unconditional yes. The observable pass state is the acceptance line; the fail state is the rollback line.

FAQ

Can SO_REUSEPORT let unrelated proxies share 443?

It is not a safe hostname-routing design for independent proxies; use one TLS front door or separate IPs.

Can one proxy pass TLS through to the second?

Yes when routing is based on SNI and the downstream proxy owns certificate termination for that hostname.

Do IPv4 and IPv6 listeners conflict?

They can, depending on dual-stack socket behavior and bind addresses; inspect both protocol families explicitly.