diff --git a/src/content/posts/hardening-a-tor-onion-service.md b/src/content/posts/hardening-a-tor-onion-service.md
index 5899a03..345f62c 100644
--- a/src/content/posts/hardening-a-tor-onion-service.md
+++ b/src/content/posts/hardening-a-tor-onion-service.md
@@ -19,6 +19,21 @@ While I was researching how to do this right, a lot of what I read online talked
 
 So what does actually keep an onion service safe? I went through this properly when I set the mirrors up, and again months later when I went back to check on them. Some of the setup held up. Some of it had quietly broken. And a couple of things I believed about Docker turned out to be wrong in ways I could measure.
 
+## Tor and onion services, in thirty seconds
+
+Tor is an anonymity network: your traffic hops through three relays, and no single relay sees both who you are and where you're going. An onion service is the reverse direction, a server that lives *inside* the network. It gets a `.onion` address instead of a domain, visitors reach it only through Tor, and the server's real location never shows up in the connection.
+
+Four properties come out of that, and a normal website simply can't offer them:
+
+- **No public IP, no ports, no DNS.** Nothing for scanners to find. You can host it from a home connection behind CGNAT.
+- **No middlemen.** No CDN, registrar, or platform in the path recording who visits.
+- **The address itself is the access control.** People who have it can reach the site; everyone else can't even tell it exists. Add client keys on top when that isn't strict enough.
+- **It keeps working when the clearnet doesn't.** If a domain gets blocked or seized, the onion is untouched, because no registry is involved.
+
+What onion hosting suits: private file drops, portfolio and git mirrors, lawyer-to-counsel drafts, digital-goods delivery, any archive that should never appear in a search index. The people who want it are the ones for whom "nobody can even see that it exists" is the feature rather than a quirk: lawyers, auditors, freelancers sending deliverables, sources talking to journalists, and shops selling digital products over a channel their competitors can't scan.
+
+The honest tradeoff is speed. Tor circuits are slower than a CDN, so you wouldn't put a marketing site on one. It's the right tool for the private half of the internet, not the public half.
+
 ## What actually protects the origin
 
 Three things, and only the last one requires any work:
@@ -144,4 +159,12 @@ So: as a bolt-on for a handful of specific clients, yes. As a product line, no.
 - **Run the tests, not the config file.** In-container probes and health states are the truth; the yaml is the intention.
 - **Prefer mechanisms that can't silently unwind.** `internal: true` beats an iptables boot task every time.
 - **Healthchecks are cheap. They caught a crash loop in minutes** where previously nothing watched for days.
-- **The boring host firewall matters more than exotic Tor hardening.** Nobody de-anonymizes you with traffic analysis if they can just walk in through an open port.
\ No newline at end of file
+- **The boring host firewall matters more than exotic Tor hardening.** Nobody de-anonymizes you with traffic analysis if they can just walk in through an open port.
+
+## Want one of these?
+
+I build and run these for clients: creating an onion site, hosting and maintaining it (updates, healthchecks, monitoring), and mining branded addresses when a client wants a name instead of gobbledygook. If you need a site that exists only for the people you choose, this is exactly what it does.
+
+- WhatsApp: [wa.me/60127972969](https://wa.me/60127972969)
+- Email: [me@hoelee.com](mailto:me@hoelee.com?subject=Onion%20service%20setup)
+- What else I do: [hoelee.com](https://hoelee.com)
\ No newline at end of file
diff --git a/src/content/posts/zh/hardening-a-tor-onion-service.md b/src/content/posts/zh/hardening-a-tor-onion-service.md
index 47513e4..54ad42f 100644
--- a/src/content/posts/zh/hardening-a-tor-onion-service.md
+++ b/src/content/posts/zh/hardening-a-tor-onion-service.md
@@ -19,6 +19,21 @@ banner: /banners/hardening-a-tor-onion-service.png
 
 那么,真正让一个洋葱服务安全的是什么?我设镜像时认真走了一遍全程,几个月后又回头检查了一遍。有一部分配置经受住了考验,有一部分已经悄悄坏掉,还有几件我原本对 Docker 的认知,被实测证明是错的。
 
+## 三十秒搞懂 Tor 和洋葱服务
+
+Tor 是一个匿名网络:流量经过三道中继,没有任何一道中继能同时知道你是谁、要去哪。洋葱服务则是反过来的方向——一个生活在网络*内部*的服务器。它拿到的是 `.onion` 地址而不是域名,访客只能通过 Tor 网络访问它,服务器的真实位置永远不会出现在连接里。
+
+由此得到四个普通网站给不了的特性:
+
+- **没有公网 IP、没有端口、没有 DNS。** 扫描器无从发现。你可以用 CGNAT 后面的家用网络来跑(现在大多数家庭宽带都是)。
+- **没有中间商。** 路径上没有任何 CDN、注册商或平台记录谁来过。
+- **地址本身就是访问控制。** 拿到地址的人可以访问;其他人连这站存不存在都无法判断。要求更高时还能叠加客户端密钥。
+- **clearnet 挂了它还在。** 域名被墙或被没收,洋葱站毫发无损,因为没有注册局参与其中。
+
+洋葱托管适合这些:私密文件交接、作品集和代码仓库镜像、律师之间传草稿、数字商品交付、任何永远不该出现在搜索索引里的档案。会想要它的人,是把"没人能看出它的存在"当作特性而不是怪癖的人:律师、审计师、交付成果的自由职业者、给记者递料的线人、以及不希望自家数字商品渠道被同行扫描的商家。
+
+诚实的代价是速度。Tor 链路比 CDN 慢,所以你不会把营销站放上去。它是给互联网的"私密那一半"用的工具,不是给公开那一半用的。
+
 ## 真正保护源站的是三件事
 
 只有最后一件需要花力气:
@@ -144,4 +159,12 @@ wget -T 6 -qO- http://ipv4.icanhazip.com     # → <你的 IP>, exit 0
 - **跑测试,别读配置文件。** 容器内探针和健康状态是真相,yaml 只是意图。
 - **优先选择无法静默解体的机制。** `internal: true` 永远胜过 iptables 开机任务。
 - **healthcheck 很便宜。** 它几分钟就抓到了一个崩溃循环,而之前没人看着,坏了好几天。
-- **朴素的主机防火墙比花哨的 Tor 加固重要。** 如果攻击者能直接从一个开着的端口走进来,就不会有人费劲用流量分析去匿名化你。
\ No newline at end of file
+- **朴素的主机防火墙比花哨的 Tor 加固重要。** 如果攻击者能直接从一个开着的端口走进来,就不会有人费劲用流量分析去匿名化你。
+
+## 想要一个吗?
+
+我帮客户做这类东西:创建洋葱站点、托管和维护(更新、健康检查、监控),以及应要求挖一个品牌前缀的地址,让地址以名字开头而不是一串乱码。如果你需要一个"只有你选的人才能访问"的网站,这套东西做的正是这个。
+
+- WhatsApp: [wa.me/60127972969](https://wa.me/60127972969)
+- 邮箱: [me@hoelee.com](mailto:me@hoelee.com?subject=Onion%20service%20setup)
+- 我还做什么: [hoelee.com](https://hoelee.com)
\ No newline at end of file