# smarGate Review: A C++ NAT Traversal Tool Controlled From an Android App

> smarGate maps ports between internal networks over TCP P2P, with an Android client as the only access entry point and a server binary that runs without configuration. It is free, its licence is not stated, and its official relay does not forward to Hong Kong, Macau, Taiwan or overseas IPs.

**lazy-luo/smarGate** — 内网穿透，c++实现，无需公网IP，小巧，易用，快速，安全，最好的多链路聚合（p2p+proxy）模式，不做之一...这才是你真正想要的内网穿透工具！

- Repository: https://github.com/lazy-luo/smarGate
- Stars: 4,358 · Forks: 467
- Language: JavaScript
- License: not declared
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/lazy-luo-smargate

## What smarGate Does That a Reverse Tunnel Does Not

Most NAT traversal tools publish an internal service to a public entry point. The README is explicit that smarGate inverts this: it calls itself a "mobile gateway" and argues that the access door should be carried with you rather than placed in a public square. Concretely, the mapping configuration lives entirely in the Android client, and the access entry point can be bound either to a local port on the phone itself or to a port on any machine running the smarGate server.

The second capability is server-to-server mapping. From v0.31 onward, the client can map an arbitrary host and port inside server A's network onto a host in server B's network. The README describes this as configured through an ip@index form. That makes smarGate usable for internal-to-internal reachability, not just for exposing something outward.

It is aimed at engineers who already have internal machines and want reachability without buying a VPS or a public IP. The README also notes that a retired Android phone can serve as a server, which is a real deployment shape rather than a figure of speech.

## The Channel Selection Order: P2P, Then Custom Proxy, Then Official Relay

smarGate is written in C++ and uses its own network engine, with socket multiplexing across poll, epoll, kqueue, port, select and IOCP. The README lists lock-free algorithms, a thread pool, a socket connection pool and multi-level task queues as design elements. Treat those as claims from the project, not as measured results.

The part that matters operationally is the fallback order. The README states the tool prefers P2P, falls back to a user-configured proxy, and uses the official proxy as a last resort. P2P runs over TCP rather than UDP, which the README frames as both a security choice and a way to avoid UDP QoS throttling. IPv6 is handled transparently: a v6 tunnel is established automatically while the user keeps addressing services by IPv4.

P2P is not always available, and the README publishes a NAT compatibility table. NAT1-3 to NAT1-3 succeeds. NAT1-2 to NAT4 succeeds, and NAT4 to NAT1-2 succeeds. NAT4 to NAT3-4 fails, and NAT3-4 to NAT4 fails. If both ends sit behind symmetric NAT, expect the proxy path, which changes the bandwidth profile entirely.

## Installing the Server and Making a First Mapping

The README gives a four-step flow: download the app and register, download the matching server build, configure it with your user ID, then log in to the app and add port mappings. Server archives ship in the repository root for linux_arm32, linux_x86_64, linux_x86 and windows_x86.

The server needs an XML config. The README shows the proxy-server variant, where the port, owner ID and optional token are set as attributes. Note that the example declares GBK encoding, and that automatic certificate generation requires OpenSSL to be installed.

```xml
<?xml version="1.0" encoding="GBK"?>
<app-config code="PROXY" name="proxy-server">
  <app-parameter>
    <proxy-service-port value="9001"/>
    <owner-id value="xxxx" />
    <access-token value="nnnnn"/>
    <ssl-create-certfile value="true" />
  </app-parameter>
  <moudle-parameter>
    <log-level value="LOG_ERROR"/>
    <log-write-mode value="CONSOLE_ONLY"/>
  </moudle-parameter>
</app-config>
```

A normal server points at that proxy through a channel element, where the address must be a public IP and the ssl flag must match whether the proxy actually has a working certificate. The token must match the proxy's token, or be omitted on both sides.

```xml
<channel address="xxx.xxx.xxx.xxx:9001" ssl="true" token="nnnnn" />
```

After the server starts, the mapping itself is created in the Android app. The README states that mappings take effect immediately without restarting the server, which it calls hot plugging. On the phone, two settings decide whether any of this survives: background execution must be allowed, and the network must stay connected during sleep. Without them the system drops the connection as soon as the app is backgrounded. The README also warns that the official proxy does not forward data to Hong Kong, Macau, Taiwan or overseas IPs.

## The Advance APK and the Huawei Install Problem

The Android client ships in two build variants from one codebase, differentiated at compile time with R8 dead-code elimination. Base keeps proxy tunnelling and file management. Advance adds audio capture and transmission, GPS location tracking and in-app upgrade. Screen and camera monitoring are marked as absent in both.

