# NSmartProxy: TCP and UDP reverse proxy for private services

> NSmartProxy is an open source .NET Core reverse proxy that connects an internal client to a public server and forwards TCP or selected UDP traffic. It is aimed at operators who need controlled access to services behind a private network, but its documentation and release history require careful review before adoption.

**tmoonlight/NSmartProxy** — NSmartProxy是一款开源的内网穿透工具。采用.NET CORE的全异步模式打造。(NSmartProxy is an open source reverse proxy tool that creates a secure tunnel from a public endpoint to a locally service.)

- Repository: https://github.com/tmoonlight/NSmartProxy
- Stars: 1,388 · Forks: 386
- Language: C#
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/tmoonlight-nsmartproxy

## NSmartProxy's reverse proxy deployment model

NSmartProxy addresses a specific networking problem: a service is running on a computer inside a private network, while the user who needs to reach it is outside that network. Instead of asking the internal service to accept public connections directly, NSmartProxy places a client in the private network and a server in a public location. The client initiates the relationship, and the server receives connections from external consumers. This is useful for administrators of remote desktops, internal web services, FTP servers, or other TCP applications that should not be exposed as a directly published endpoint.

The project supports one client mapping multiple services. Its documentation describes multi-endpoint mapping, so the operator can configure several entries for a local host or for different addresses within the same private network. The target examples include FTP, Telnet, SMTP, HTTP or HTTPS, POP3, SMB, VNC, RDP, DNS queries, and mosh. TCP is the default for mappings, while UDP must be selected with the `Protocol` setting for the documented UDP case.

This is a transport-level forwarding arrangement rather than an application-aware gateway. The documentation describes forwarding requests and responses between the public server and internal services. It does not document URL routing, HTTP path rewriting, user authorization policies, request logging formats, or application-layer protocol inspection. That distinction matters when comparing NSmartProxy with a web-specific reverse proxy.

## Server, client, and tunnel data flow

The repository identifies two principal programs. `NSmartProxy.ServerHost` is deployed on a machine with a public IP address. It receives reverse connections from clients and connections from final users, then forwards traffic between those two sides. `NSmartProxyClient` runs inside the private network and connects to the server. It also connects or proxies traffic toward the configured internal service, allowing the server to pair an external consumer port with a target address and port inside the private network.

The configuration model is file based. The server uses `ReversePort` for reverse connections, `ConfigPort` for its configuration service, and `WebAPIPort` for the API service. The client uses `ProviderAddress` and `ProviderWebPort` to identify the server, then defines mappings in the `Clients` array. Each mapping can specify an `IP`, a `TargetServicePort`, and, where needed, a `ConsumerPort`. If the external port is omitted, the README says allocation begins at port `20000` in sequence when the requested port is occupied.

The project description calls the implementation fully asynchronous and identifies the primary language as C#. That points to an event-driven .NET Core networking design, but the README does not provide enough implementation detail to describe thread counts, buffer sizes, reconnect behavior, authentication token handling, or failure recovery. Those points need code or operational documentation before they should be treated as guarantees.

## Installing the client and exposing a first mapping

The README offers three client distribution styles. A cross-platform package requires a.NET Core runtime, an SCD package includes the runtime and is selected for a particular operating system and architecture, and a Windows WinForms package requires.NET Framework 4.6.1 or later. The documentation also shows Docker-based installation. The following Docker command pulls the client image and starts a detached container:

```bash
sudo docker pull tmoonlight/nspclient
sudo docker run --name mynspclient -dit tmoonlight/nspclient
```

For a file-based Linux SCD package, the README gives this download and startup sequence. The documented package names are not fully consistent, so the operator should match the archive actually downloaded before running the extraction command.

```bash
wget https://github.com/tmoonlight/NSmartProxy/releases/download/v1.2_final4/nspserver_scd_linux_v1.2_final4.zip
sudo unzip nspclient_scd_linux_v1.2.zip
cd nspclient_scd_linux_v1.2
chmod +x ./NSmartProxyClient
./NSmartProxyClient
```

The first download command names a server archive, while the later startup instructions name a client archive. That mismatch is a documentation issue, not an instruction to substitute an unknown release. A minimal configuration can map an internal web service, but JSON comments shown in the README are not valid JSON. Use a JSON-compatible configuration without comments:

```json
{
  "ProviderWebPort": 12309,
  "ProviderAddress": "2017studio.imwork.net",
  "Clients": [
    {
      "IP": "127.0.0.1",
      "TargetServicePort": "80"
    }
  ]
}
```

The README says the client may use anonymous login by default when the server permits anonymous access. For explicit credentials, it documents `-u` and `-p`; this creates `.usercache` in the current directory, which should be protected because it stores login credentials. The first use should therefore use a controlled server and explicit credentials.

## Running a self-hosted NSmartProxy server

A self-hosted server requires a machine with an independent IP address. The server package can be run on Linux, Windows, or macOS. Its documented server configuration is:

```json
{
  "ReversePort": 7842,
  "ConfigPort": 7841,
  "WebAPIPort": 12309
}
```

On Linux or macOS, the README gives the following startup procedure after extracting the package:

```bash
unzip nspserver_scd_linux_v1.2_final4.zip
chmod +x ./NSmartProxy.ServerHost
./NSmartProxy.ServerHost
```

The server also has a Docker path. Four port groups are required according to the documentation: the configuration port, reverse connection port, API port, and range used by consumers.

```bash
sudo docker pull tmoonlight/nspserver
sudo docker run --name mynspserver -dit -p 7842:7842 -p 7841:7841 -p 12309:12309 -p 20000-20050 tmoonlight/nspserver
```

The README says that the web interface is available at `http://ip:12309` and gives `admin/admin` as the factory credentials. That credential should be changed through the server interface if the interface provides a supported change procedure. The README excerpt does not document that procedure, so it should not be inferred. It also does not explain how to restrict access to `ConfigPort` or `WebAPIPort`, how TLS is terminated, or whether the public endpoint is suitable for internet exposure without additional controls.

The client can register as a Windows service. The documented commands are installation and removal actions:

```text
NSmartProxyClient action:install
NSmartProxyClient action:uninstall
```

Equivalent macOS and Linux background-service instructions are explicitly marked as omitted.

## TCP mappings, UDP cases, and protocol limits

NSmartProxy is most directly aligned with TCP forwarding. The README says it supports all protocols under the TCP stack and lists tested applications including FTP, Telnet, SMTP, HTTP or HTTPS, POP3, SMB, VNC, and RDP. That is a useful breadth claim for a port-forwarding tool, but it does not mean every application behaves identically. Some services depend on additional IP addresses, multicast, certificate validation, or multiple related ports. The documentation does not describe those cases.

UDP support is narrower. The stated tested cases include DNS queries and mosh. The client configuration selects UDP with a mapping such as:

```json
{
  "IP": "192.168.0.168",
  "TargetServicePort": "60002",
  "ConsumerPort": "30002",
  "Protocol": "UDP"
}
```

The server must be able to receive the corresponding traffic, and any network firewall or container port publishing must permit the selected protocol. The Docker example publishes ports but does not show a separate UDP publication for the server, so UDP deployments should not be treated as fully documented by that example. NSmartProxy also lacks documentation for UDP port-range handling, packet loss behavior, NAT traversal beyond its reverse connection model, or application-specific UDP state.

The project is consequently a poor fit for workloads that need protocol-aware load balancing, TLS termination, HTTP caching, header manipulation, or an administrative access-control layer. For those requirements, an HTTP reverse proxy or a managed tunnel service with explicit authentication and audit controls may be easier to operate. For private TCP administration tools such as RDP or VNC, the basic design is more closely aligned with the problem.

## Release history, licensing, and operating cost

NSmartProxy uses the MIT license. That license permits broad use under its terms, but the repository information here does not replace review of the actual `LICENSE` file. Operators still need to check obligations concerning copyright notices and redistribution when shipping modified binaries or distributing containers.

The listed releases are `v1.4.1` on 2024-08-18, `1.3_alpha` on 2020-04-22, and `v1.2_final4` on 2019-11-18. The last push was on 2026-08-14, and the repository is not archived. These facts indicate that the repository has recent repository activity, but they do not establish that every release is current, that the latest release has been validated for a particular platform, or that documentation has been updated. The README still contains old package URLs and several naming inconsistencies, which increases verification work during upgrades.

The operational cost is the main adoption constraint. A self-hosted deployment requires a public server, firewall rules for the configured ports, client configuration, credential management, process supervision, and monitoring of the reverse connection. The README does not document automatic client updates, version negotiation, migration of `.usercache`, or a rollback procedure. A Docker deployment reduces runtime installation work but still requires operators to manage images, persistent configuration, exposed ports, and log retention. The documented setup should therefore be treated as a starting point, not a complete production runbook.

## Conclusion

NSmartProxy fits operators who specifically need a self-hosted reverse proxy for TCP services or the documented UDP examples and can operate both the client and public server. It does not fit deployments requiring a managed service, a current security model, or documentation for many operational details. Before adopting it, verify compatibility with the intended release, inspect the public server exposure and authentication configuration, and confirm that the documented protocol and port mappings match the target services.

## FAQ

### What is NSmartProxy used for?

NSmartProxy is an open source reverse proxy for exposing services inside a private network through a public server. Its client can map TCP services and documented UDP cases such as DNS queries and mosh.

### How do I configure an NSmartProxy client?

The README directs users to edit `appsettings.json` with `ProviderAddress`, `ProviderWebPort`, and entries in `Clients`. Each entry identifies an internal `IP`, a `TargetServicePort`, and optional fields such as `ConsumerPort` and `Protocol`.

### Does NSmartProxy support Docker?

Yes. The README provides Docker commands for `tmoonlight/nspclient` and `tmoonlight/nspserver`. The server example publishes ports `7842`, `7841`, `12309`, and the range `20000-20050`.

## Sources

- [Issues](https://github.com/tmoonlight/NSmartProxy/issues)
- [License: MIT](https://github.com/tmoonlight/NSmartProxy/blob/master/LICENSE)
- [README](https://github.com/tmoonlight/NSmartProxy/blob/master/README.md)
- [Releases](https://github.com/tmoonlight/NSmartProxy/releases)
- [tmoonlight/NSmartProxy on GitHub](https://github.com/tmoonlight/NSmartProxy)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tmoonlight-nsmartproxy