DEV Community: ChenXX

Measuring Throughput When the Subprocess Owns the Socket: A TCP Relay Pattern for Tauri Apps

ChenXX — Sun, 25 Oct 2026 08:26:37 +0000

If you have ever wanted a traffic graph for a tunnel client, you know the awkward part: the client usually owns the socket. You cannot wrap it, you cannot ask it, and its status endpoint is often a step-function of "connected" or not.

When I was building MoonProxy — a cross-platform GUI desktop client for FRP — I hit exactly this. frpc exposes an /api/status endpoint, and it is genuinely useful: it tells you whether the tunnel is up. What it does not expose is a single byte counter. Yet the whole point of a tunnel dashboard is answering "how much data is moving right now?"

This is a writeup of the pattern I landed on, because it generalizes well beyond FRP.

The constraint

The naive approach is to watch the process's network usage from the outside. On Linux that is /proc/<pid>/net/dev; on macOS and Windows it is a platform-specific call. All three have the same two problems:

They report traffic for the whole process, with no way to attribute bytes to a specific tunnel.
They report host-level interface counters, which include every other program on the machine.

For a desktop app whose entire purpose is to show you per-tunnel traffic, neither is acceptable. The user has five tunnels and wants to see them individually.

The trick: be the middleman

frpc's local proxy config points at a localIP:localPort where your service is listening. That address is just a string in a TOML file. If you own the process that writes that file, you can point it somewhere else.

So instead of:

frpc  ──────────────▶  127.0.0.1:8080   (your service)

you get:

frpc  ──────▶  127.0.0.1:53912  ──────▶  127.0.0.1:8080   (your service)
             (MoonProxy relay)          (your service)

MoonProxy opens a listener on an ephemeral port, rewrites localIP/localPort in the proxy config to point at it, and copies bytes in both directions while counting them.

The relay is a plain TCP proxy. It is not a protocol-aware proxy, it does not parse HTTP, and it does not care what is on the other end.

Counting bytes without `copy_bidirectional`

Tokio has tokio::io::copy_bidirectional, which is exactly the wrong tool here. It is efficient, it is correct, and it returns the total bytes moved in each direction at the end — but only at the end. For a live dashboard you want running totals you can sample at any instant.

The obvious substitute, tokio::io::copy, returns bytes copied too, but only when the stream closes. So the counter has to live somewhere that outlives the call.

I used a pair of atomic counters incremented inside the copy loop:

/// Single-direction copy: read, write, immediately accumulate the counter.
/// Equivalent to `tokio::io::copy` but with a live counter.
async fn copy_one_way<R, W>(
    rd: &mut R,
    wr: &mut W,
    counter: &AtomicU64,
) -> std::io::Result<u64>
where
    R: tokio::io::AsyncRead + Unpin + ?Sized,
    W: tokio::io::AsyncWrite + Unpin + ?Sized,
{
    use tokio::io::{AsyncReadExt, AsyncWriteExt};
    let mut buf = vec![u8; 8 * 1024];
    let mut total = 0u64;
    loop {
        let n = rd.read(&mut buf).await?;
        if n == 0 {
            return Ok(total);
        }
        wr.write_all(&buf[..n]).await?;
        total += n as u64;
        counter.fetch_add(n as u64, Ordering::Relaxed);
    }
}

fetch_add with Relaxed ordering is the right choice here. The counters are pure statistics — nobody reads them to establish a happens-before relationship with other memory — so paying for SeqCst fencing on every 8 KB chunk would be pure waste.

Running two directions concurrently

copy_bidirectional runs both directions at once and cancels whichever finishes first. Reproducing that with tokio::select! is straightforward:

async fn copy_bidirectional_counted<R1, W1, R2, W2>(
    user_rd: &mut R1,
    frpc_wr: &mut W1,
    in_counter: &AtomicU64,
    frpc_rd: &mut R2,
    user_wr: &mut W2,
    out_counter: &AtomicU64,
) -> (u64, u64)
where /* ... */ {
    let in_task = copy_one_way(user_rd, frpc_wr, in_counter);
    let out_task = copy_one_way(frpc_rd, user_wr, out_counter);
    tokio::pin!(in_task);
    tokio::pin!(out_task);

    let mut in_bytes = 0u64;
    let mut out_bytes = 0u64;
    loop {
        tokio::select! {
            res = &mut in_task => {
                if let Ok(n) = res { in_bytes += n; }
                break;
            }
            res = &mut out_task => {
                if let Ok(n) = res { out_bytes += n; }
                break;
            }
        }
    }
    (in_bytes, out_bytes)
}

The tokio::pin! calls matter: without pinning, the two futures are dropped at the end of the select! arm and the surviving copy task is cancelled mid-stream.

Note the direction convention. I deliberately count in terms of the end user's perspective rather than the process's:

user_conn → frpc_conn = the user's service uploading = in (up)
frpc_conn → user_conn = the user's service downloading = out (down)

Getting this backwards is the classic mistake in this kind of tool. A user watching their NAS upload a backup should see the up arrow move, not the down arrow.

Connection counting with an RAII guard

Counting open connections is where an early-return bug really bites. Every path out of the connection handler has to decrement, and there are a lot of them — a failed TcpStream::connect, a read error, a write error, a panic in the copy loop.

Rather than hand-decrementing at each exit, use a guard whose Drop does it:

/// Connection-count RAII guard: +1 on construction, -1 on drop,
/// so every exit path (early return, error, panic) stays balanced.
struct ConnGuard<'a>(&'a AtomicI64);

impl ConnGuard<'_> {
    fn new(c: &AtomicI64) -> Self {
        c.fetch_add(1, Ordering::Relaxed);
        Self(c)
    }
}

impl Drop for ConnGuard<'_> {
    fn drop(&mut self) {
        self.0.fetch_sub(1, Ordering::Relaxed);
    }
}

Then the handler body is short enough to audit at a glance:

async fn handle_relay_conn(mut frpc_conn: TcpStream, entry: Arc<RelayEntry>) {
    let mut user_conn = match TcpStream::connect(&entry.upstream).await {
        Ok(s) => s,
        Err(_) => return,
    };
    let _guard = ConnGuard::new(&entry.connections);

    let (mut frpc_rd, mut frpc_wr) = frpc_conn.split();
    let (mut user_rd, mut user_wr) = user_conn.split();
    copy_bidirectional_counted(
        &mut user_rd, &mut frpc_wr, &entry.in_bytes,
        &mut frpc_rd, &mut user_wr, &entry.out_bytes,
    ).await;
}

The guard is declared after the connect succeeds, which is important: a failed connection never became a connection.

Deriving a rate from a cumulative counter

The counters are monotonic totals. The UI wants bytes per second. There are two ways to get there, and the difference matters.

Bad: sample the counter, and treat the delta as the rate. This produces a value that is really "bytes in the last interval," and it aliases badly — a single 2 MB chunk arriving between two samples reads as either 2 MB/s or 0 B/s depending entirely on where the sampling boundary lands.

Better: keep the previous sample and difference it explicitly.

// Swap-and-difference: the previous value is read and replaced atomically.
let last_in = state.last_in_bytes.swap(total_in, Ordering::Relaxed);
let last_out = state.last_out_bytes.swap(total_out, Ordering::Relaxed);
let in_rate = total_in.saturating_sub(last_in);
let out_rate = total_out.saturating_sub(last_out);

swap is the important detail. It reads and writes in one atomic operation, so two concurrent samplers can never interleave into a corrupted "last value." saturating_sub handles the reset case (the tunnel restarted and the counter went back to zero) without underflowing into a 17-exabyte "negative" rate.

With a 1-second sampling tick, the difference is bytes per second, which keeps the arithmetic in the backend trivially simple and leaves the frontend to do nothing but plot.

Wiring it to the frontend

The backend samples once per second and emits an event:

pub async fn poll_traffic(app: AppHandle, start_gen: u64) {
    const TICK: Duration = Duration::from_secs(1);
    loop {
        tokio::time::sleep(TICK).await;
        let state = match app.try_state::<crate::frpc_state::FrpcState>() {
            Some(s) => s,
            None => break,
        };
        // A new start/stop cycle invalidates this sampler.
        if state.poll_gen.load(Ordering::Acquire) != start_gen {
            break;
        }
        let payload = {
            let guard = state.relay.lock().await;
            match guard.as_ref() {
                Some(r) => sample(r, &state).await,
                None => break,
            }
        };
        let _ = app.emit("frpc://traffic", payload);
    }
}

Two details here are easy to get wrong:

The generation counter. Without poll_gen, an old sampler keeps running after a new tunnel starts, and you end up with two samplers emitting interleaved traffic events. The frontend would show a sawtooth pattern that looks like a network problem but is actually two samplers fighting.

poll_traffic must be spawned, not awaited. It is an infinite loop. Awaiting it inside a #[tauri::command] would hang the command forever and the start button would appear to hang with it. Wrap it:

tauri::async_runtime::spawn(poll_traffic(app, gen));

The frontend side is then almost trivial, because the backend already did the differencing:

export function handleTrafficPayload(p: TrafficPayload) {
  totalInBytes.value = p.total_in_bytes;
  totalOutBytes.value = p.total_out_bytes;

  const now = Date.now();
  const snapshot: TrafficSnapshot = {
    timestamp: now,
    in_rate: p.in_rate,
    out_rate: p.out_rate,
    connections: p.connections,
  };
  latestTraffic.value = snapshot;

  // Keep a fixed-size rolling window for the chart.
  const next = trafficHistory.value.concat(snapshot);
  if (next.length > WINDOW_SIZE) {
    next.splice(0, next.length - WINDOW_SIZE);
  }
  trafficHistory.value = next;
}

WINDOW_SIZE is 60, matching the 1-second backend tick — a 60-point rolling window is one minute of history, which is long enough to read a trend and short enough that the chart stays responsive.

Rewriting the client's config

The last piece is the part that makes the whole trick work: pointing frpc at the relay instead of at the user's service.

// Bind an ephemeral port on loopback.
let listener = match TcpListener::bind(("127.0.0.1", 0u16)).await {
    Ok(l) => l,
    Err(e) => {
        crate::frpc_state::emit_log(app, "system", format!("中转端口绑定失败，跳过 {name}：{e}"));
        continue;
    }
};
let relay_port = match listener.local_addr() {
    Ok(a) => a.port(),
    Err(_) => continue,
};

// Rewrite THIS proxy's localIP/localPort to the relay.
match p {
    ProxyConfig::Tcp { local_ip, local_port, .. }
    | ProxyConfig::Http { local_ip, local_port, .. }
    | ProxyConfig::Https { local_ip, local_port, .. } => {
        *local_ip = "127.0.0.1".to_string();
        *local_port = relay_port;
    }
    ProxyConfig::Udp { .. } => { /* unreachable: UDP is skipped above */ }
}

Two deliberate decisions:

Loopback only. The relay binds 127.0.0.1, never 0.0.0.0. The relay is an internal implementation detail; exposing it on a routable interface would create a new, unintended entry point into the user's local network.

UDP is skipped. The relay is TCP-only because it is implemented as a byte stream. UDP would need a separate, connectionless path. Rather than half-implement it, MoonProxy passes UDP proxies through untouched — they simply do not appear in the traffic graph.

Binding to port 0 and asking the OS for an ephemeral port is also worth calling out: it avoids a port collision with a user's actual service, which a fixed port would eventually cause.

Cleanup

Stopping the tunnel has to tear down the listeners. Because each accept loop owns its TcpListener, aborting the task closes the socket:

pub async fn stop_relay(state: &RelayState) {
    let mut entries = state.entries.lock().await;
    for (_, entry) in entries.drain(..) {
        if let Some(h) = entry.accept_task.lock().await.take() {
            h.abort();
        }
    }
}

In-flight connections end on their own: their copy loop hits a read or write error when the peer goes away, and the ConnGuard drops on the way out, so the connection count returns to zero without any explicit bookkeeping.

What this buys you

Per-tunnel byte counts, attributed exactly, with no host-level guessing
Rates that survive a slow network because they are differenced from cumulative totals
A connection count that is correct on every exit path, including panics
No changes to the tunnel client itself — you only rewrite where it points

The pattern is not FRP-specific. Any time a subprocess owns the socket and you want to observe the traffic, you can insert yourself in the middle, count the bytes, and let the subprocess do what it was always going to do.

MoonProxy

MoonProxy is a free, open-source (MIT) cross-platform GUI desktop client for FRP, built with Tauri v2, Vue 3, and Rust. It bundles the frpc binary, so you do not need to install anything separately.

Repository: https://github.com/MoonProxyHQ/moonproxy-desktop
Homepage: https://moonproxy.app
Runs on macOS (Apple Silicon and Intel) and Windows x64

If this kind of low-level plumbing is your thing, the source is on GitHub and I am happy to answer questions about the details.

Tunneling From a Raspberry Pi: How FRP Actually Behaves on Low-Power ARM Hardware

ChenXX — Fri, 23 Oct 2026 08:18:57 +0000

A Raspberry Pi is the most common way people first meet FRP. You've got Home Assistant, a small web dashboard, maybe a Minecraft server for the kids — all sitting on the Pi, all needing to be reachable from outside the house.

So you install FRP on the Pi and expose it. Then you open a second terminal and think: is this really what I need every time? And whether you should run frpc from a config file, or a tray-based GUI client that assumes someone's sitting at the machine.

Here's what actually happens on real hardware.

The short version

FRP's client (frpc) is a single static Go binary. On a Pi it's cheap — it's a Go daemon with no runtime dependencies, near-zero CPU when idle, and it doesn't need a desktop environment. For a headless Pi you SSH into, frpc is genuinely the right tool and I'd keep using it.

The friction starts when the Pi isn't yours alone. Family members, a partner, or yourself two weeks later — now the SSH + edit + restart loop is the thing that costs time.

What the Pi actually costs you

The tunnel itself is cheap. The process management around it is what isn't:

It doesn't survive a reboot. Your SSH session is gone, so nothing restarts frpc unless you wrote a systemd unit.
It doesn't tell you it's dead. If frpc crashes, your public address just starts refusing connections, and you find out when a user complains.
Changing one port means editing TOML over SSH. Fine for you. Not fine for someone who isn't sure what localPort vs remotePort means.
There's no status you can glance at. On a headless box you'd run systemctl status frpc or journalctl — which is a terminal, every time.

None of this is a criticism of FRP. frpc is a great tool. It's that the operating model assumes you live in a terminal, and a Pi sitting under a desk is precisely a machine nobody sits at.

The ARM reality check

People assume a GUI will be too heavy for a Pi. The tradeoffs to weigh:

	`frpc` (headless)	Tauri GUI client
Desktop required	No	Yes — needs a display
Survives reboot	Only via systemd	Native launch-at-login
Crash visibility	`journalctl`	On-screen state + health polling
Edit a tunnel	Edit TOML over SSH	Click
Memory	Modest — a static Go daemon	Higher — GUI + webview runtime

The important line in that table: a desktop GUI needs a desktop. A headless Pi with no monitor has no window to click into — in that case frpc + a systemd unit genuinely is the better engineering choice, and MoonProxy isn't meant to replace it.

MoonProxy runs on macOS and Windows, not Linux/Pi. So think of it as the answer for the machine that has a screen — your laptop, a desktop in the homelab, the box you actually sit down at — rather than for the Pi itself.

The pattern that actually works

The setup that's held up well across homelab setups:

The Pi keeps the service, and runs headless frpc — it's a single binary plus a systemd unit. Lean and scriptable.
The machine with a screen runs MoonProxy to manage tunnels in a form instead of a file.

You end up with one tunnel config in two places, which sounds like duplication — but in practice each side only owns the tunnels it actually needs, and you get both: unattended reliability on the Pi, and no-SSH convenience at the desk.

If you only have the Pi, keep using frpc. Nothing below changes that recommendation.

If you're on a Pi and tired of `journalctl`

Three options, roughly in order of how much I'd recommend them:

Write the systemd unit properly. Restart=always, RestartSec=5, and a WantedBy=multi-user.target. This is the fix that makes frpc boring in the best way. Smallest possible change.
Use a lightweight web UI for frpc if you genuinely want a browser interface on the Pi — that's a real category (see FRP's own docs and community projects).
Use MoonProxy on a machine that has a display if your tunnels mostly live on laptops/desktops rather than the Pi.

What this looks like in MoonProxy, concretely

On a machine with a screen, the tunnel is a form instead of a file:

Add a tunnel by filling fields — local port, remote port, type, token. No TOML, no syntax to get wrong.
Four-state start button — stopped / connecting / connected / error. "Connected" is derived from real frpc output, not an optimistic flag, so you can trust the green state.
Health polling every 3 seconds — it checks whether your local port is actually reachable, so you find out your service is down before the person using it does.
Tray-resident — close the window and the tunnel keeps running. Launch-at-login brings it back after a reboot.
Scheduled connect — set weekdays and a time window, so a dev tunnel isn't exposed at 3am.
Engine self-update — pulls new frpc releases, SHA256-verifies, and swaps the binary atomically without reinstalling the app.

