The story of getting a web server online from behind a network that blocks almost everything.
There's an NVIDIA DGX Spark sitting on a desk in a company office in Taiwan. It's a Grace Blackwell GB10 — 20-core ARM CPU, 119 GiB of unified memory, a GPU that can run 30-billion-parameter models. It's the kind of machine you want to run things on and show people what it can do.
The problem is getting anything out of it. The DGX has no ethernet port. Its only internet connection comes from a Windows laptop sitting next to it, sharing its WiFi through Windows ICS (Internet Connection Sharing). The laptop connects to the company WiFi, creates a hotspot, and the DGX connects to that hotspot. It's a chain of two wireless hops before anything reaches the internet.
And the company network is hostile.
We tested every protocol and port we could think of. Here's what we found:
All UDP outbound is blocked. Not just specific ports — all of it. This kills WireGuard (UDP-only), kills STUN (needed for peer-to-peer connections), kills any VPN that relies on UDP. We confirmed this with tailscale netcheck which reported UDP: false every time.
TCP 7844 is blocked. This is the port Cloudflare Tunnel uses for both its QUIC and HTTP/2 fallback transport. There's no first-party way to make cloudflared use a different port. We tried HTTPS_PROXY environment variables — cloudflared tunnel run ignores them.
Hinet residential IPs are blocked. Taiwan's largest ISP, Chunghwa Telecom (Hinet), has separate IP ranges for residential and business customers. The company network blocks the residential range but allows the business range. Our home has both subscriptions on the same physical router, but only one is reachable from the office.
The university blocks controlplane.tailscale.com. This is a separate problem from a separate network — the school where the DGX's owner studies blocks official Tailscale coordination entirely. Two different hostile networks, both pushing toward the same solution.
Before landing on what works, we exhausted the obvious approaches. Each failure taught us something about the network.
Cloudflare Tunnel (cloudflared) would have been the simplest solution — install it on the DGX, point a domain at it, done. But cloudflared exclusively uses TCP 7844 for its tunnel transport. The company firewall drops it. We installed it, configured the tunnel, created the DNS records — and watched it timeout on every connection attempt.
We tried forcing it through a proxy with HTTPS_PROXY. The tunnel run subcommand ignores that environment variable entirely. Only proxy-dns honors it. Dead end.
WireGuard is UDP-only. The company blocks all UDP outbound. There is no official TCP mode for WireGuard. We didn't spend long on this one.
Tailscale actually works from the company network — it falls back to its DERP relay over TCP 443 when UDP is blocked. But Tailscale's coordination server at controlplane.tailscale.com is blocked on the university network. We needed something that worked from both networks.
We tried setting up a self-hosted Headscale coordination server and pointing it at Tailscale's public DERP relay network. The nodes registered fine, but couldn't actually exchange traffic. Tailscale's public DERP relays reject clients that aren't enrolled in official Tailscale. Our Headscale-enrolled nodes got stonewalled.
We set up our own DERP relay and tried putting it behind Cloudflare's proxy (orange cloud) to hide the server's IP. Cloudflare's proxy blocks the Upgrade: DERP HTTP header. It only allows Upgrade: websocket. The DERP protocol isn't WebSocket — it's its own upgrade type. Cloudflare kills it silently.
We tried generating a 10-year self-signed certificate for the DERP relay. Go's crypto/x509 library enforces the CA/Browser Forum baseline requirement of ~398 days maximum validity. It rejected our certificate as non-compliant. We also hit SNI mismatch issues when trying to use CertName with a SHA-256 hash — the Tailscale client sends CertName as the TLS SNI, but our cert was registered under the real hostname.
The solution has four pieces. Each one exists because a simpler approach failed.
Headscale is an open-source replacement for Tailscale's coordination server. We run it in Docker on a home server (Ubuntu 24.04, Hyper-V VM). Instead of controlplane.tailscale.com, our devices connect to headscale.arthurlin.dev — which no network blocks, because it looks like any other HTTPS domain on a personal domain name.
One coordination server solves both hostile networks: the company that blocks everything, and the university that blocks Tailscale specifically.
Since public DERP relays reject our clients, we run our own. It sits on the same home server behind nginx, with a Let's Encrypt certificate obtained via DNS-01 challenge through the Cloudflare API. The relay runs with -verify-clients, which means it queries the local Headscale to confirm that connecting nodes are legitimate. Random internet scanners get rejected.
The critical insight that made this possible: the home server has a Hinet business IP (125.229.144.147). The company network blocks Hinet residential IPs but allows business IPs. The home has both subscriptions on the same physical router. One IP range difference — residential vs. business — is what made the whole system possible.
The home server (jason) accepts HTTPS on port 443, terminates TLS, and reverse-proxies the request through the Tailscale mesh to the DGX at 100.64.0.3:8080. The browser talks to jason; jason talks to the DGX through the encrypted mesh. The browser never knows the DGX exists.
flowchart LR
A["Your Browser"] -->|"HTTPS"| B["Cloudflare DNS"]
B -->|"125.229.144.147"| C["jason\n(nginx reverse proxy)"]
C -->|"Tailscale mesh\n(DERP, TCP 443)"| D["DGX Spark\n(Docker: nginx)"]
D -->|"HTML"| C
C -->|"HTTPS response"| A
style A fill:#1a1a1a,stroke:#555,color:#e0e0e0
style B fill:#1a1a1a,stroke:#555,color:#f6821f
style C fill:#1a1a1a,stroke:#76b900,color:#76b900
style D fill:#1a1a1a,stroke:#76b900,color:#76b900
Getting the tunnel working was only half the battle. The company WiFi (iii_wireless) disconnects the laptop every three hours or so. When that happens, the laptop's hotspot dies, the DGX loses internet, and the entire chain goes down.
The WiFi profile is managed by Group Policy — IT pushed it with connectionMode=manual, and that setting is read-only. Even with local admin, netsh wlan set profileparameter connectionmode=auto is rejected. The GUI toggle is grayed out. We can't change it.
So we built a watchdog. But that took five attempts to get right.
Created a Windows scheduled task running netsh wlan connect name=iii_wireless every 2 minutes as SYSTEM. The netsh command executed but couldn't authenticate — the WiFi uses WPA2-Enterprise with PEAP, and the PEAP credentials are tied to the interactive user session. SYSTEM doesn't have them.
Ran the task as iii\arthurlin with saved credentials. Same problem — the task runs in a non-interactive context, which doesn't have access to the cached PEAP/802.1X credentials. The WiFi connect request completes but authentication fails silently.
Wrote a PowerShell script that loops every 30 seconds and reconnects if WiFi is down. Started it from an SSH session. It worked — until the WiFi dropped, which killed the SSH session, which killed the script. Windows OpenSSH puts all child processes in a "job object" that gets terminated when the session ends. Unlike Linux, orphaned processes don't survive.
Tried using netsh wlan show interfaces to check WiFi status. Windows 11 requires location services to be enabled for this command. Without it, it returns "Access denied" even with admin — causing the script to think WiFi was always disconnected and repeatedly firing reconnect commands on an already-connected network.
The final solution uses Invoke-WmiMethod -Class Win32_Process -Name Create to launch the watchdog. WMI creates the process in the interactive desktop session — not as a child of SSH — so it survives SSH disconnects. The same trick was already proven for starting a Minecraft server on the same laptop.
For detection, we switched to Get-NetConnectionProfile -InterfaceAlias "Wi-Fi" which doesn't need location permissions. The watchdog checks every 20 seconds, and when WiFi drops, it fires netsh wlan connect and waits 60 seconds for the WPA2-Enterprise/PEAP authentication to complete.
A VBS launcher in the Windows Startup folder ensures the watchdog starts automatically on login.
On the DGX side, NetworkManager is configured with autoconnect-retries=0 (retry forever). Previously, when the hotspot died during a WPA handshake, NetworkManager interpreted the failure as a wrong password and gave up permanently. Now it keeps retrying until the hotspot comes back.
The DGX is a shared machine — multiple people use it with sudo access. We can't let other users pivot through the Tailscale mesh into personal devices.
The DGX is enrolled in Headscale with forced_tags: [tag:dgx] — server-enforced, can't be removed by anyone on the machine, even with root. The ACL policy:
{
"acls": [{
"src": ["arthur@"],
"dst": ["arthur@:*", "tag:dgx:22,8080", "autogroup:internet:*"]
}]
}
Translation: personal devices can SSH in (port 22) and reach this web server (port 8080). The DGX has zero outbound access through the mesh — it cannot reach the home server, cannot reach the laptop, cannot browse the internet through the exit node. One-way street. The enrollment used a single-use pre-auth key with the tag baked in. All old reusable untagged keys have been revoked.
flowchart TD
Mac["MacBook\n(arthur@)"] -->|"SSH, HTTP"| DGX["DGX Spark\n(tag:dgx)"]
Jason["jason\n(arthur@)"] -->|"HTTP proxy"| DGX
Mac <-->|"all ports"| Jason
Mac -->|"exit node"| Internet["Internet"]
DGX -.-x|"BLOCKED"| Mac
DGX -.-x|"BLOCKED"| Jason
DGX -.-x|"BLOCKED"| Internet
style Mac fill:#1a1a1a,stroke:#76b900,color:#76b900
style Jason fill:#1a1a1a,stroke:#76b900,color:#76b900
style DGX fill:#1a1a1a,stroke:#ff4444,color:#ff4444
style Internet fill:#1a1a1a,stroke:#555,color:#999
Here's the complete picture of how this page gets from the DGX to your screen:
flowchart TB
subgraph Internet
Browser["Your Browser"]
CF["Cloudflare DNS"]
end
subgraph Home["Home Server (jason)"]
Nginx["nginx\n(reverse proxy, TLS)"]
HS["Headscale\n(coordination)"]
DERP["DERP Relay\n(TCP 443)"]
end
subgraph Office["Company Office"]
DGX["DGX Spark\n(Docker: web server)"]
Laptop["Dynabook\n(WiFi + ICS hotspot)"]
Watchdog["WiFi Watchdog\n(auto-reconnect)"]
end
Browser -->|"1. DNS lookup"| CF
CF -->|"2. Returns 125.229.144.147"| Browser
Browser -->|"3. HTTPS request"| Nginx
Nginx -->|"4. Proxy via mesh"| DERP
DERP -->|"5. Encrypted relay"| DGX
DGX -->|"6. HTML response"| DERP
DERP --> Nginx
Nginx -->|"7. HTTPS response"| Browser
Laptop -->|"ICS hotspot"| DGX
Watchdog -->|"reconnects WiFi"| Laptop
DGX -->|"Tailscale\n(TCP 443)"| DERP
HS -.->|"coordination"| DGX
style Browser fill:#1a1a1a,stroke:#555,color:#e0e0e0
style CF fill:#1a1a1a,stroke:#f6821f,color:#f6821f
style Nginx fill:#0a1a00,stroke:#76b900,color:#76b900
style HS fill:#0a1a00,stroke:#76b900,color:#76b900
style DERP fill:#0a1a00,stroke:#76b900,color:#76b900
style DGX fill:#0a1a00,stroke:#76b900,color:#76b900
style Laptop fill:#1a1a1a,stroke:#555,color:#999
style Watchdog fill:#1a1a1a,stroke:#555,color:#999
This page was built in a single day. The architecture, debugging, security reviews, and five rounds of WiFi watchdog failures were all worked through in one long session. If you're curious about who (or what) helped — well, the page has its secrets. Look closer.