NP

NPS

Lightweight proxy server for intranet penetration

Reverse Proxy & Gateways ★ 34.2k stars Medium setup GPL-3.0

NPS is a lightweight, feature-rich intranet penetration proxy server with a web management interface, supporting TCP, UDP, HTTP and SOCKS5 tunnels. It is self-hosted on a public server and clients.

Key features

  • Intranet penetration
  • Web management UI
  • Multiple protocols
  • Lightweight

Pros & cons

Strengths

  • Web management interface
  • Many protocol tunnels
  • Lightweight single binary

Trade-offs

  • Docs mostly Chinese
  • Development largely stalled

NPS replaces

Last reviewed Aug 26, 2026 · 779 words

Use frp instead, unless you specifically want NPS's web dashboard and are prepared to keep that dashboard off the public internet. NPS is a capable piece of software: a single 64 MB Go binary that punches a home server out through a VPS with TCP, UDP, HTTP, HTTPS and SOCKS5 tunnels, configured by clicking. It also has not seen a substantive upstream release in years, its documentation is largely in Chinese, and it is designed to sit on a public IP address. Those three facts together are why the rest of this guide is mostly about the alternatives.

What NPS does, and does well

The server, nps, runs on a machine with a public address and listens on a bridge port (8024 by default) for clients and on a web port (8080) for you. The client, npc, runs at home, connects outward to the bridge with a key, and needs no open ports on your router. From the dashboard you create tunnels: forward VPS port 2222 to the home box's SSH, map git.example.com to a Forgejo container on the LAN, expose a SOCKS5 proxy so your phone browses as if it were at home. Everything frp does in a TOML file, NPS does in a browser, and that is genuinely why it collected 34,000 stars. For someone who finds text configuration off-putting it is the most approachable ngrok replacement that exists.

Why stalled development matters here specifically

A stalled note-taking app is a shrug. A stalled reverse tunnel is a server on a public IP with a web login, a client-key exchange and an HTTP proxy, all frozen at whatever security posture it had when the last maintainer stepped away. Weaknesses in the NPS web interface's authentication have been discussed publicly for years without an upstream fix, and I would treat any instance whose dashboard is reachable from the internet as compromised on principle. Community forks exist and some are maintained, but a fork you have to hunt for on GitHub is a different risk category from a project with a release cadence. Add the licence (GPL-3.0, which is fine for personal use) and the Chinese-first docs, and you are running something you cannot easily read the manual for and nobody is patching.

If you run it anyway

Do these four things before the first tunnel. Bind the web UI to localhost or a WireGuard interface, never 0.0.0.0. Change web_username and web_password in conf/nps.conf from admin and 123. Blank out public_vkey, which otherwise lets any client that knows the default connect. Set auth_key so API calls need a secret. A minimal server in Docker:

docker run -d --name nps --net=host \
  -v /srv/nps/conf:/conf \
  ffdfgdfg/nps

And the home-side client, using the key the dashboard shows when you create a client entry:

docker run -d --name npc --net=host \
  ffdfgdfg/npc -server=vps.example.com:8024 -vkey=YOUR_CLIENT_KEY -type=tcp

Put a firewall on the VPS that permits 8024 and your tunnel ports and nothing else, and reach the dashboard over a VPN. Run like that, NPS is usable. It is still not what I would choose for something that has to stay up for years.

The alternatives, ranked for a self-hoster

First, frp: the same architecture (public server, outbound client, per-tunnel config), actively maintained, TOML instead of a dashboard, and the answer for anyone comfortable editing one file. Second, rathole, which does the TCP and UDP subset of the job in a smaller Rust binary with lower memory and simpler config; it is what I run for one or two services. Third, and for most people actually first: skip the VPS and use Tailscale or headscale, which makes every device a peer on a private network with no public exposure at all, and reach for Tailscale Funnel only for the one thing that must be public. Fourth, Pangolin if you want the "VPS plus dashboard" experience NPS offered, built on WireGuard, with identity-aware access and a maintainer who ships. Cloudflare Tunnel is a fifth option for HTTP-only services at the cost of routing them through Cloudflare.

What I'd do

Tailscale for everything that only I need to reach, frp on a 5 USD VPS for the two services that must have a public hostname, and no NPS. If a colleague already runs NPS and it works, lock the dashboard behind WireGuard this week and plan a move to frp or Pangolin this year rather than waiting for the release that is not coming.

Compare NPS

1 head-to-head comparisons.

Similar reverse proxy & gateways apps