You bring your own frps — MoonProxy is strictly the client side, and it doesn't relay your traffic through anyone's infrastructure.

Bottom line

On a Raspberry Pi, FRP works well and frpc is the correct tool. Don't reach for a GUI to solve a problem a systemd unit solves.

But if the machine that runs your tunnels is one you actually sit at — a laptop, a desktop — the GUI layer earns its place, because the thing it removes isn't complexity, it's SSH.

🌐 Website: moonproxy.app
💻 Source (MIT): github.com/MoonProxyHQ/moonproxy-desktop
⬇️ Releases: macOS (Apple Silicon + Intel) and Windows x64

If you've already run FRP on a Pi, I'd genuinely like to hear what numbers you got — CPU and memory on a Pi 4 vs a Pi 5 is exactly the kind of detail I'd like to add to the article. 👋

How to Put a Local Service on the Public Internet with FRP (Without Losing Your Mind Over Config Files)

ChenXX — Sat, 26 Sep 2026 08:06:31 +0000

The Problem

FRP's configuration looks like this:

[ssh]
type = tcp
local_ip = 127.0.0.1
local_port = 22
remote_port = 6000

[web]
type = http
local_port = 8080
custom_domains = myapp.example.com

Every time you add a service, you edit this file, save it, and restart frpc. For developers, it's manageable. For everyone else, it's a barrier.

What MoonProxy Does

MoonProxy wraps FRP's frpc into a native desktop app:

Visual configuration — Fill a form instead of editing INI files
One-click start/stop — Toggle tunnels without touching the terminal
Rule management — Manage up to 50 proxy rules in one window
Auto-reconnect — Automatically recoble after network interruptions
Cross-platform — macOS (Intel + Apple Silicon) and Windows
Dark mode — Easy on the eyes

Tech Stack

Layer	Technology
Frontend	Vue 3 + TypeScript
Backend	Rust
Framework	Tauri v2
Engine	frp (frpc)

The installer is ~5MB — a fraction of Electron-based alternatives.

Getting Started

Download MoonProxy from GitHub Releases
Install the app (DMG for macOS, EXE for Windows)
Configure your FRP server address and port
Add proxy rules for your local services
Start — that's it

Use Cases

Remote NAS access — Reach your home file server from anywhere
Dev preview — Share localhost projects with clients
Home automation — Access Home Assistant while traveling
Game servers — Host Minecraft or Valheim for friends
Self-hosted apps — Expose Jellyfin, Gitea, Vaultwarden, etc.

"Managing a CLI Subprocess from Rust: Lifecycle, Logs, and Graceful Shutdown (Tauri)"

ChenXX — Mon, 20 Jul 2026 08:02:46 +0000

Most "wrapper" apps do the same thing: launch a CLI binary in the background, pipe its logs into the UI, and tear it down when the user quits. It sounds trivial — until you actually build it.

I recently worked through this while building MoonProxy, a GUI desktop client that wraps the frp CLI (frpc). The Rust side has to own the full lifecycle of that child process: spawn it on demand, surface a ring buffer of its stdout/stderr to the frontend, detect "are we actually connected?" from log heuristics, stop it cleanly on window close, and restart it atomically when the binary updates itself on disk.

This post is the pattern that emerged. It's framework-aware (Tauri v2) but the core ideas apply to any Rust app that needs to babysit a long-running CLI.

The naive version (and why it bites you)

let mut child = Command::new("frpc")
    .args(["-c", "frpc.toml"])
    .stdout(Stdio::piped())
    .stderr(Stdio::piped())
    .spawn()?;

This compiles, runs, and is wrong in four ways you won't notice until production:

You never read the pipes. When the OS pipe buffer fills (~64 KB on Linux), the child process blocks on its next write and silently stalls. The app shows "starting…" forever.
No way to ask "is it healthy?" A spawned PID tells you the process exists, not that it's connected to the server.
On window close you call child.kill(). That sends SIGKILL (or TerminateProcess on Windows). The server side never sees a clean disconnect — its connection table leaks until a keepalive timeout.
You can't swap the binary while it's running. File is locked on Windows; replacing it in-place on macOS is a race.

Let's fix each.

1. Drain the pipes into a ring buffer

A dedicated reader thread per stream, writing into a fixed-size ring buffer that the frontend can poll:

use std::sync::{Arc, Mutex};
use std::collections::VecDeque;

pub struct LogRing {
    buf: Mutex<VecDeque<String>>,
    cap: usize,
}

impl LogRing {
    pub fn push(&self, line: String) {
        let mut g = self.buf.lock().unwrap();
        if g.len() == self.cap { g.pop_front(); }
        g.push_back(line);
    }
    pub fn snapshot(&self) -> Vec<String> {
        self.buf.lock().unwrap().iter().cloned().collect()
    }
}

fn spawn_reader<R: Read + Send + 'static>(stream: R, ring: Arc<LogRing>) {
    std::thread::spawn(move || {
        let reader = BufReader::new(stream);
        for line in reader.lines().flatten() {
            ring.push(line);
        }
        // stream closed = child exited
    });
}

Key point: the ring is unbounded-consumer, bounded-memory. Logs from a chatty CLI never OOM the app; the oldest line just rolls off. The frontend gets a get_logs() command that snapshots the current contents — cheap to call on a timer.

2. Health = evidence, not just "process exists"

child.try_wait() returning None means "still running." It does not mean "doing useful work." For an frpc-style client the interesting state lives in its own log output: it prints something like [I] [proxy.go:xxx] start proxy success when a tunnel is actually up.

So model the connection as a small state machine driven by log lines:

#[derive(Clone, Copy, PartialEq)]
pub enum FrpcState { Stopped, Connecting, Connected, Error }

pub fn classify(line: &str, current: FrpcState) -> FrpcState {
    if line.contains("login to server failed") || line.contains("token is incorrect") {
        FrpcState::Error
    } else if line.contains("start proxy success") && current == FrpcState::Connecting {
        FrpcState::Connected
    } else {
        current
    }
}

This matters because a running process with the wrong token will happily sit there retrying forever. You want the UI to show "Error: token rejected," not a fake green "Connected."

A 30-second fallback timer that flips Connecting → Error covers the case where the log never emits a decisive line (firewalled, DNS wedged, etc.).

3. Graceful shutdown: ask, then escalate

Don't go straight to kill(). On Unix, send SIGTERM and give it a beat to flush; on Windows, the equivalent is harder, so we lean on the CLI's own shutdown path if it has one.

pub async fn stop_gracefully(child: &mut Child, timeout: Duration) {
    // Prefer a clean path
    #[cfg(unix)]
    {
        use nix::sys::signal::{kill, Signal};
        let _ = kill(
            nix::unistd::Pid::from_raw(child.id() as i32),
            Signal::SIGTERM,
        );
    }
    #[cfg(windows)]
    {
        // Best-effort: on Windows we drop directly; for a well-behaved CLI
        // that traps the console close event this still lets it clean up.
    }

    // Wait up to `timeout` for it to exit on its own
    let start = Instant::now();
    while start.elapsed() < timeout {
        if let Ok(Some(_)) = child.try_wait() { return; }
        tokio::time::sleep(Duration::from_millis(100)).await;
    }
    // Escalate
    let _ = child.kill();
    let _ = child.wait();
}

In a Tauri app you also want to hook ExitRequested so that closing the window while a tunnel is up pops a confirm dialog (or, for "minimize to tray" mode, just hides the window and keeps frpc alive in the background — the whole reason the user installed a GUI client).

4. Atomic binary replacement

The problem: you want to update frpc from v0.69 to v0.70 without making the user reinstall the app, and without leaving a half-written file behind.

Pattern: download to a temp path → SHA256-verify → rename into place. Rename is atomic on the same filesystem.

// Pseudocode for the happy path
let tmp = bin_dir.join("frpc.new");
download_and_verify(&release_url, &expected_sha256, &tmp)?;

// Stop the running child FIRST (see §3), then:
fs::rename(&tmp, &final_path)?;   // atomic on same fs
// Restart on next "start" click, or auto-restart

The two things that bite you here:

Windows holds an exclusive lock on a running .exe. You cannot rename over it while the child is alive. The order is non-negotiable: stop → replace → start.
SHA256 before rename, not after. A truncated or MITM'd binary that "looks like" frpc but isn't would otherwise get swapped in silently. Verify the bytes you downloaded against a digest fetched over a trusted channel (the GitHub Release API + a pinned algorithm), then promote.

A frpc_update.json next to the binary tracks current / pending versions, so a crash mid-update is recoverable on next launch rather than leaving the user with a broken install.

