Immich Opens Locally but Fails Remotely After a Router Change

If Immich still opens on your home Wi-Fi after a router change but fails from mobile data, the server is probably healthy and the changed layer is the remote path around it.

A replacement or reset router can change the server’s LAN address, erase port-forwarding rules, obtain a different public IP, alter DNS behavior, or put the connection behind a different NAT mode. Start with a true outside-network test and work from the server outward. Change one layer at a time; opening extra ports before you know which hop failed can add exposure without restoring access.

Prove That the Failure Is Remote-Only

First, test Immich from a device on the same LAN using the server’s current local address. Then turn Wi-Fi off on a phone and repeat the remote test over cellular. If local access fails too, stop treating this as a router-edge problem and repair the server or local network first.

If local access works and remote access fails, record the exact remote hostname, protocol, and error you see. A timeout means something different from a certificate warning or a proxy error page. Also note whether you use direct port forwarding, a reverse proxy, a mesh VPN, or a tunnel, because a router replacement affects those models differently.

Do not use the same home Wi-Fi as your only remote test. Some routers handle internal requests to the public hostname through hairpin NAT and others do not, so a LAN test can produce a false failure or false success. The exit from this stage is a clean symptom: local Immich works, while one defined external path fails.

Check Whether the Router Still Sends Traffic to the Same LAN Target

A new router often hands the Immich host a different private IP. Compare the server’s current LAN address with the target stored in any port-forward, reverse-proxy upstream, firewall object, or DHCP reservation. If the rule still points at the old address, correct that mapping before touching Immich.

Recreate only the inbound rule your chosen access design actually needs. Verify the external port, internal target, internal port, and protocol as a single tuple. If you use a reverse proxy, the router normally forwards to the proxy rather than directly to Immich; forwarding both can create a second, unnecessary public path.

After correcting the target, test from cellular again and inspect whether the proxy or server logs see the request. If logs remain completely quiet, traffic is still dying before the application. If the request now reaches the proxy or host but returns an application error, the router edge is probably fixed and the next section should focus on public addressing or name resolution.

Compare the Public IP, DNS Record, and NAT Mode

Router replacement can coincide with a new WAN lease. Resolve the hostname you use for Immich and compare that result with the public IP currently assigned to your home connection. If they differ, the name is sending clients to the old endpoint even though every local service is healthy.

Dynamic DNS keeps a hostname aligned with a changing public address. If the hostname still resolves to the old WAN address, external clients continue to reach the wrong destination until the record and relevant caches update. Check how dynamic DNS tracks changing IPs, correct the updater or record, and then test again from an external resolver and cellular data.

If the router’s WAN address does not match the public address seen from the internet, the new connection may sit behind carrier-grade NAT or another upstream NAT layer. With NAT between peers and the public internet, changing a home-router port-forward may never make the service reachable. In that branch, use a public address, a VPN/overlay path, or another access method that does not depend on unsolicited inbound forwarding.

-15% OFF

ZimaBoard 2 - Mini Home Server for Your Big Idea

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verify Reverse-Proxy, TLS, and Firewall State After the Network Change

If external traffic reaches the host but Immich still does not open, check the identity layers the router does not manage. Confirm the reverse proxy still points to the current Immich address and port, the hostname matches the proxy route, and the server firewall allows the intended path from the new LAN subnet.

A domain that reaches the wrong proxy site, loops through redirects, or shows a certificate-name error is no longer a simple port-forwarding problem. Keep the working IP path and failing hostname path separate while you inspect DNS, SNI, Host routing, and any configured public URL. Do not regenerate certificates blindly when the hostname still resolves to the wrong public address.

For a broader decision tree, separate local reachability from public-path failures before repeating server-side fixes. Once local Immich is proven healthy, a router change narrows the investigation to addressing, NAT, DNS, firewall, proxy, and TLS state.

Re-Test From Outside and Choose the Smallest Safe Access Path

Once one cause is corrected, repeat the original test from cellular data using the same hostname and client. Then restart the router once and reboot the Immich host once. The fix is durable only if the server keeps the expected LAN target, DNS still resolves correctly, and remote access returns without manual intervention.

If you rely on direct inbound exposure, verify that only the intended HTTPS path is public and that old temporary rules are removed. For family-only access, a mesh VPN or authenticated tunnel can reduce dependence on port forwarding and changing public addresses, especially when the new router or ISP path is difficult to control.

Stop escalating network changes when requests reliably reach the correct proxy or Immich endpoint and the original client works again. If local access remains healthy but no external packets ever reach your router despite a correct public/DNS path, involve the ISP or switch access models; that is a network-boundary problem, not a reason to rebuild Immich.