Use a $6 VPS to Bring External Network Security Back Into Your Own Hands

I’m not a network engineer, but I don’t want to trust my traffic to an unfamiliar proxy service provider.

If you don’t want to read the long post, just copy the prompt below and give it to ChatGPT, Claude, Codex, or any AI agent that can control a terminal.

This is exactly what my assistant actually did last night.

He’s going back to China on Monday, and after returning, he still needs stable access to the external internet.

Here’s his complete process, for your reference.

Initially, his computer already had Shadowrocket and a proxy subscription. The nodes looked plentiful: Hong Kong, Japan, Singapore, United States, South Korea, Taiwan — all options were there.

The existing proxy subscription existed, but it wasn’t his exit

Could it work? Probably yes.

But what I was really worried about wasn’t whether I could open a webpage — it was: who exactly is receiving my traffic?

The proxy provider might not see the actual content within HTTPS, but they can at least see connection metadata. When you connect, which domains or IPs you connect to, how much traffic you use — all of this could end up in someone else’s hands. Worse still, if you set Shadowrocket to global proxy, your banking apps, Apple ID, primary email, verification codes, password manager, and background sync could all be routed through the same unknown exit.

This isn’t to say that proxy providers are inherently bad.

The problem is: you have zero control.

Who controls the subscription link? Who maintains the nodes? Who pushes the routing rules? Are logs retained? Will the nodes change later? You have no idea. You’re just buying convenience.

So I made a decision: I could keep the proxy subscription as a backup, but the primary exit would be self-hosted.

The process was simpler than I expected.

Step 1: Buy an overseas VPS.

I chose DigitalOcean, Singapore region, Ubuntu 24.04 LTS, Basic Shared CPU, 1GB RAM / 1 vCPU, at $6 per month. 512MB RAM could theoretically work, but there’s not enough headroom for system updates, installing services, or debugging issues — not worth saving that $2.

Create VPS, choose Ubuntu 24.04, Singapore, Basic plan

Recommendation between the lowest tier and 1GB: go with 1GB

One key point here: choose SSH Key for authentication, not Password.

Password login works, but for a long-running server like this, SSH key is the more reliable default. More importantly, throughout this process, you should never send your password, verification code, or private key to any AI. The agent can help you write commands, check configurations, and install services, but actions like payment, login, and key management must remain firmly in your own hands.

Step 2: Let the agent log into the server and install Hysteria2.

I didn’t have it handwrite a bunch of cryptic config files. It first SSH’d in to confirm the system version, then used the official installation script to install Hysteria2, generated a random password and obfuscation key, configured TLS certificates, and enabled systemd startup on boot.

Firewall: only open necessary ports.

During this, we hit a small but real pitfall: the service failed to start the first time.

The cause wasn’t network or certificate issues — it was overly tight file permissions. The Hysteria2 service runs under a dedicated hysteria user, but I had set the config directory to root-only access, so the service user couldn’t read the configuration file.

The agent read the log, pinpointed permission denied, and adjusted the permissions so the service user could read it. After the service started, the certificate was obtained successfully and it began listening on UDP 443.

This is exactly the kind of task an AI agent is best suited for: not making dangerous decisions for you, but reading error messages, searching documentation, and running verifications.

Step 3: Import the node into Shadowrocket.

This step is actually the most likely place where a non-technical person would get stuck.

A Hysteria2 link looks like this:

Note: When publicly sharing an image, you must blur the sensitive parts. The link contains a password — never post the original text.

I initially tried to fill in the fields manually, but the Shadowrocket Mac interface isn’t very intuitive. You can select the Hysteria2 type, fill in address, port, and password, but the obfuscation password field isn’t in an obvious place. Later, I discovered that one of the small icons on the main page is a “Paste” button that can parse the full link from the clipboard.

Shadowrocket main page, Paste icon location

Select Hysteria2 as the protocol when adding a node

If you encounter this situation, remember one sentence:

Do not paste the entire hysteria2:// link into the Address field.

Do not paste the full link into the Address — this is a common pitfall

Only put the domain in the Address. Use the import or paste feature to parse the full link.

Step 4: Test.

Don’t just trust the “connected” status in Shadowrocket. The real test is simple:

First, without proxy, visit:

Note your local exit IP.

Then, turn on Shadowrocket, and visit the same address again.

If the displayed IP is your VPS’s public IP, it means your browser traffic is going through your private node. I also ran a Google 204 test to confirm the link was working. Finally, I opened X, Google, and ChatGPT — all accessible normally.

Node added successfully (sensitive info blurred)

At this point, you’re not getting “absolute anonymity” or “magic invisibility.”

What you get is control.

Your exit IP is no longer shared with a bunch of strangers. Only you know your node’s password. Your subscription configuration isn’t pushed by someone else at any time. You don’t need to install an untrusted root certificate, and you don’t need to send all your sensitive logins through a shared proxy node.

Of course, the VPS provider still knows you rented this server. The internet services might also see your traffic coming from a cloud provider. It’s not a perfect privacy solution.

But it has one very important thing that a shared proxy subscription lacks: clear boundaries.

My current usage principles are:

• For general browsing, searching, using AI, or browsing X, use my own node.
• For sensitive operations like banking, exchanges, Apple ID, primary email, or password managers, try not to use a proxy — unless absolutely necessary, and only if you confirm the site is HTTPS with a valid certificate.
• Never install any root certificate that requires “acceleration.”
• Never enter passwords on HTTP pages.
• Never share your node link in group chats.
• If the link is leaked, immediately reset the Hysteria2 password and obfuscation key.

The biggest takeaway for me from this experience is: ordinary people can now truly bring a part of their infrastructure back under their own control.

In the past, you had to understand Linux, ports, TLS, and proxy protocols. Now, you just need to know what you want, which information cannot be handed over, and let an AI agent execute the steps, verify them, and fix errors.

The truly important thing isn’t “I know how to set up a proxy.”

It’s that when you need to work across regions, travel, or just want a stable, clean exit, you don’t have to entrust all your accounts, traffic, and privacy to a middleman you don’t understand.

Functionality is the minimum requirement; control is the source of security.

If you want to do this too, don’t just copy a one-click script from the internet. Start with the prompt at the beginning of this post, and let the AI guide you step by step. For things like buying the server, filling in payment details, and saving keys — you do those yourself. For installation, configuration, debugging, and verification — let the agent handle them.

Humans handle boundaries.

Machines handle execution.

This is probably the most practical use of AI I’ve experienced recently.