5. The part Tauri adds on top

All of the above is plain Rust. Tauri's job is to (a) ship the binary inside the app bundle via the sidecar mechanism — tauri.conf.json declares it and the build renames the per-target binary to the sidecar convention (frpc-x86_64-pc-windows-msvc.exe, etc.) — and (b) expose invoke_handler commands so the Vue frontend can call start_frpc, stop_frpc, get_state, get_logs, update_frpc over the IPC bridge.

The tempting mistake is to put lifecycle logic in the frontend and just have Rust be a thin Command::spawn wrapper. Don't. The frontend can be reloaded, the window can be closed, the process tree cares about neither — the Rust side is the single source of truth for "what is the child doing right now."

Recap

Drain stdout/stderr into a bounded ring buffer, always.
Treat "running" and "healthy" as different questions; derive health from the child's own output.
Shutdown is SIGTERM-then-SIGKILL with a timeout, never the other way around.
Binary updates are atomic rename after verify, and Windows forces a strict stop-before-replace order.
In Tauri, the Rust core owns the state machine; the frontend is a view onto it.

The full implementation of this lives in src-tauri/src/ — process.rs for lifecycle, frpc_state.rs for the log classifier, proxy_relay.rs for the traffic-counting TCP middle layer, and frpc_update.rs for the verified-then-atomic update path. Comments and corrections welcome.

MoonProxy is MIT-licensed and on macOS + Windows — if you're shipping a Tauri app that wraps a CLI, the patterns above are field-tested.

How to Host a Minecraft Server Friends Can Join from Anywhere (No Port Forwarding)

ChenXX — Sat, 18 Jul 2026 08:04:48 +0000

The Problem: "Connection Refused"

You set up a Minecraft server. Your friends type in your IP. Nothing. The dreaded "Connection refused" or endless "Connecting to server..." timeout.

The culprit is almost always the same: NAT. Your home router sits behind your ISP's network address translation, so your server's local port (25565) is invisible to the public internet.

The classic answer is port forwarding — log into your router, open port 25565, point it at your server's local IP. But that approach has real problems:

It doesn't work behind carrier-grade NAT (CGNAT), which most mobile and many home ISPs now use.
It exposes your home IP directly to the internet.
Every router UI is different, making it a frustrating guessing game.

There's a better way.

The Fix: A Reverse Tunnel with FRP

FRP (Fast Reverse Proxy) is an open-source tool that creates a reverse tunnel: your server connects outward to a public relay, and players connect to the relay instead of your home network. No port forwarding, no exposed home IP, and it works behind CGNAT.

The catch: FRP's official client (frpc) is a command-line binary. Running it means editing a .toml config, opening a terminal, and babysitting a process. For a lot of people who just want to play Minecraft with friends, that's friction.

That's exactly the problem MoonProxy was built to solve.

MoonProxy: A GUI for FRP

MoonProxy is a free, open-source desktop app that wraps frpc in a graphical interface. You fill in your FRP server details (address, port, token), add a proxy rule for port 25565, and click Start. That's it.

macOS (Apple Silicon + Intel) and Windows x64
Built with Tauri v2 + Rust — small binary, low memory, no Electron bloat
System tray so the tunnel keeps running in the background
Auto-connect on boot so your server is reachable 24/7 without you thinking about it
Scheduled connect / disconnect if you only want it up on weekends
The FRP engine ships bundled — you never install frpc separately

Step-by-Step: Minecraft Server Over FRP with MoonProxy

1. Get an FRP server

You need a machine with a public IP running frps (the FRP server). Options:

A cheap VPS ($3-5/month) from any provider
A free-tier cloud instance (Oracle Cloud, Google Cloud, AWS)
A friend's server that already has a public IP

On that machine, download FRP and run frps with a minimal config exposing a port range for tunnels. Note down the server's public IP, the bind port (usually 7000), and the token.

2. Download MoonProxy

Grab the latest release for your platform from the releases page:

macOS Apple Silicon: the aarch64.dmg
macOS Intel: the x64.dmg
Windows: the x64-setup.exe

3. Configure your FRP server

Open MoonProxy, go to Settings > Server, and enter:

Server address: your VPS public IP
Port: 7000 (or whatever frps binds)
Token: your FRP auth token
Username: any unique name for this client

4. Add a proxy rule for Minecraft

Go to Settings > Proxies and add a rule:

Type: TCP
Local IP: 127.0.0.1
Local port: 25565 (your Minecraft server port)
Remote port: 25565 (the port players will connect to on your VPS)

5. Start the tunnel

Back on the home screen, click Start. The status indicator turns green when frpc has connected to your FRP server.

6. Share the address

Give your friends the address <your-vps-public-ip>:25565. They add it as a server in Minecraft and they're in.

That's the whole flow — no terminal, no config files, no router gymnastics.

Keeping It Up 24/7

If you want your server reachable around the clock:

Enable Launch at login in MoonProxy's settings.
Enable Auto-connect — the tunnel starts automatically whenever the app launches.
Minimize to the system tray so it runs quietly in the background.

Now your Minecraft world is reachable whenever your computer is on, with zero manual steps.

Why Not Just Use a Hosting Service?

You absolutely can pay for managed Minecraft hosting ($5-15/month typically). But:

Running it yourself on your own hardware is free.
You keep full control over mods, worlds, and backups.
You learn networking along the way.

MoonProxy + a $3 VPS gives you a self-hosted server with the same reachability as a paid plan, for a fraction of the cost.

Wrap-Up

The combination of FRP (the protocol) and MoonProxy (the GUI) removes the last piece of friction in self-hosting a Minecraft server: the networking. No port forwarding, no command line, no exposed home IP.

MoonProxy website: https://moonproxy.app/en/
Source code (MIT): https://github.com/MoonProxyHQ/moonproxy-desktop
Download: https://github.com/MoonProxyHQ/moonproxy-desktop/releases/latest

Happy building.

How to Put a Local Service on the Public Internet with FRP (Without Losing Your Mind Over Config Files)

ChenXX — Fri, 17 Jul 2026 08:04:39 +0000

How to Put a Local Service on the Public Internet with FRP (Without Losing Your Mind Over Config Files)

A practical walkthrough of FRP — what it is, how it works, and why you might want a GUI on top of it.

The problem every self-hoster hits

You built something. A local API. A Minecraft world for your friends. A self-hosted dashboard. An ERP running on the office machine. It works great — on your LAN.

The moment you want someone outside to reach it, the fun begins:

Port forwarding? Good luck if you're behind CGNAT, a corporate firewall, or an ISP that doesn't give you a public IP.
VPN? Now every person who wants access has to install a client, join a network, and stay connected. Overkill for "let me show you this one page."
Cloud deploy? Now you're maintaining two environments, paying for a VPS you didn't need, and shipping data somewhere it doesn't have to live.

What most people actually want is simpler: take this one local port, give it a public address, done.

That's exactly what FRP does.

What FRP is

FRP (Fast Reverse Proxy) is an open-source tool by fatedier that exposes a local service behind a NAT or firewall to the public internet. It's battle-tested, written in Go, and has been the go-to answer in self-hosting communities for years.

The model is clean — two pieces:

frps (the server) — runs on a machine with a public IP (a $5 VPS is plenty).
frpc (the client) — runs on your local machine, the one with the service you want to expose.

The client opens an outbound tunnel to the server. The server listens on a public port and forwards traffic back through the tunnel. NAT and firewalls don't matter because the connection is initiated from inside.

[Visitor] → [frps on public VPS:7000] ⇄ tunnel ⇄ [frpc on your laptop] → [localhost:8080]

That's the whole idea. It works for TCP, UDP, HTTP, HTTPS. People run Minecraft servers, remote desktops, internal dashboards, and dev previews through it every day.

The catch: config files

FRP works great. The friction isn't the protocol — it's the workflow.

To run frpc, you write a TOML/INI config file:

serverAddr = "203.0.113.10"
serverPort = 7000
auth.token = "your-secret-key"

[[proxies]]
name = "my-web"
type = "tcp"
localIP = "127.0.0.1"
localPort = 8080
remotePort = 8080

Then you run it from a terminal. If it crashes, you find out when someone texts you "is the server down?" If you want it to start on boot, you write a systemd unit. If you want to change one port, you edit the file and restart. If you're on Windows, you're juggling a console window or a scheduled task.

None of this is hard. But it adds up. And for users who aren't comfortable in a terminal — a small business owner running an ERP, a parent hosting Minecraft for their kid, a designer previewing a static site — it's a wall.

The piece I actually wanted to share

This is where I mention a project I think is worth knowing about, because it directly addresses that friction.

