Building a China Exit Node in My Homelab

Tue, 07 Jul 2026 20:45:00 +0800

I ended up building a China-facing VPN path in my homelab for a very unglamorous reason: some devices simply behave better when they think they are on a China network.

Not faster. Not more elegant. Just better.

This was one of those projects that started with a minor annoyance and slowly turned into a proper piece of infrastructure. A few smart devices and Android-based appliances in my lab were technically online from Singapore, but the experience was inconsistent enough to be irritating:

app sessions behaved strangely
local control broke and then came back
firmware updates changed behaviour in ways that did not make much sense
some cloud-backed features were clearly happier when traffic exited from China

That was enough for me to stop treating it as random consumer device weirdness and build a proper path for it.

The Real Motivation

I did not want a full-network VPN.

That would have been lazy and honestly a bit reckless. The whole point of a homelab is to make systems more understandable, not to put everything behind an opaque tunnel and hope for the best.

What I wanted was much narrower:

only the problematic devices should use the China path
the rest of the lab should stay exactly as it was
I should be able to observe every hop
I should be able to disable the whole thing quickly if the experience was bad

That last point ended up being more important than I expected.

The Basic Idea

At a high level, the path looked like this:

I am intentionally keeping this generic. No public IPs, no public hostnames, and no details that would help anybody map the external edge of the setup.

The useful part of the story is the shape of the design, not the sensitive values.

Why This Needed to Exist

I have learned, sometimes the hard way, that many consumer devices are regional even when vendors do not clearly say so.

On paper they are internet-connected devices. In reality they are often tightly coupled to where their backend expects them to be. You notice it when something feels “almost working” but never completely stable.

I saw this with a mix of devices in the lab, and one case in particular made the pattern obvious: a device that was perfectly alive on the local network, but much happier when its traffic path looked Chinese.

Once I saw that, the solution stopped being “let’s keep trying random app settings” and became “let’s build a controlled network path and test it properly.”

The Nodes in the Chain

Each piece in the design had a small job and nothing more.

Main gateway

My main OpenWrt router stayed as the normal gateway for the house and the lab.

Its special role here was only policy routing. For selected source IPs, it could choose a different next hop instead of the normal WAN path. That meant I did not have to trust a consumer device to run a VPN client properly.

Singapore relay

The Singapore-side relay was a small Linux box that already had WireGuard in the lab.

It became the transit hop for selected traffic. This was a very practical place to do it because I could inspect it, route around it, and instrument it without much overhead.

China router

The China-side node was the real exit.

It terminated the WireGuard path and NATed traffic out locally. This was the point where traffic stopped being “just tunneled” and became regionally meaningful.

In practical terms, this node is a Raspberry Pi connected to China Unicom at an intentionally undisclosed spot in Hangzhou. That was enough realism for the experiment without turning the post into a map of the setup.

Sanitized Architecture Diagram

This is the version I am comfortable publishing:

It captures what matters without exposing anything that should stay private.

Why WireGuard

There was never much doubt here.

WireGuard is simple, lightweight, and fits small ARM hardware very well. I already use it elsewhere in the lab, so it did not introduce a new operational model. More importantly, it is easy to reason about when something goes wrong.

That mattered because I did not want a feature-rich VPN box. I wanted a narrow, inspectable transport layer.

Why I Did Not Rely on Client-Side VPN

I tried thinking from the client side first, especially with embedded Android devices.

That turned out to be a bad use of time.

Some of these devices will let you install or configure a VPN app, but they do not behave like a normal phone or laptop. They may show a profile, suggest they are connected, or partially integrate with the system UI while never actually emitting the expected tunnel traffic.

That is the kind of thing that can waste hours if you do not verify it from the network.

So I pushed the logic back into the infrastructure:

the main router decides who should use the path
the relay decides how traffic enters the tunnel
the exit node decides how traffic leaves

That is much more reliable than hoping a consumer device understands its own VPN state.

The Part I Enjoyed Most: Observability

The VPN itself was not the fun part.

The fun part was making the whole chain visible enough that I could answer real questions instead of guessing:

is the device actually sending traffic?
did the gateway match the policy route?
did the relay forward packets into WireGuard?
did the China node receive them?
did replies come back?
is the failure in routing, in the app, or on the remote side?

That visibility came from a mix of:

Prometheus
Grafana
WireGuard counters
packet captures
syslog
Loki
blackbox probes

This is where the project stopped being “a VPN hack” and became proper infrastructure.

What the Path Actually Did

The packet flow was simple enough:

That logic was easy to document and, more importantly, easy to test.

What I Learned the Hard Way

One of the more useful lessons from this project was that a path can be technically correct while still being operationally bad.