This is a genuine trade-off rather than a marketing split. Base has fewer permissions and a smaller APK, which matters if the phone is only a gateway. Advance carries the high-permission modules, and the README states plainly that on Huawei phones the full version is detected as a fraud program: you must disable Pure Mode, then set the phone to airplane mode before installing. That is a real deployment obstacle, not a footnote, and it is the kind of thing that will surface during a rollout rather than during evaluation.

## Where smarGate Is the Wrong Tool

The project is not open source yet. The README says it is free and that open sourcing will be considered once it is stable, so the licence field is unknown and there is no source to audit. If your organisation requires a reviewable codebase or a clear licence before deployment, this tool fails that gate today regardless of how well it works.

Second, the control plane is a phone. Every mapping change, every enable and disable, goes through the Android client. That is the security argument the README makes, and it is also an availability argument against it: if the phone is lost, discharged or offline, you cannot reconfigure anything. A team that needs a web dashboard, an API or configuration management integration will find nothing here.

Third, the fallback relay is constrained. The official proxy is shared bandwidth and the README describes it as slow when several users are on it, recommending a self-hosted proxy as best practice. Combined with the geographic restriction on the official relay, anyone outside mainland China should assume they need their own proxy server with a public IP before this is usable.

## How It Differs From nps and Lucky

nps and Lucky, both of which appear in the search terms around this project, are built around a server with a public address that publishes internal services. You configure the server, the server holds the entry point, and clients connect to it. smarGate moves the entry point to the client device and treats the server as a config-free runtime.

That difference has practical consequences. With nps or Lucky, the entry point is stable and shareable: you can hand someone a domain and port. With smarGate, sharing means the other party reaches a port on your phone or on a server you designate, and the README's own analogy is that other tools leave the door in a public place while smarGate carries it. The cost of that model is that availability now depends on the client device staying online.

The second difference is transport selection. smarGate tries TCP P2P first and only falls back to a relay. A conventional reverse tunnel is a relay by definition, so its latency and throughput are bounded by the relay server. smarGate's ceiling is higher when P2P succeeds and identical when it does not.

## Maintenance, Upgrades and Licence Status

The last push to the repository was on 2026-07-27, roughly two months before this writing, and the repository is not archived. The most recent release listed is v0.40.6 from 2026-04-17, following v0.40.5 in January 2026 and a long gap back to v0.40.4 in April 2025. The server archives in the repository root are labelled v0.41.1, which is ahead of the newest listed release.

The README states that automatic version upgrade is supported, with one-click upgrade from the app. That is an Advance-only feature per the variant table, so Base users upgrade manually. Nothing in the README documents a rollback path if an upgrade goes wrong, and no migration notes are given for the config format between versions.

On licensing: the field is unknown. The README says the project is free and that open sourcing is planned after stability, which means there is currently no licence text to read. Free of charge and open source are not the same thing, and without a licence you have no stated grant of rights. That is a question for your own legal review, not something this article can resolve.

## Conclusion

Adopt smarGate if you need internal-to-internal port mapping where the access entry point travels with you and you accept an Android phone as the control plane; skip it if you need a documented licence, an auditable codebase, or a relay that reaches users outside mainland China. Before installing, verify the NAT types on both ends against the README table, because NAT4 to NAT3 and NAT4 to NAT4 cannot establish P2P, and confirm the Android battery permissions are set, otherwise the connection drops as soon as the app leaves the foreground.

## FAQ

### What is smarGate and what is it used for?

smarGate is a cross-network port mapping tool written in C++, with an Android client and a server installed inside the internal network. The README describes it as a mobile gateway that exposes internal services on demand, with all configuration done in the app.

### Does smarGate require a public IP?

No. The README states you do not need to buy a VPS or a public IP, and that no firewall configuration is changed. A self-hosted proxy server with a public IP is only needed as a fallback when P2P cannot be established.

### What NAT types can smarGate punch through for P2P?

The README table shows NAT1-3 to NAT1-3 succeeds, NAT1-2 to NAT4 succeeds, and NAT4 to NAT1-2 succeeds. NAT4 to NAT3-4 and NAT3-4 to NAT4 both fail, in which case traffic goes through a proxy instead.

### Why does the smarGate connection drop when the app goes to the background?

The README lists this as a typical failure: the app must be granted the allow background running permission and the keep network connection during sleep setting. Without both, the system disconnects the client as soon as it is backgrounded or the phone sleeps.

### Is smarGate open source?

Not currently. The README says it is free and that open sourcing will be considered after testing is stable, and the repository states no licence. There is no source code to review at this point.

## Sources

- [Issues](https://github.com/lazy-luo/smarGate/issues)
- [lazy-luo/smarGate on GitHub](https://github.com/lazy-luo/smarGate)
- [README](https://github.com/lazy-luo/smarGate/blob/master/README.md)
- [Releases](https://github.com/lazy-luo/smarGate/releases)

---

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