DEV Community: A.z

The hardest part of my NAS dashboard was getting traffic to reach it

A.z — Fri, 09 Oct 2026 10:27:49 +0000

I built NAS Device Flow to choose which devices on my home Wi-Fi use rule-based proxy routing. The daily interaction is a switch beside each device. Shipping the first regular release, 0.1.0, made me spend more time on the path to that switch: installation, DHCP leases, and making the page explain what it actually knows.

The screenshot is a demo, with fictional devices and generated traffic.

A switch cannot repair an old gateway

The NAS runs a Linux controller and a separate Mihomo routing container. My Wi-Fi router remains the access point and upstream Internet router. For automatic onboarding, NAS DHCP advertises the routing container as the client's gateway and DNS server.

A client can retain its old gateway until it renews its DHCP lease. In my original deployment, a tablet needed to forget the Wi-Fi network and rejoin before it picked up the new configuration. Turning its proxy switch on did not change the gateway stored on the tablet.

That is why the panel separates a saved routing preference from observed gateway activity. A valid lease means the client received configuration. A sampled connection means the core saw traffic. Neither proves that a proxy request succeeded.

An address that looks tidy can still be taken

An installer can read the host interface, subnet and default route. It cannot establish that an arbitrary address is free just because a device did not answer ARP. A sleeping printer, a static assignment or a DHCP reservation can still conflict later.

In 0.1.0, I removed prefilled guesses for the core IP, panel IP and future DHCP range. Those fields start empty. Each has an explanation, and the operator checks router reservations and static devices before entering them. Validation catches invalid ranges and responsive conflicts, but does not turn silence into proof.

The two static addresses have different jobs. The core IP becomes the clients' gateway and DNS address. The panel IP opens the management page. The future DHCP pool supplies client addresses and must exclude the router, NAS, core, panel and other fixed devices. Installation leaves DHCP off; enabling it is a separate step after a single-client routing test and disabling the other DHCP servers.

Test from the client that will use the page

The temporary installer opens at the NAS management IP on port 9088. The production panel has its own macvlan address.

Linux macvlan restricts direct host-to-container communication. A failed test from a browser running on the NAS can be misleading. The installation guide now explicitly asks for a test from another device on the same LAN. Changing the NAS gateway to work around that test can create another problem.

What shipped

The main panel still puts devices first: direct or smart routing per device, upload/download charts, sampled proxy traffic in decimal MB, and subscription controls tucked away from the everyday switches. It now supports Chinese, English, Japanese, Spanish, French and Korean, plus system, light and dark appearance. The installer is Chinese/English.

The release includes a prebuilt Linux x86-64 controller image and a NAS Compose installation file. I checked 105 automated tests, container startup and isolated DHCP exchanges in CI. The image and downloadable attachments have verified checksums. Router name provenance also follows the configured adapter instead of falling back to Huawei when a source is absent.

The original deployment runs on a UGREEN DXP4800. Fresh full-LAN installations on other NAS hardware remain unverified; OpenWrt and MikroTik naming adapters have simulated tests only. This is IPv4, with no automatic gateway failover. Docker Desktop on macOS or Windows is not a supported gateway host. The included regional routing preset targets mainland China and needs review for other regions.

Source and release · NAS installation guide

I would like feedback on how the installer explains the network changes, especially where a label might suggest more certainty than the program has. That has been a useful lesson from building this: a simple switch still needs an honest description of the network underneath it.

This article and the implementation were developed with substantial Codex assistance under my direction. Automated tests are not an independent security audit.

I built a NAS dashboard for per-device smart routing

A.z — Thu, 08 Oct 2026 13:47:52 +0000

I wanted to choose which devices on my home Wi-Fi use rule-based proxy routing, without installing a client on every phone or changing network settings each time. That became NAS Device Flow, a small self-hosted dashboard running on my NAS.

The main screen puts devices first. Each device has a switch: enable it to apply the configured routing rules, or disable it for direct access. Traffic charts are visible at the top; subscription management lives in settings so it does not get in the way of the everyday task.

This screenshot uses fictional devices and generated traffic. Update, October 9, 2026: 0.1.0 is now the first regular release, within the documented hardware and network scope.

How the traffic reaches the NAS

My Wi-Fi router remains the access point and upstream router. The NAS runs a Linux gateway container and a controller, with Mihomo handling the proxy rules. For automatic onboarding, DHCP supplies the NAS gateway and DNS address to clients. Existing clients need to renew their leases before they follow those settings.

That last sentence turned out to matter. One tablet kept its old gateway after the DHCP change. Toggling a dashboard switch could not fix a lease that still pointed somewhere else. The release now includes an explicit opt-in authoritative DHCP mode for deployments where this is the only DHCP server, and tests for an old lease being rejected and replaced with the correct gateway and DNS. The upstream router's DHCP must be disabled first in that mode.

A device with its switch enabled still follows the configured rules. It does not send every connection through a proxy. The included regional preset is intended for mainland China, with domestic destinations direct and other matching destinations proxied; users elsewhere should review and adapt it.

Remembering devices

The controller uses MAC addresses to retain device choices. DHCP leases, neighbor information and optional router adapters help discover devices and supply names. You can give a device a friendly name when discovery has no useful answer.

Returning with the same MAC preserves its choice even if its IP changes. A rotating private Wi-Fi address becomes a new device record. Two devices with the same hostname are not automatically merged. The setting for newly discovered devices defaults to direct access and only affects new records.

There is a Huawei adapter tested against my hardware. OpenWrt and MikroTik adapters currently have mock coverage, not hardware validation. Device names are useful labels, not a guarantee that the dashboard knows the exact model of every client.

Making the dashboard useful day to day

Besides the device switches, it shows upload and download rates, sampled proxy traffic beside each device, subscription controls, and basic gateway information. The interface supports Chinese, English, Japanese, Spanish, French and Korean, with a manual language choice that is remembered in the browser.

The traffic counter uses decimal MB. It accumulates sampled connection deltas and saves checkpoints, so it is an operational estimate rather than a billing meter. The interface also separates a configured proxy choice from observed gateway activity: a switch alone is not proof that a device's traffic actually reached the gateway.

Local authentication includes a password-change flow that verifies the current password and invalidates existing sessions after a successful change.

What is ready, and what still needs work

The current v0.1.0 release has 105 automated tests. CI also checks container startup and an isolated Linux DHCP renewal path. My deployment runs on a UGREEN DXP4800, but a fresh installation across other NAS models and router combinations still needs validation.

The gateway requires Linux and macvlan networking. Docker Desktop on macOS or Windows is not a supported gateway host; those systems can use the web interface. IPv6 routing and automatic gateway failover are not implemented. If the NAS is your gateway, its availability matters to the devices using it.

The controller is MIT-licensed. Mihomo and other dependencies retain their own licenses.

Source, installation instructions and limitations

I would appreciate feedback on the device workflow, DHCP migration and naming adapters. In particular, I want the panel to make it easy to tell the difference between a saved preference and traffic that is actually using the gateway.

This article was prepared with AI assistance and checked against the project's documented behavior and tests.