Five-Click Path: Building Admin Navigation for FRP Tunnel Management

Building the Tunnels Dashboard: A Five-Step Navigation Strategy

The borisovai-admin project needed a critical feature: visibility into FRP (Fast Reverse Proxy) tunnels. The task seemed straightforward at first—add a navigation link to four HTML files—but unfolding it revealed a full-stack implementation plan that would touch server endpoints, a new dashboard page, and installation scripts.

Here’s how the work actually unfolded.

The Navigator’s Problem

The codebase had four HTML files serving as navigation hubs: tokens.html, projects.html, index.html, and dns.html. Each maintained identical navigation structures with links sitting at predictable line numbers (235–238, 276–279, 196–199, 216–219 respectively). The developer’s first instinct was mechanical—find, copy, paste. But then came the realization: if we’re adding a navigation link to tunnels, we need tunnels to exist.

This single observation cascaded into a five-stage implementation strategy.

The Plan Takes Shape

Stage one handled the immediate task: inserting the “Tunnels” link into each navigation section across all four files. Simple, but foundational.

Stage two tackled the backend complexity. Two new helper functions were needed in server.js: readFrpsConfig to parse tunnel configuration files and frpsDashboardRequest to communicate with the FRP daemon. Five GET endpoints would follow, exposing tunnel status, active connections, configuration details, and a critical feature—dynamic frpc.toml generation for clients.

Stage three introduced the visual layer. tunnels.html would become a dashboard with three distinct elements: a status card showing FRP server health, a live tunnel list with auto-updating capabilities (refreshing periodically without full page reloads), and a configuration generator letting users build client tunnel configs on the fly.

Stage four addressed the operational side. The install-all.sh script needed updating to make FRP an optional installation component, allowing teams to skip it if unnecessary.

Stage five documented everything in CLAUDE.md—the team’s knowledge vault.

Why This Matters

What struck during this planning phase was the cascading design principle: one UI element (a link) demanded five architectural decisions. Each decision locked down subsequent choices. The frpc.toml generator, for instance, had to match FRP’s configuration schema precisely, which meant the helper functions needed specific parsing logic.

The auto-refresh mechanism for active tunnels required careful JavaScript patterns to avoid memory leaks—a common pitfall when polling APIs repeatedly. The solution involved proper cleanup handlers and interval management, preventing the classic “create 100 timers and wonder why the browser slows down” scenario.

The Lesson

Frontend navigation feels trivial until you build the entire system it represents. The task expanded from “four edits” to “implement distributed proxy monitoring.” This isn’t scope creep—it’s discovery. The plan ensured nothing got overlooked, trade-offs were explicit, and the team could visualize the complete picture before a single line of backend code shipped.

Sometimes the shortest journey to a solution requires mapping the longest path first.

😄 Why did the FRP tunnel refuse to load? Because it had too many connections to make!