When configuring port forwarding, local DNS (Pi-hole/AdGuard), or self-hosted homelab services, guessing whether your router lives at 192.168.1.1 or 192.168.0.1 in a browser is the slowest way to debug your network.
Between multi-hop mesh systems, ISP-enforced Carrier-Grade NAT (CGNAT), and browser HSTS policies forcing HTTPS on unencrypted local web servers (uHTTPd / lighttpd), standard browser logins frequently fail with ERR_CONNECTION_REFUSED or ERR_ADDRESS_UNREACHABLE.
Here is how to query your exact default gateway via the command line across every major OS, inspect whether the router's management port is actually listening, and resolve common subnet collisions.
1. Extract the Live Default Gateway via CLI
Instead of guessing the subnet, pull the active routing table directly from your network interface.
Linux (iproute2)
Modern Linux distributions have deprecated net-tools (ifconfig/route). Use ip route to grab the active gateway in a single pipe:
ip route show default | awk '{print $3}'
If you have multiple active interfaces (e.g., Docker bridges, WireGuard, or Tailscale interfaces), filter specifically by the interface routing traffic to external DNS:
ip route get 1.1.1.1 | awk '{print $3; exit}'
macOS (BSD netstat / route)
On macOS, query the default route directly from the routing table:
route -n get default | grep 'gateway' | awk '{print $2}'
Windows (PowerShell & CMD)
Avoid scrolling through walls of virtual adapter outputs in ipconfig. In PowerShell, pull only the active IPv4 gateway:
(Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Sort-Object RouteMetric | Select-Object -First 1).NextHop
2. Default Subnet & Fallback Matrix by Hardware Vendor
When you connect a secondary router behind an ISP ONT or cable modem, the downstream router's firmware detects an IP collision on 192.168.1.0/24 and automatically shifts its LAN DHCP pool to a secondary fallback subnet.
| Hardware Vendor / OS | Primary Subnet Gateway | Auto-Shift Fallback IP | Local DNS / mDNS Hostname |
|---|---|---|---|
| TP-Link (Archer / Omada / Deco) | 192.168.0.1 |
192.168.1.1 / 192.168.68.1
|
[http://tplinkwifi.net](http://tplinkwifi.net) |
| Netgear (Nighthawk / Orbi) | 192.168.1.1 |
10.0.0.1 |
[http://routerlogin.net](http://routerlogin.net) |
| ASUS (ASUSWRT / Merlin) | 192.168.50.1 |
192.168.1.1 |
[http://router.asus.com](http://router.asus.com) |
| Ubiquiti (UniFi OS / EdgeRouter) | 192.168.1.1 |
192.168.2.1 |
[https://unifi.ui.com](https://unifi.ui.com) |
| MikroTik (RouterOS) | 192.168.88.1 |
None (WinBox MAC Login) | N/A |
| OpenWrt / pfSense / OPNsense | 192.168.1.1 |
Manual CLI assignment | [http://openwrt.lan](http://openwrt.lan) |
| ISP Gateways (Xfinity / Arris) | 10.0.0.1 |
192.168.100.1 (Modem Docsis) |
N/A |
For legacy hardware, regional ISP fiber gateways, or model-specific default credentials, you can search the full RouterIPGuide Default Gateway Database or pull the raw .csv and .json files from our open-source GitHub reference repo.
3. Test Whether the Web GUI Daemon Is Actually Listening
If you know the gateway IP is correct because ping succeeds, yet your browser throws ERR_CONNECTION_REFUSED, the router's ICMP stack is alive, but its internal HTTP/HTTPS web server may be hanging, running on a non-standard port, or blocking you via HSTS.
Bypass your browser completely and inspect the headers using curl:
# Test standard HTTP (Port 80) and follow redirects
curl -I -L http://192.168.1.1
# Test self-signed HTTPS (Port 443) ignoring SSL certificate errors
curl -I -k https://192.168.1.1
If both ports 80 and 443 return Connection refused, run a quick port scan on the gateway to check if the vendor moved the admin interface to port 8080 or 8443:
nmap -p 80,443,8080,8443 192.168.1.1
4. Resolving fe80:: Link-Local Gateways & Double NAT Lockouts
Two edge cases frequently break local gateway access even when using the CLI:
-
IPv6 Link-Local Only (
fe80::1%eth0): Some ISP gateways disable IPv4 DHCP temporarily during firmware provisioning or Dual-Stack Lite (DS-Lite) transitions, leaving only an IPv6 link-local gateway in your routing table. - Bridge Mode / AP Isolation: When a router is placed in Access Point (AP) mode, its routing engine is disabled and its management GUI moves to a dynamically assigned DHCP address leased by the upstream router.
If your terminal only returns an fe80:: address, or if your gateway is locked behind a Double NAT / AP-mode conflict, follow the Router Login Diagnostic & Subnet Conflict Guide to scan the active ARP table and recover local admin access without factory resetting your network config.
Top comments (0)