FastTunnel turns a .NET tunnel framework into a hosted NAT relay

Two things in one repository: a hosted platform and a library

FastTunnel describes itself as a high-performance cross-platform intranet penetration tool for exposing intranet services to the public network. But the more interesting line for a developer is the second one: the project is committed to being an easy-to-extensible and easy-to-maintain intranet penetration framework, and you can build your own penetration application by referencing the NuGet package `FastTunnel.Core` and targeting the business extensions you need.

So there are two audiences. One is a person who wants a working tunnel today and will register on the hosted platform, which the README says eliminates the cost of building and maintaining your own. The other is a team that wants the mechanism and will supply their own business logic.

The project is split accordingly in the tree: `FastTunnel.Core/` is the shared library, `FastTunnel.Server/` is the relay side, `FastTunnel.Client/` and `FastTunnel.Core.Client/` are the client side, and `FastTunnel.Api/` is the API surface. The root `FastTunnel.sln` and `Directory.Build.props` tie them together, and `FastTunnel.Core` is published to NuGet with a download count badge in the README.

The hosted platform has one warning attached that should be quoted rather than paraphrased: do not use this service for important items.

What the tunnel can actually carry

The capability list covers remote computer access, domain-based access, port forwarding, multiple domains, whitelist restrictions and client verification. Remote access to an intranet Windows, Linux or Mac machine is supported. Using a custom domain name to reach intranet web services is supported, with the README noting this is usually used for WeChat development, which tells you the intended user is a Chinese developer needing a callback URL. Port forwarding and port mapping for services on any intranet port is supported, with mysql, redis and ftp given as examples.

Binding multiple domain names to reach the same intranet service is supported, so one relay can front several hostnames. The checklist also includes a domain name whitelist restriction. Client identity verification is also supported, which is the control that makes the whitelist meaningful.

The unchecked box is p2p penetration. That is the one structural difference from the direct approach: the traffic goes through the relay rather than being negotiated directly between the two ends. That architecture is what makes it work without public IP on either side or inbound port forwarding on the NAT device, and it is also why traffic passes through a third party host.

Deploying the server as a container

The server is a standard ASP.NET Core application and the Dockerfile at the root is a three-stage build you can read directly. The runtime base is `mcr.microsoft.com/dotnet/aspnet:8.0` exposing ports 80 and 443. The build stage uses `mcr.microsoft.com/dotnet/sdk:8.0`, copies only the three project files that the server depends on, restores, then copies the rest of the source:

FROM mcr.microsoft.com/dotnet/aspnet:8.0 AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /src
COPY ["FastTunnel.Server/FastTunnel.Server.csproj", "FastTunnel.Server/"]
COPY ["FastTunnel.Core/FastTunnel.Core.csproj", "FastTunnel.Core/"]
COPY ["FastTunnel.Api/FastTunnel.Api.csproj", "FastTunnel.Api/"]
RUN dotnet restore "FastTunnel.Server/FastTunnel.Server.csproj"

The publish stage runs `dotnet publish` in Release into `/app/publish`, and the final stage copies the config directory to `/vols/config` before the application itself, then copies in `start.sh` as the entrypoint:

FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish/config /vols/config
COPY --from=publish /app/publish .
COPY ./start.sh .
ENTRYPOINT ["/bin/bash","./start.sh"]

That entrypoint choice is deliberate: the commented-out line right below it would have run `dotnet FastTunnel.Server.dll` directly, and the active one runs a shell script instead. A start script is what you want if you need to generate or patch configuration before the process starts, and the separate config copy to `/vols/config` is there so a mounted volume can supply it.

For Linux deployment outside a container there is a systemd unit, `fasttunnel.service`, alongside `publish.sh`, `publish-self-contained.sh` and `start.sh`. Windows users get the client scripts: `udp_client.ps1`, `udp_client_proxyed.ps1` and `udp_server.ps1`, plus `addhost.bat` for local name resolution.

Version confusion is the first thing to resolve

The repository metadata and the release list do not line up, and this is the first thing to sort out before reading any documentation.

The default branch is `v2`. The release list, however, shows v2.3.0 published on 2026-05-20 alongside two beta tags, 3.1.0-Beta.1.260520 and v3.2.0-Beta.1.260520, all on the same day. So the maintained line appears to be 3.x while the branch you land on by default is still the 2.x tree.

The naming also encodes dates: the beta tags end in `.260520`, which is 2026-05-20, matching their publication timestamps. Expect to pick a version deliberately rather than tracking a moving branch.

Repository URLs are inconsistent too. The README links to github.com/SpringHgui/FastTunnel and to a Gitee mirror at gitee.com/Hgui/FastTunnel, and the CI badge points at a workflow in anjoy8/blog.core. The repository itself is FastTunnel/FastTunnel. Those are forks and mirrors from earlier locations rather than separate products, but if you are following issue links from an older thread you will land somewhere that no longer looks like the project.

The last push was on 2026-09-16, so the tree is current. The licence is Apache 2.0 with the terms in the root LICENSE file.

Where FastTunnel is the wrong choice

The hosted platform is the weak point, and the project says so. It asks you not to use the service for important items, which means no production traffic and no real credentials. That is not a limitation you engineer around; it is a statement about who bears the risk when a relay mishandles your data.

For a production exposure, consider alternatives that provide deployment and operational guarantees suited to your requirements. FastTunnel's pitch is convenience and speed of setup, and the trade is that the relay is somebody else's problem.

The second limitation is the missing p2p mode. Because traffic is relayed rather than direct, latency is the sum of two hops and throughput is bounded by the relay. Performance will depend on the relayed route, and the current checklist marks peer-to-peer penetration as unsupported.

Third, the documentation is hosted outside the repository in a separate opentask-doc project, and community support is through QQ groups. If you are working on a network where that is not reachable, the practical support channel is thin.

Editorial conclusion

Developers who need to expose a local service for a demo, a webhook test or a temporary debugging session will find FastTunnel's client mode sufficient, and teams already on .NET can build a purpose-made tunnel on FastTunnel.Core. Anyone planning to route production traffic or hold real credentials through the hosted platform should not, since the README says not to use that service for important items. Before adopting, confirm which branch you are on, because the default is v2 while the newest tags are 3.x betas, and check the domain whitelist and client verification options are enabled before you bind a hostname.

Frequently asked questions

Official sources

1. FastTunnel/FastTunnel on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases