Cannot reach LuCI: IP, port, DHCP and console recovery

Outcome

Tell whether the problem is the physical link, client address, management IP, HTTP service, or SSH/firewall.
Decide whether LuCI is actually listening without changing configuration.
Recover with a static client address, console, or failsafe instead of a blind factory reset.
Know when to stop, back up, or read the device documentation.

Triage table

Symptom	Check first	Do not do first
No link LED	cable, LAN port, power	reflash firmware
Client has 169.254.x.x	DHCP/cable/LAN port	change router LAN
Ping works, web fails	80/443, uhttpd, firewall, HTTPS	factory reset
Ping fails	client subnet, management IP, VLAN/port	keep changing IPs
SSH works, LuCI fails	uhttpd/LuCI package/port	change network config
No console output	serial settings, video output, power	short pins/reflash blindly

Layer 1: physical port and link

ComputerUse a LAN port, not WAN

Connect to a port labeled LAN; the WAN port usually does not provide management access. Try another cable and another LAN port; check the LEDs and the client NIC state.

If the LED never lights: check power, cable and port before touching firmware.

ExpectedThe LAN LED is on and the client sees a link.

Layer 2: client address and gateway

ComputerConfirm the client is in the LAN subnet

Linux:

ip addr show
ip route

Windows:

ipconfig /all

macOS:

ifconfig
netstat -rn

A 169.254.x.x address means DHCP failed. Confirm cable/LAN first, then set a temporary static address:

IP: 192.168.1.2
Mask: 255.255.255.0
Gateway: 192.168.1.1

Use it only for login; do not collide with the router LAN address.

ExpectedThe client has 192.168.1.x or another known LAN address.

ComputerPing the gateway

ping 192.168.1.1

Replies: go to layer 3.
No reply: check the client subnet, LAN port, and whether the default address was changed.
Do not declare the device dead from a failed ping alone.

ExpectedIt replies, or you know the management IP is not 192.168.1.1.

Layer 3: was the management IP changed?

ComputerFind the real LAN address

Common sources:

device label/manual;
a saved config/screenshot;
the upstream router’s DHCP lease table, if reachable;
uci show network on the console;
a LAN address you changed yourself.

On your own subnet, inspect the ARP cache:

ip neigh

Do not scan an unknown network broadly, and do not guess a device from scan results.

ExpectedYou have at least two candidate addresses and test them.

Layer 4: HTTP/HTTPS and SSH

ComputerSeparate “ping works but web fails” from link failure

curl -v http://192.168.1.1/
curl -k -v https://192.168.1.1/
ssh [email protected]

HTTP and HTTPS both time out: uhttpd/LuCI is not listening, or the firewall blocks it.
HTTP 404/redirect: port/path/HTTPS configuration.
SSH works: debug services over SSH; do not change the LAN.

ExpectedYou know whether it is a port/service/protocol issue.

Router shellIf SSH works, inspect uhttpd and ports

netstat -lnp | grep -E ':80|:443|:22'
ps w | grep -E 'uhttpd|rpcd' | grep -v grep
logread -e uhttpd | tail -30
uci show uhttpd

If uhttpd is not running, try:

/etc/init.d/uhttpd restart

If it still fails, read the logs and firewall; do not restart the whole network repeatedly.

ExpectedYou know whether LuCI runs and 80/443 listen.

Router shellCheck whether the firewall blocks management

uci show firewall
logread | grep -i firewall | tail -20

If you just changed a firewall zone, restore the backup or fix it from the console; do not keep changing it without console access.

ExpectedLAN to router 80/443/22 is not accidentally blocked.

Layer 5: local console / failsafe

ConsoleConfirm the system is alive from the console

Use serial/HDMI/keyboard, IPMI, or a cloud console. Serial is often 115200 8N1, but check the device. If there is no output, verify the cable/baud/power first.

Once in:

ip addr show
ip route
uci show network
uci show dhcp
logread | tail -50

ExpectedYou see a login prompt or kernel log.

ConsoleUse failsafe only when needed

Failsafe button timing is device-specific; follow the OpenWrt device page/vendor manual. Once in, inspect first:

uci show network
uci show dhcp

If only the LAN address is wrong, change it back and reboot after verifying. If unsure, record/back up the config first; do not run firstboot. A factory reset erases configuration.

ExpectedYou can restore LAN/DHCP without a factory reset.

Recovery order

Change nothing: cable/LAN port/static client address.
Ping works, web fails: uhttpd/firewall/HTTPS.
SSH works: debug services over SSH; do not change LAN.
No SSH: console/failsafe.
Factory reset last: confirm no important config/backup, and know you must reconfigure WAN/LAN/Wi-Fi.

Common misdiagnoses

Using the WAN port as management.
The client still has an old subnet/static IP.
The browser forces HTTPS while LuCI is HTTP.
Assuming LuCI is healthy because ping works.
Changing the LAN address without updating DHCP/gateway.
A firewall rule blocks LAN management.
uhttpd is missing/removed, but the network is restarted repeatedly.

E2 lab run (2026-10-20)

Environment: OpenWrt 25.12.6 x86 VM 200; LAN 192.168.1.2; HTTP checked from the PVE host.
/etc/init.d/uhttpd stop: curl to http://192.168.1.2/ returned http=000 (connection failed); SSH stayed available.
/etc/init.d/uhttpd start: HTTP returned 200.
Not tested: firewall drop, uhttpd port change, missing LuCI package, real serial/failsafe key sequence.
Recipe: tests/recipes/troubleshooting-no-web-ui.md.

E2 status and sources

This is E2 partial: uhttpd stop/recover and SSH retention were tested; firewall, port and failsafe remain documentation.
Decide whether it is link, address, uhttpd or firewall first; do not factory-reset instead of layering the diagnosis.
Console/failsafe procedures differ by device/firmware; read the device docs first.

Sources

Router.Homes

Independent OpenWrt notes. Every page states the firmware, device, package manager and way back.

Icons: Solar by 480 Design, CC BY 4.0