I had moments where I could prove the traffic was taking the expected route. Packet captures lined up. Counters moved. Replies came back. From a routing perspective, it was real.

And still, the actual user experience on some devices was disappointing.

That matters.

It is very easy to declare victory too early in network experiments. “The packets pass” is not the same as “the device works well.” Regional backend behaviour, resets, protocol assumptions, and application quirks can still make the experience poor even when the routing is exactly right.

That is one reason I made reversibility a hard requirement.

Reversibility Was Not Optional

I wanted a setup that I could shut down without drama.

That meant:

named rules instead of random manual state
clear enable and disable points
no mystery dependency hiding in the middle

In hindsight, this was probably the most important design choice.

If a special path cannot be turned off easily, it becomes dangerous. Not because it is malicious, but because it quietly becomes part of the environment before you fully trust it.

I did not want that.

Why I Still Like This Project

Even if a specific device does not end up using the path permanently, the China exit node is still useful.

It gives me:

a real China-origin test path
a way to validate how regional devices behave
a better understanding of policy routing in my own lab
a reusable building block for future experiments

That is enough for me to consider it worthwhile.

It also reminded me of something I keep relearning in homelab work: sometimes the most interesting infrastructure is built not for scale, but for explanation.

The XGIMI Case

One of the best examples in this project was an XGIMI projector running Android.

It was a perfect candidate for the China path, at least on paper. The device is clearly tied to a China-centric ecosystem, and I wanted to see whether giving it China egress at the network level would make it behave more naturally.

My first thought was the obvious one: install or configure a VPN client on the projector itself.

That went nowhere.

The device would accept some configuration, but from the network side it was not behaving like a proper client. I could not see the expected tunnel traffic leaving it, which made the whole thing suspect. This is a good example of why I do not trust embedded Android UIs when it comes to networking. If a device claims to be connected but never emits the expected packets, the network wins the argument.

So I moved the logic back into the infrastructure and routed the projector at the gateway layer instead.

The policy-routing chain itself worked. I could verify that:

traffic from the projector was matched by the main gateway
the selected flows were forwarded to the Singapore relay
the relay sent them into WireGuard
the China-side node received them
return traffic came back through the same path

In other words, the routing was real. This was not a fake success caused by a bad assumption or a stale route.

But the user experience was still poor.

That was the important observation.

Some traffic patterns behaved well enough to prove the path was active, but the projector itself did not become reliably pleasant to use through that route. Certain flows were slow, some connections were reset, and the overall experience was not good enough to justify forcing the device through the China exit all the time.

From the traffic side, the pattern was quite revealing. I could see outbound connections taking the expected path, but some of them were answered almost immediately with resets from the remote side. A simplified example looked like this:

projector -> 203.0.113.10:443   SYN
remote    -> projector          RST

projector -> 203.0.113.11:443   SYN
remote    -> projector          RST

projector -> 198.51.100.20:443  SYN
remote    -> projector          RST

These are not the real addresses, just representative examples, but the behaviour was real enough: the routing path was alive, replies were coming back, and yet the application experience was still poor. That was an important distinction. The problem was no longer “is the tunnel working?” but “is this regional egress actually good enough for this device?”

That was a useful outcome, even if it was not the outcome I originally wanted.

It showed that:

the routing design was sound
the observability stack was doing its job
regional egress can help some devices
but not every China-market device benefits equally from the same path

This is probably the most practical lesson from the whole setup: routing works for some devices, and for others it does not improve the experience enough to be worth keeping. The only way to know which is which is to test them properly and watch the traffic end to end.

In the case of the projector, I rolled the route back cleanly. That was not failure. That was exactly the kind of decision the design was supposed to make easy.

Lessons Learned

A route can be correct and still not be the right answer for the device using it.

That is probably the most useful takeaway from the whole experiment.

regional routing is worth testing when device behaviour clearly depends on backend geography
policy routing is much more reliable than trusting embedded devices to run their own VPN clients
observability is what makes the difference between debugging and guessing
a technically valid tunnel does not guarantee a good user experience
rollback paths are not a nice-to-have, they are part of the design

In short: routing works for some devices, and for others it does not improve the experience enough to justify keeping it. The job of the lab is to make that visible quickly.

Final Thoughts

Homelabs are often described as miniature datacenters, but sometimes they are really miniature negotiation layers between reality and badly behaved consumer hardware.

This project was one of those cases.

I did not build a China exit node because it looked cool in a network diagram. I built it because a few devices only behave properly when they feel closer to home, and in modern networking “home” is often just a routing decision.

If there is one idea I would keep from this whole exercise, it is this:

Make the special path visible. Make it selective. And make sure you can turn it off.

vpn on Antonio Space