MoonProxy is an open-source desktop GUI for FRP. MIT licensed, built with Tauri v2 + Vue 3 + Rust, runs on macOS and Windows. The frpc binary is bundled — you don't install FRP separately.

What it does is take the config-file workflow above and turn it into a form:

Add a tunnel by filling in fields (local port, remote port, type, key) — no text editor, no syntax to get wrong.
Start/stop with one button — a circular toggle with four visual states (stopped, connecting, connected, error). "Connected" is derived from real frpc output, not an optimistic flag.
Health polling — it checks whether your local port is actually reachable every 3 seconds, so you find out your service is down before your users do.
System tray resident — close the window, the tunnel keeps running. Launch-at-login means it comes back after a reboot.
Scheduled connect — set weekdays and a time window; tunnels only stay open during working hours.
Engine self-update — pulls new frpc releases from the upstream FRP GitHub Releases, SHA256-verifies them, and atomically swaps the binary without reinstalling the app.

You still bring your own frps (self-hosted or a community-public one you trust) — MoonProxy is strictly the client side. It doesn't relay your traffic through any third-party infrastructure. The auth key stays with you.

It's independent of the upstream FRP project — FRP is fatedier's work, licensed and maintained by its original authors. MoonProxy is just a desktop client for it.

A quick walkthrough

Say you have a local dev server on localhost:5173 and an frps running on your VPS at 203.0.113.10:7000.

With plain FRP, you'd write the config, run ./frpc -c frpc.toml, and leave a terminal open.

With MoonProxy, you:

Open the app.
Click "Add tunnel."
Fill in: name vite-dev, type tcp, local 127.0.0.1:5173, remote port 5173, server address + your token.
Click the toggle.

The button goes connecting → connected. Your dev server is now reachable at 203.0.113.10:5173. Close the laptop lid, open it again — the tunnel comes back. You didn't write a config file or touch a terminal.

When to use what

Plain frp CLI if you live in the terminal, want to script everything, or run headless servers. FRP is excellent. This isn't a replacement — it's a layer on top.
A GUI like MoonProxy if you want set-and-forget tunnels, you're sharing the machine with non-technical users, or you're tired of debugging a YAML file at midnight because a colleague can't reach the staging URL.
Managed relays (Ngrok, Cloudflare Tunnel) if you want zero infrastructure and don't mind routing through a vendor's network. Different tradeoff — convenience for dependency.

Wrapping up

FRP remains one of the cleanest ways to put a local service on the public internet. The protocol is solid; the friction has always been in the operating of it.

If you've been meaning to try FRP but bounced off the config-file workflow — or you're already running it and want a tray icon instead of a terminal window — MoonProxy is worth a look.

🌐 Website: moonproxy.app
💻 Source (MIT): github.com/MoonProxyHQ/moonproxy-desktop
⬇️ Releases: macOS (Apple Silicon + Intel) and Windows x64

If you build something with it, I'd love to hear what you're tunneling. 👋

5 Real-World Scenarios Where a GUI FRP Client Beats the Command Line

ChenXX — Thu, 16 Jul 2026 08:15:10 +0000

If you've ever set up frp — the go-to open-source reverse proxy for NAT traversal — you know the drill: SSH into a VPS, install frps, write a frpc.toml on your local machine, wrestle with ports and tokens, run it as a background service, and hope nothing drifts.

It works. But for a lot of people — self-hosters, remote workers, small teams, anyone who isn't a sysadmin — the CLI workflow is friction they'd rather avoid. That's exactly why I built MoonProxy: an open-source desktop GUI for frp (macOS + Windows, MIT-licensed, built on Tauri v2).

Rather than pitch features, here are five concrete scenarios where reaching for a GUI client saves real time and headaches.

1. The "I Just Want to SSH Into My Home Server" User

You're at a coffee shop. You need to fix something on the mini-PC running under your desk at home. No public IP, carrier-grade NAT, no VPN.

CLI path: write a frpc.toml with a tcp proxy stanza, make sure the remote port on your VPS matches, start frpc, keep it alive, SSH to vps-ip:remote-port.

GUI path: open MoonProxy, type your frps server address + token, add one TCP proxy rule (local port 22 → remote port 6000), click Start. The public address is shown right on the home screen. Done.

The win isn't speed for an expert — it's that a non-Linux-savvy family member can do it after a one-time setup.

2. Debugging Webhooks and OAuth Callbacks Locally

Third-party services (Stripe, GitHub, Slack) need to POST to a publicly reachable URL. Your dev server runs on localhost:3000.

With MoonProxy you spin up an HTTP proxy rule pointing at localhost:3000, and you get a public domain on your frps server that forwards straight to your laptop. No ngrok account, no tunnel-as-a-service limits — just your own infra.

The bonus: MoonProxy's home tab shows a live traffic chart for the tunnel, so you can see the webhook hitting your machine in real time. That's surprisingly useful when debugging "did the callback actually fire?"

3. Sharing a Local Service With a Non-Technical Colleague

You've got a demo running locally and want a teammate to take a look — but they're on a different network and you don't want to deploy to a cloud VM just for a 10-minute review.

Start a tunnel in MoonProxy, hand them the public URL. When they're done, click Stop. The URL dies. No lingering exposure, no cloud bill, no kubectl.

4. Keeping a Tunnel Up 24/7 Without Babying It

Long-running tunnels (home NAS access, a personal blog hosted on a Raspberry Pi, a Minecraft server for friends) need to survive reboots, sleep/wake cycles, and network hiccups.

MoonProxy handles this with three built-in features:

System tray resident — close the window and the tunnel keeps running.
Launch at login + silent start — boots hidden to the tray.
Scheduled connect — pick weekdays and start/stop times; the scheduler hot-reloads every minute.

So a tunnel can run Monday–Friday 9–18 and turn itself off otherwise — without a cron job or a systemd timer you'll forget about.

5. Knowing Immediately When a Tunnel Breaks

The silent failure mode of a backgrounded frpc process is brutal: everything looks fine until you try to connect and realize the tunnel died three hours ago.

MoonProxy polls local endpoint reachability at adaptive intervals (exponential backoff from 3s up to 24s) and surfaces the result as colored health dots on the home screen. A broken tunnel shows red within seconds, not after you've already left the house relying on it.

The Broader Point

frp the protocol is excellent. The workflow around it — hand-edited TOML, process supervision, port juggling — is where most non-experts give up. A GUI doesn't make frp more powerful; it makes it accessible to the people who need NAT traversal but don't want a side quest in systems administration.

If any of those five scenarios sound familiar, MoonProxy is free and open source:

GitHub: MoonProxyHQ/moonproxy-desktop
Website: moonproxy.app
Platforms: macOS (Apple Silicon + Intel), Windows x64
License: MIT

You bring your own frps server (self-hosted or any community endpoint you trust) — MoonProxy handles configuration, lifecycle, monitoring, and updates. The bundled frpc engine even self-updates from upstream releases, so you never have to wget a binary again.

Questions, feature ideas, or war stories? The Discussions tab is open. 🌙

Bundling a CLI Binary as a Tauri v2 Sidecar: Architecture and Lessons from Building MoonProxy

ChenXX — Tue, 14 Jul 2026 08:07:44 +0000

When you build a desktop app that needs to ship a CLI binary alongside it, the Tauri v2 sidecar mechanism is the cleanest solution. This post is a deep-dive into how MoonProxy (an open-source FRP GUI client for macOS & Windows) uses it to bundle the frpc binary so users never have to install it separately.

MoonProxy v1.2.0+ — Tauri v2 + Vue 3 + Rust, MIT licensed, moonproxy.app

Why sidecar?

A FRP client is intrinsically a client-server tool:

The user runs frpc (client) on their machine
frpc connects to frps (server) running on a public cloud

Options for distributing frpc:

Tell users to install frp separately — too many support tickets
Spawn frpc via system PATH lookup — fragile, version drift
Bundle frpc binary inside the app — ✅ best UX

Tauri v2's sidecar feature lets you ship a binary that the app spawns as a child process, with the same lifecycle management as the app itself.

Step 1 — Naming convention

Tauri identifies sidecar binaries by file-name suffix per target platform:

Platform	File name
macOS Apple Silicon	`frpc-aarch64-apple-darwin`
macOS Intel	`frpc-x86_64-apple-darwin`
Windows x64	`frpc-x86_64-pc-windows-msvc.exe`
Windows ARM64	`frpc-aarch64-pc-windows-msvc.exe`

The base name (frpc) is what you reference from tauri.conf.json.

Step 2 — Place binaries in `src-tauri/binaries/`

