NPS: four default ports, a copied client command, and a dev branch that is not master

Four ports do four different jobs, and 8024 is the one clients need

The default configuration file uses ports 80, 443, 8080 and 8024, and each has a separate job. Ports 80 and 443 are the host mode default ports, which is what a tunnel bound to a hostname lands on. Port 8080 is the web management access port, the one you open in a browser. Port 8024 is the net bridge port, the channel the server and client use to talk to each other.

That last one is the constraint people miss. Port 8080 can sit behind a firewall or a VPN because only an administrator visits it, while 8024 has to be reachable from every machine running a client, wherever that machine is. A deployment that opens 80, 443 and 8080 and forgets 8024 produces a client that appears in the web terminal and then does nothing. Plan the firewall around 8024 first, and remember that host mode will not start at all on a server where something else already holds 80 or 443.

sudo ./nps install lands the config in /etc/nps and the log in /var/log

You download the matching system version from the releases page, and the server and client packages are separate. Unzip the server package, enter the folder, and install it:

sudo ./nps install

On Windows the same step is nps.exe install, run from a command prompt opened as administrator in the installation directory. Then start it with sudo nps start, or nps.exe start on Windows.

Where things end up is the part worth writing down. After installation the Windows configuration file is at C:\Program Files\nps, and on linux or darwin it is at /etc/nps. Logs behave differently: on Windows they are written to the current running directory, and on linux and darwin to /var/log/nps.log. That asymmetry decides your debugging habit. If the service does not start, the README's advice is to read the log, and on Windows that means the log is in whatever directory you happened to launch from, not in the configuration directory next to the file you are editing.

The client is a command string you copy, and Windows needs npc.exe

Creating a client is done in the web terminal: click the plus sign in front of the client entry, then copy the startup command it produces. On Linux you run that command directly. On Windows you replace ./npc with npc.exe and run it from cmd. Registering the client as a system service is a separate step, described in the project documentation rather than in the quick start.

Two consequences follow. The command is the credential. Whatever server address and secret the terminal embeds in that string is now sitting in a shell history, a process listing and a terminal scrollback, so treat it the way you would treat a password and give each machine its own client entry rather than sharing one. And because running the command directly is the documented default, an unattended client does not survive a reboot until you do the service registration yourself. Anything that has to come back after a restart needs that extra step or a supervisor of your own.

The web terminal logs you in as admin/123 and is the only control surface

You reach the terminal at the server IP and the web service port, which defaults to 8080, and log in with a username and password. The default pair is admin/123, and the README says in the same sentence that it must be modified when the software is put to official use. That is the one piece of security advice in the quick start, and it is easy to read past because it sits in a parenthetical.

The terminal is also the whole interface. Tunnels are created there, per the configuration step, and the feature list is written in the vocabulary of that interface: traffic and system information, real-time bandwidth, client version, and per tunnel extensions covering cache, compression, encryption, traffic limit, bandwidth limit and port reuse. Domain resolution adds custom headers, 404 page configuration, host modification, site protection, URL routing and pan-resolution. Server side multi-user and user registration are part of the same surface, which is how several people share one server without sharing the admin account.

The gap is that none of this is described as a configuration file format. The conf/ directory exists in the repository and the installed file lives at /etc/nps, yet the README documents only what the four default ports are for. If your process requires tunnels to live in a reviewable file under version control, the web terminal does not offer that, and you would be reconstructing definitions by hand.

The Makefile builds two commands and fetches modules through gocenter.io

Source builds go through a Makefile whose build target is two go build lines:

build:
	go build cmd/nps/nps.go
	go build cmd/npc/npc.go

Those two paths are the whole shape of the project: a server and a client, matching the two packages you download. Around them sit setup, which installs golangci-lint and misspell by piping a download into sh before running go mod download, and lint, which runs golangci-lint with --enable-all, --tests=false and --disable=lll, then misspell in error mode. The ci target chains build, test, lint and go-mod-tidy, and test itself runs with -race and atomic coverage.

One line deserves a look before you build anything. The Makefile exports the module proxy with export GOPROXY := https://gocenter.io, so a build resolves every dependency through that host rather than through the default proxy. If your environment has to reach a module proxy to build at all, verify that this one resolves for you before you start, because a build that cannot fetch is a build that fails before it compiles. The go.mod also declares go 1.15, and the README points at a static documentation target built with hugo from a www directory that the repository root does not contain, listing docs/ and web/ instead.

Pull requests go to dev while the default branch is master

The contribution section is short enough to quote in full. Bugs go to the dev branch. Problems are reported through issues. Code contributions are pull requests to the dev branch. Feedback on new features goes through issues or the project's QQ group. Meanwhile the repository's default branch is master, and the quick start tells you to download binaries from the releases page.

So there are three lines here rather than one: master as the default branch, dev as the branch that receives contributions, and the tagged releases as what you actually install. Which of them a given release was built from is not stated anywhere in the README. The dates make the gap concrete: the newest tag is v0.26.10 from 2021-04-08, before v0.26.9 from 2020-10-06 and v0.26.8 from 2020-06-17, while the last push to the repository was 2024-05-30. Commits have landed years after the last tag, so a bug fixed on master may exist in no release at all. The README's own sentence that the project is under development was written against that earlier state of the repository, and the dates are the better guide to what to expect now.

Editorial conclusion

NPS fits a team that wants a single web terminal to define tcp, udp, http and socks5 tunnels across many clients, and that is willing to run the server binary on a machine that holds ports 80, 443, 8080 and 8024. It does not fit a deployment that cannot expose 8080 to the internet or that requires secrets in a file it can review, because the README documents neither. Before installing, change the admin/123 login the README itself flags, decide whether 8024 is reachable from every client, and check that the release you download matches the code you intend to run: the default branch is master, the README asks for pull requests against dev, the last push was 2024-05-30, and the newest tag is v0.26.10 from 2021-04-08.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes