Domain on Margrop Blog

You Bought an Overseas VPS and a Domain. Now What? 12 Things That Make a Public IP Worth Owning

Sat, 11 Jul 2026 13:30:00 +0800

The short answer

An overseas VPS by itself is a powered, connected room without a memorable street address. A top-level domain by itself is only a sign. Put the domain on Cloudflare DNS and point carefully chosen records at the VPS, and you finally own the sign, the map, the storefront, and a standards-based public entrance.

The result is much more useful than “a place to host a blog.” It is a small, always-on piece of Internet infrastructure where you control the code and the migration path: websites, APIs, webhooks, status pages, monitoring, controlled file sharing, password management, remote-access relays, automation jobs, and a personal AI gateway can all grow from the same foundation.

A public IP is also a door facing a busy street. Automated scanners may try the handle shortly after the server appears. This guide therefore covers both the useful projects and the services that should never be exposed directly.

After Buying a Domain, Use Cloudflare Tunnel to Turn Home Services into Public HTTPS

Thu, 21 May 2026 11:38:00 +0800

Short version

The previous two posts covered the cheap-domain part and the Cloudflare DNS part: buy a low-cost .xyz domain for personal lab use, then move the domain to Cloudflare for nameservers, DNS, DDNS, email routing, and basic automation. This post continues with the next practical step: use Cloudflare Tunnel to expose an internal web service as a public https:// hostname. The important point is that visitors use standard HTTPS on port 443, while your home router does not need to forward ports 80 or 443 and your origin IP does not need to be exposed.

This article follows these two posts:

“Ten Years for 80 Yuan: Why I Prefer 6-Digit .xyz Domains for Personal Sites”
Original link: https://mp.weixin.qq.com/s/tbefnWGFI0QBFlRVcYjVEw
“Do Not Waste That 80-Yuan Ten-Year Domain: Put It on Cloudflare First”
Original link: https://mp.weixin.qq.com/s/h0o-vtGB_zj1aptaumBztQ

Those posts already covered buying a cheap .xyz domain, moving nameservers to Cloudflare, creating DNS records, using DDNS, and setting up email-related records. This post assumes that your domain is already active on Cloudflare. We will focus on one thing: publishing an internal web service through Cloudflare Tunnel with a clean public HTTPS hostname.

All examples in this article use documentation placeholders such as example.xyz, nas.speedtest.example.xyz, 192.0.2.10, localhost, and <TUNNEL_TOKEN>. No real domain, account, token, zone ID, private network address, or personal information is included.

After Buying an 80-Yuan 10-Year Domain, Hand the Rest to Cloudflare

Wed, 13 May 2026 08:46:06 +0800

The short version

Buying a cheap domain is only the first step. The real value starts when you move authoritative DNS to Cloudflare: DNS records, dynamic DNS, business email verification, mail forwarding, certificate automation, and even Agent-assisted configuration through scoped API Tokens can all live behind one clean control plane. The previous article covered how to buy a low-cost .xyz domain for roughly 80 RMB for 10 years. This one continues from there: how to connect that domain to Cloudflare, the generous infrastructure provider many people jokingly call a public good of the Internet, and how to use it efficiently without leaking secrets.

All screenshots and examples in this article use safe placeholders such as example.xyz, 203.0.113.10, and 2001:db8::10. They do not contain real domains, real IP addresses, Cloudflare account identifiers, Zone IDs, API Tokens, or private network information. Replace the placeholders with your own values when you follow the steps.

Ten Years for 80 Yuan: Why a 6-Digit .xyz Domain Is Good Enough for Personal Labs

Tue, 12 May 2026 19:10:00 +0800

Short version

If the domain is for a home lab, personal testing, temporary demos, API callbacks, development services, or other non-formal websites, I would first look at low-cost .xyz domains. In China, Tencent Cloud often makes this especially convenient for domestic users. For some pure numeric .xyz names with six or more digits, the checkout page may show a very low first-year and renewal price. If the price is 8 RMB per year, buying 10 years costs only 80 RMB.

This is not a recommendation for company websites, public products, serious brands, payment systems, or long-term marketing pages. For those, a readable and trustworthy brand domain is still worth the money.

When people start building a personal website, home lab, NAS callback endpoint, temporary API, reverse proxy, monitoring page, or small side project, they often overthink the domain name. Should it be a .com? Should it be short? Should it look like a real company? Should it use pinyin, English words, initials, or a private nickname?

My practical answer is: first decide what the domain is supposed to do.

If it is a serious public identity, choose the name carefully. If it is just a personal utility domain, do not spend too much money or attention on the name. In that case, the domain is not a brand asset. It is a stable handle for DNS, HTTPS, reverse proxy rules, ACME certificates, third-party callbacks, object storage, and temporary services.

Why a NAS hostname with `speedtest` can sometimes be much faster

Fri, 24 Apr 2026 09:00:00 +0800

Short version

If your NAS is painfully slow when accessed from outside your home, and you control both your domain name and your reverse-proxy entry, putting speedtest into the subdomain can sometimes make a dramatic difference.
This is not magic and it is not guaranteed, but it often appears to hit a more permissive carrier policy path for “speed-test-like” traffic.

This post was inspired by a discussion on the fnNAS forum. The original thread makes a very direct claim: some home broadband lines seem to throttle ordinary NAS access quite aggressively, but once the hostname contains speedtest, the connection can suddenly behave much better.

I am not repeating the forum post word for word. Instead, I am turning the idea into a longer-lived technical note that answers three questions:

Why this trick can work
How to set it up with the least amount of moving parts
When it will not work, or is not worth the effort

Let's Encrypt verifies domain name validity through DNS TXT records

Tue, 19 Jan 2021 10:39:58 +0800

When we use letsencrypt to obtain the free HTTPS certificate, letsencrypt needs to verify the domain name. By default it authenticates like this: The certbot program places a file in the root directory of the web directory. The server of letsencrypt accesses this file through the domain name to verify that the domain name you applied for belongs to you. But sometimes we want to set HTTPS for a certain host on the intranet.