Tauri v2 looks for sidecar binaries in src-tauri/binaries/ at compile time and embeds them into the app bundle.

src-tauri/
  binaries/
    frpc-aarch64-apple-darwin
    frpc-x86_64-apple-darwin
    frpc-x86_64-pc-windows-msvc.exe
    frpc-aarch64-pc-windows-msvc.exe

A sync-frpc.sh script downloads the matching frpc release and renames it to the above pattern.

Step 3 — Declare in `tauri.conf.json`

{
  "bundle": {
    "externalBin": [
      "binaries/frpc"
    ]
  }
}

Note: Tauri strips the platform suffix automatically; you only write the base name (frpc).

Step 4 — Spawn the sidecar from Rust

Tauri exposes the tauri-plugin-shell for command-based sidecar execution. In our case we use a Rust wrapper that gives us stdout streaming + log buffering + restart on failure:

use tauri_plugin_shell::ShellExt;

let sidecar_command = app.shell()
    .sidecar("frpc")
    .expect("failed to create sidecar")
    .args(["-c", "/path/to/frpc.toml"]);

let (mut rx, mut child) = sidecar_command.spawn().expect("failed to spawn");

// Stream stdout → in-memory ring buffer + log UI
tauri::async_runtime::spawn(async move {
    use tauri_plugin_shell::process::CommandEvent;
    while let Some(event) = rx.recv().await {
        match event {
            CommandEvent::Stdout(line) => { /* push to log ring buffer */ }
            CommandEvent::Stderr(line) => { /* push to log ring buffer */ }
            CommandEvent::Terminated(payload) => { /* mark exit */ }
            _ => {}
        }
    }
});

Step 5 — Log ring buffer (for the UI)

The Vue UI shows a real-time log feed. We don't want unbounded memory growth, so we use a RingBuffer<String> with a 2000-line capacity in frpc_state.rs:

pub struct LogRing {
    inner: Arc<Mutex<VecDeque<String>>>,
    capacity: usize,
}

impl LogRing {
    pub fn push(&self, line: String) {
        let mut q = self.inner.lock().unwrap();
        if q.len() >= self.capacity {
            q.pop_front();
        }
        q.push_back(line);
    }
}

Step 6 — Auto-restart with backoff

If the frpc process dies (network glitch, server reboot), we want to retry with exponential backoff. State machine in frpc_state.rs:

enum ConnState {
    Stopped,
    Connecting { attempt: u32 },
    Connected { since: Instant },
    Error { reason: String, next_retry: Instant },
}

fn schedule_retry(&mut self) {
    let backoff = 2u64.saturating_pow(self.attempt.min(6));  // 1, 2, 4, 8, 16, 32, 64s
    self.state = ConnState::Connecting { attempt: self.attempt + 1 };
    self.timer = Some(Instant::now() + Duration::from_secs(backoff));
}

Step 7 — Self-update of the sidecar binary

When upstream frpc releases a new version, we want users to get it without reinstalling the app. We ship an updater that:

Downloads the new frpc release tarball
Verifies SHA256
Atomically replaces the binary
Restarts frpc

async fn update_frpc(app: AppHandle, new_version: &str) -> Result<()> {
    let url = format!("https://github.com/fatedier/frp/releases/download/v{}/frp_{}_darwin_amd64.tar.gz", new_version, new_version);
    let tmp_path = app.path().app_config_dir()?.join("frpc.new");
    download_and_verify(&url, &tmp_path, &expected_sha).await?;

    // atomic rename
    let final_path = app.path().app_config_dir()?.join("frpc");
    std::fs::rename(&tmp_path, &final_path)?;
    Ok(())
}

The app itself has a separate updater path (Tauri's built-in tauri-plugin-updater).

Gotchas we hit

1. macOS code signing & Gatekeeper

Unsigned binaries downloaded at runtime trigger Gatekeeper on first launch. Solution: ship the binary inside the .app bundle (already code-signed with the app), not downloaded at runtime for the initial version. Runtime updates still work because the new binary inherits the parent app's permissions (mostly).

2. Windows Defender false positive

frpc is sometimes flagged because of its network behavior. We:

Document the SHA256 + source URL in the update flow
Provide a "report false positive" link in the UI
Sign the binary (planned for v1.3.0)

3. Architecture mismatch on Apple Silicon

A common bug: user is on M1 Mac but the app shipped the Intel frpc. With Tauri v2's platform-suffix naming, this is solved at bundle time, but you need to make sure your build matrix covers all 4 platform suffixes (we use GitHub Actions matrix builds).

What I'd do differently

Pin frpc version in Cargo.toml rather than downloading at build time — simpler CI
Use tauri-plugin-shell's structured sidecar API (newer versions have it) — saves the manual stdout stream loop
Expose the sidecar process to the JS frontend via IPC — we do this for status, but logs are still polled; streaming via Tauri events would be smoother

Code links

MoonProxy repository: https://github.com/MoonProxyHQ/moonproxy-desktop
Sidecar wrapper: src-tauri/src/process.rs
Log ring buffer: src-tauri/src/frpc_state.rs
Auto-restart: src-tauri/src/frpc_state.rs::schedule_retry
Self-update: src-tauri/src/frpc_update.rs
Sync script: scripts/sync-frpc.sh

Try it

If you're building a desktop app that needs to bundle a CLI tool, I hope this deep-dive saves you some time. Tauri sidecar is a powerful pattern — once you have the boilerplate right, shipping a "runs offline, talks to my server" app becomes tractable for a small team.

Comparing FRP GUI Clients in 2026: MoonProxy vs frpc-desktop vs frpmgr vs frp-panel

ChenXX — Sat, 11 Jul 2026 08:11:00 +0000

FRP (Fast Reverse Proxy) is one of the most popular open-source tools for exposing local services to the public internet. But FRP is a CLI tool — and for many users, editing TOML config files and running terminal commands feels intimidating.

That's where GUI clients come in. Let's compare the top FRP desktop clients available today.

Why use a GUI for FRP?

No command line knowledge needed
Visual traffic monitoring and connection status
One-click start/stop instead of managing background processes
System tray integration for always-on operation
Easier configuration management across multiple servers

The contenders

1. MoonProxy (cross-platform)

GitHub | macOS + Windows | MIT License

The newest entry, built with Tauri v2 + Vue 3 + Rust. Key features:

Cross-platform: macOS (Apple Silicon + Intel) and Windows x64
Real-time traffic monitoring with live charts
System tray with silent start and auto-connect on boot
Scheduled connections (weekday + time range)
Built-in frpc auto-update (no manual binary management)
App self-update via Tauri updater
Built with Tauri — lightweight (~10 MB), not Electron

Best for: Non-technical users who want a polished, modern experience on both Mac and Windows.

2. frpc-desktop

GitHub | Windows + macOS + Linux

A mature Electron-based FRP client with a large community. Supports proxy management and basic monitoring.

Best for: Users who need Linux support and don't mind Electron's resource footprint.

3. frpmgr

GitHub | Windows only

A Windows-native FRP manager with a clean Win32 UI. Lightweight and focused.

Best for: Windows-only users who want a native, no-frills experience.

4. frp-panel

GitHub | Web-based

A web dashboard for managing FRP servers and clients. Great for multi-machine setups.

Best for: Server administrators managing multiple FRP instances.

Quick comparison

Feature	MoonProxy	frpc-desktop	frpmgr	frp-panel
macOS	Yes	Yes	No	Web
Windows	Yes	Yes	Yes	Web
Linux	Planned	Yes	No	Web
Traffic monitor	Live charts	Basic	No	Yes
System tray	Yes	Yes	Yes	N/A
Auto-connect	Yes	No	No	N/A
Scheduled	Yes	No	No	No
Auto-update	Yes	No	No	No
Framework	Tauri v2	Electron	Win32	Go web
Bundle size	~10 MB	~80 MB	~5 MB	Server

Which one should you choose?

Want the most polished Mac + Windows experience? Try MoonProxy
Need Linux support today? Go with frpc-desktop
Windows only and want minimal overhead? frpmgr
Managing multiple servers? frp-panel

All of these are open-source and free. The FRP ecosystem is better when these projects support each other — many of them maintain mutual cross-references in their READMEs.

This is an independent comparison. I am a contributor to MoonProxy, but I respect all projects in the FRP ecosystem. Star any project that helps you.

How to Put a Local Service on the Public Internet with FRP (Without Losing Your Mind Over Config Files)

ChenXX — Fri, 10 Jul 2026 09:55:11 +0000

The problem every self-hoster hits

You built something. A local API. A Minecraft world for your friends. A self-hosted dashboard. An ERP running on the office machine. It works great — on your LAN.

The moment you want someone outside to reach it, the fun begins:

Port forwarding? Good luck if you're behind CGNAT, a corporate firewall, or an ISP that doesn't give you a public IP.
VPN? Now every person who wants access has to install a client, join a network, and stay connected. Overkill for "let me show you this one page."
Cloud deploy? Now you're maintaining two environments, paying for a VPS you didn't need, and shipping data somewhere it doesn't have to live.

What most people actually want is simpler: take this one local port, give it a public address, done.

That's exactly what FRP does.

What FRP is

The model is clean — two pieces:

frps (the server) — runs on a machine with a public IP (a $5 VPS is plenty).
frpc (the client) — runs on your local machine, the one with the service you want to expose.

[Visitor] → [frps on public VPS:7000] ⇄ tunnel ⇄ [frpc on your laptop] → [localhost:8080]

That's the whole idea. It works for TCP, UDP, HTTP, HTTPS. People run Minecraft servers, remote desktops, internal dashboards, and dev previews through it every day.

The catch: config files

FRP works great. The friction isn't the protocol — it's the workflow.

To run frpc, you write a TOML/INI config file:

serverAddr = "203.0.113.10"
serverPort = 7000
auth.token = "your-secret-key"

[[proxies]]
name = "my-web"
type = "tcp"
localIP = "127.0.0.1"
localPort = 8080
remotePort = 8080

The piece I actually wanted to share

This is where I mention a project I think is worth knowing about, because it directly addresses that friction.

MoonProxy is an open-source desktop GUI for FRP. MIT licensed, built with Tauri v2 + Vue 3 + Rust, runs on macOS and Windows. The frpc binary is bundled — you don't install FRP separately.

What it does is take the config-file workflow above and turn it into a form:

Add a tunnel by filling in fields (local port, remote port, type, key) — no text editor, no syntax to get wrong.
Start/stop with one button — a circular toggle with four visual states (stopped, connecting, connected, error). "Connected" is derived from real frpc output, not an optimistic flag.
Health polling — it checks whether your local port is actually reachable every 3 seconds, so you find out your service is down before your users do.
System tray resident — close the window, the tunnel keeps running. Launch-at-login means it comes back after a reboot.
Scheduled connect — set weekdays and a time window; tunnels only stay open during working hours.
Engine self-update — pulls new frpc releases from the upstream FRP GitHub Releases, SHA256-verifies them, and atomically swaps the binary without reinstalling the app.

It's independent of the upstream FRP project — FRP is fatedier's work, licensed and maintained by its original authors. MoonProxy is just a desktop client for it.

A quick walkthrough

Say you have a local dev server on localhost:5173 and an frps running on your VPS at 203.0.113.10:7000.

With plain FRP, you'd write the config, run ./frpc -c frpc.toml, and leave a terminal open.

With MoonProxy, you:

Open the app.
Click "Add tunnel."
Fill in: name vite-dev, type tcp, local 127.0.0.1:5173, remote port 5173, server address + your token.
Click the toggle.

When to use what

Plain frp CLI if you live in the terminal, want to script everything, or run headless servers. FRP is excellent. This isn't a replacement — it's a layer on top.
A GUI like MoonProxy if you want set-and-forget tunnels, you're sharing the machine with non-technical users, or you're tired of debugging a YAML file at midnight because a colleague can't reach the staging URL.
Managed relays (Ngrok, Cloudflare Tunnel) if you want zero infrastructure and don't mind routing through a vendor's network. Different tradeoff — convenience for dependency.

Wrapping up

FRP remains one of the cleanest ways to put a local service on the public internet. The protocol is solid; the friction has always been in the operating of it.

If you've been meaning to try FRP but bounced off the config-file workflow — or you're already running it and want a tray icon instead of a terminal window — MoonProxy is worth a look.

🌐 Website: moonproxy.app
💻 Source (MIT): github.com/MoonProxyHQ/moonproxy-desktop
⬇️ Releases: macOS (Apple Silicon + Intel) and Windows x64

If you build something with it, I'd love to hear what you're tunneling. 👋

MoonProxy: A Desktop GUI Client for FRP (Fast Reverse Proxy)

ChenXX — Wed, 08 Jul 2026 14:00:37 +0000

MoonProxy: The Complete Guide to FRP Intranet Penetration

From setup to real-world use cases. For developers and self-hosters.
Compatible with MoonProxy v1.2.0+

Why FRP + MoonProxy?

FRP (Fast Reverse Proxy) is the most popular open-source tunneling tool (80k+ GitHub stars). But its CLI-only workflow keeps non-technical users away. MoonProxy wraps FRP's frpc into a native desktop app — visual configuration, one-click start/stop, real-time traffic monitoring.

Why not ngrok / Cloudflare Tunnel / Tailscale?

ngrok: Free tier is limited, paid plans are expensive
Cloudflare Tunnel: Closed source, only handles HTTP(S), vendor lock-in
Tailscale: Great for mesh networking, but not traditional port forwarding

FRP + MoonProxy gives you full control with your own server, supports any TCP/UDP/HTTP protocol, and costs nothing.

Architecture

[Your Computer]                     [Public Server]            [Visitor]

  Local Service (NAS:5000)                                      
       ↓                                                       
  MoonProxy (frpc GUI) ←── tunnel ──→  frps (server) ←── public access
       ↓                                                       
  127.0.0.1:5000                                     your-server:6000

Part 1: Set Up frps Server (5 min)

Download FRP

wget https://github.com/fatedier/frp/releases/download/v0.69.1/frp_0.69.1_linux_amd64.tar.gz
tar xzf frp_0.69.1_linux_amd64.tar.gz
cd frp_0.69.1_linux_amd64

Configure frps.toml

bindPort = 7000
auth.token = "your-secret-token-change-me"

Run as systemd service

sudo cp frps /usr/local/bin/
sudo mkdir -p /etc/frp && sudo cp frps.toml /etc/frp/
sudo tee /etc/systemd/system/frps.service << 'EOF'
[Unit]
Description=frps service
After=network.target

[Service]
Type=simple
ExecStart=/usr/local/bin/frps -c /etc/frp/frps.toml
Restart=on-failure
RestartSec=5s

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl enable frps && sudo systemctl start frps

Open firewall ports

sudo ufw allow 7000/tcp   # FRP communication
sudo ufw allow 6000/tcp   # Your tunnel port
# Also check your cloud provider's security group

Part 2: Install MoonProxy

Download from GitHub Releases:

Platform	File
macOS (Apple Silicon)	`MoonProxy_1.2.0_aarch64.dmg`
macOS (Intel)	`MoonProxy_1.2.0_x64.dmg`
Windows (x64)	`MoonProxy_1.2.0_x64-setup.exe`

📸 Main panel: https://moonproxy.app/screenshots/main-full-en.webp
📸 Provider config: https://moonproxy.app/screenshots/server-provider-en.webp
📸 Proxy rules: https://moonproxy.app/screenshots/server-proxy-en.webp

Part 3: Connect in 3 Steps

Step 1: Enter Server Info

Go to Services → Provider tab:

Field	Value
Server Address	Your server's public IP (e.g., `203.0.113.50`)
Bind Port	`7000` (matches frps bindPort)
Token	Same as frps auth.token

Step 2: Add Proxy Rule

Go to Proxy Rules tab → Add Rule:

Expose a Web service (HTTP):

Protocol: http
Local Port: 8080
Custom Domain: myapp.example.com (point DNS to your server)

Expose SSH (TCP):

Protocol: tcp
Local Port: 22
Remote Port: 6000

Then connect with: ssh -p 6000 user@your-server-ip

Expose NAS (TCP):

Protocol: tcp
Local Port: 5000
Remote Port: 5000

Access at: http://your-server-ip:5000

Step 3: Click Start

📸 Home panel: https://moonproxy.app/screenshots/main-full-en.webp

Return to the home screen. The large button changes color:

Gray = Stopped
Blue = Connecting
Green = Connected

The endpoint list shows green dots (reachable) or red dots (unreachable). Click Start — when the button turns green, you're live!

Real-World Use Cases

Remote NAS Access

Expose your Synology NAS (port 5000) to access files from anywhere.

Dev Preview Sharing

Share your localhost:5173 Vue/React project with clients via a public URL.

Minecraft Server

Expose your local Minecraft server (port 25565) so friends can join directly.

Home Automation

Access Home Assistant while traveling — no VPN needed.

Advanced Features

Auto-Start + Silent Mode

📸 Launch settings: https://moonproxy.app/screenshots/settings-launch-en.webp

Auto-start: Launches on system boot
Silent start: Hides to system tray, no window popup
Auto-connect: Automatically starts frpc on boot

Scheduled Connection

Set working hours (e.g., Mon-Fri 9:00-18:00). MoonProxy auto-connects at start time and disconnects at end time. No exposed ports outside working hours.

Real-Time Traffic Monitor

The home panel shows live upload/download speed curves, active connections, and cumulative traffic — powered by a built-in TCP relay counting layer.

Self-Updating Engine

FRP engine updates automatically: checks GitHub releases → downloads → SHA256 verify → atomic replace. No reinstall needed.

FAQ

Can't connect? Check: (1) frps running? systemctl status frps (2) Port 7000 open? (3) Token matches? (4) Remote port open in firewall?

macOS "unidentified developer"? System Settings → Privacy & Security → "Open Anyway"

How many proxy rules? Up to 50 (v1.2.0+).

Data privacy? MoonProxy runs 100% locally. Your data flows: your computer → your server → visitor. No third party involved.

Tech Stack

Layer	Technology
Frontend	Vue 3 + TypeScript + Vite 6
Backend	Rust + Tauri v2
Engine	frp (frpc) v0.69.1
Bundle size	~5MB (far smaller than Electron)

How to Put a Local Service on the Public Internet with FRP (Without Losing Your Mind Over Config Files)

ChenXX — Wed, 08 Jul 2026 12:10:52 +0000

The problem every self-hoster hits

You built something. A local API. A Minecraft world for your friends. A self-hosted dashboard. An ERP running on the office machine. It works great — on your LAN.

The moment you want someone outside to reach it, the fun begins:

Port forwarding? Good luck if you're behind CGNAT, a corporate firewall, or an ISP that doesn't give you a public IP.
VPN? Now every person who wants access has to install a client, join a network, and stay connected. Overkill for "let me show you this one page."
Cloud deploy? Now you're maintaining two environments, paying for a VPS you didn't need, and shipping data somewhere it doesn't have to live.

What most people actually want is simpler: take this one local port, give it a public address, done.

That's exactly what FRP does.

What FRP is

FRP (Fast Reverse Proxy) is an open-source tool by fatedier that exposes a local service behind a NAT or firewall to the public internet. It's battle-tested, written in Go, and has been the go-to answer in self-hosting communities for years.

The model is clean — two pieces:

frps (the server) — runs on a machine with a public IP (a $5 VPS is plenty).
frpc (the client) — runs on your local machine, the one with the service you want to expose.

[Visitor] → [frps on public VPS:7000] ⇄ tunnel ⇄ [frpc on your laptop] → [localhost:8080]

That's the whole idea. It works for TCP, UDP, HTTP, HTTPS. People run Minecraft servers, remote desktops, internal dashboards, and dev previews through it every day.

The catch: config files

FRP works great. The friction isn't the protocol — it's the workflow.

To run frpc, you write a TOML config file:

serverAddr = "203.0.113.10"
serverPort = 7000
auth.token = "your-secret-key"

[[proxies]]
name = "my-web"
type = "tcp"
localIP = "127.0.0.1"
localPort = 8080
remotePort = 8080

Then you launch it from a terminal. Change a port? Edit the file, restart the process. Add a second tunnel? Edit again, restart again. Want to know if it's actually working? Check the terminal output — or don't, because you closed that tab two hours ago.

This is fine if you live in the terminal. It's a wall for everyone else — a small-business owner running an ERP, a parent hosting Minecraft for their kid, a designer sharing a local mockup.

MoonProxy: a GUI for FRP

MoonProxy is an MIT-licensed desktop client for FRP. It wraps frpc in a GUI so you don't have to touch config files or terminals.

What it adds over plain frpc:

Form-based tunnel config — no toml/ini files. Add a tunnel like filling out a form.
One-click start/stop — a toggle button with real connection state, derived from frpc output (not an optimistic flag).
Endpoint health polling every 3s — catches a dead local service before your users do.
System tray resident — close the window, the tunnel keeps running. Launch at login, silent start.
Scheduled tunnels — set weekday + time window. Hot-reloaded, no restart.
Engine self-update — pulls new frpc from upstream FRP releases, SHA256-verifies, atomically swaps.

Built with Tauri v2 + Vue 3 + Rust + TypeScript. The frpc binary is bundled via Tauri sidecar — no separate FRP install. macOS (Apple Silicon + Intel) and Windows x64.

You bring your own frps (self-hosted VPS or a community node you trust). MoonProxy only manages the client side — it doesn't relay your traffic through any third-party infrastructure. Auth key stays with you.

It's independent of fatedier/frp — that project deserves all the credit for the protocol. This is just a GUI layer.

Getting started

Download from moonproxy.app or GitHub Releases (DMG for macOS, EXE for Windows).
On macOS first launch, right-click → Open, or run xattr -cr "/Applications/MoonProxy Desktop.app".
Set up your frps on a VPS (plenty of community tutorials exist).
Open MoonProxy, add a tunnel, click start.

That's it. Your local service now has a public address.

Project links

Website: moonproxy.app
Source: github.com/MoonProxyHQ/moonproxy-desktop
License: MIT, permanently free

It's not trying to replace the CLI — if you're happy scripting frp, keep doing that. This is for folks who want a tray icon and a toggle instead of a terminal window.

Happy to answer questions in the comments!

DEV Community: ChenXX

Measuring Throughput When the Subprocess Owns the Socket: A TCP Relay Pattern for Tauri Apps

The constraint

The trick: be the middleman

Counting bytes without copy_bidirectional

Running two directions concurrently

Connection counting with an RAII guard

Deriving a rate from a cumulative counter

Wiring it to the frontend

Rewriting the client's config

Cleanup

What this buys you

MoonProxy

Tunneling From a Raspberry Pi: How FRP Actually Behaves on Low-Power ARM Hardware

The short version

What the Pi actually costs you

The ARM reality check

The pattern that actually works

If you're on a Pi and tired of journalctl

What this looks like in MoonProxy, concretely

Bottom line

How to Put a Local Service on the Public Internet with FRP (Without Losing Your Mind Over Config Files)

The Problem

What MoonProxy Does

Tech Stack

Getting Started

Use Cases

Links

"Managing a CLI Subprocess from Rust: Lifecycle, Logs, and Graceful Shutdown (Tauri)"

The naive version (and why it bites you)

1. Drain the pipes into a ring buffer

2. Health = evidence, not just "process exists"

3. Graceful shutdown: ask, then escalate

4. Atomic binary replacement

5. The part Tauri adds on top

Recap

How to Host a Minecraft Server Friends Can Join from Anywhere (No Port Forwarding)

The Problem: "Connection Refused"

The Fix: A Reverse Tunnel with FRP

MoonProxy: A GUI for FRP

Step-by-Step: Minecraft Server Over FRP with MoonProxy

1. Get an FRP server

2. Download MoonProxy

3. Configure your FRP server

4. Add a proxy rule for Minecraft

5. Start the tunnel

6. Share the address

Keeping It Up 24/7

Why Not Just Use a Hosting Service?

Wrap-Up

How to Put a Local Service on the Public Internet with FRP (Without Losing Your Mind Over Config Files)

How to Put a Local Service on the Public Internet with FRP (Without Losing Your Mind Over Config Files)

The problem every self-hoster hits

What FRP is

The catch: config files

The piece I actually wanted to share

A quick walkthrough

When to use what

Wrapping up

5 Real-World Scenarios Where a GUI FRP Client Beats the Command Line

1. The "I Just Want to SSH Into My Home Server" User

2. Debugging Webhooks and OAuth Callbacks Locally

3. Sharing a Local Service With a Non-Technical Colleague

4. Keeping a Tunnel Up 24/7 Without Babying It

5. Knowing Immediately When a Tunnel Breaks

The Broader Point

Bundling a CLI Binary as a Tauri v2 Sidecar: Architecture and Lessons from Building MoonProxy

Why sidecar?

Step 1 — Naming convention

Step 2 — Place binaries in src-tauri/binaries/

Step 3 — Declare in tauri.conf.json

Step 4 — Spawn the sidecar from Rust

Step 5 — Log ring buffer (for the UI)

Step 6 — Auto-restart with backoff

Step 7 — Self-update of the sidecar binary

Gotchas we hit

1. macOS code signing & Gatekeeper

2. Windows Defender false positive

3. Architecture mismatch on Apple Silicon

What I'd do differently

Counting bytes without `copy_bidirectional`

If you're on a Pi and tired of `journalctl`

Step 2 — Place binaries in `src-tauri/binaries/`

Step 3 — Declare in `tauri.conf.json`