子域名架構設計

良好的子域名架構讓系統清晰、易於管理，也有助於 SEO 和安全隔離。

常用子域名慣例

子域名 vs 子路徑：SEO 的選擇

對於博客、電商等內容，SEO 上的選擇：

子域名方式：
blog.example.com/article
shop.example.com/product
子路徑方式：
example.com/blog/article
example.com/shop/product

SEO 建議：使用子路徑

• Google 把子域名視為獨立網站，SEO 權重不共享
• 子路徑繼承主域名的 SEO 權重
• 例外：如果博客內容與主業務完全不同，子域名更合適（避免主題混亂）

Shopify 的建議（電商場景）： - shop.example.com 指向 Shopify（子域名，Shopify 技術要求） - 使用 Shopify Markets 的子路徑（example.com/en-us）更好

多環境子域名架構

Production（生產）：
www.example.com      → 用戶流量
api.example.com      → API 服務
cdn.example.com      → 靜態資源
Staging（測試）：
staging.example.com  → 部署前測試
api-staging.example.com
Development（開發）：
dev.example.com      → 開發環境（本機）
localhost:3000       → 本地開發

環境隔離原則： - dev 和 staging 不應該對外公開（加密碼保護或 IP 限制） - 測試環境的域名不需要 SSL 公開憑證（可以用 Let's Encrypt） - 確保測試環境的 DNS 記錄不會影響生產環境

通配符 DNS 記錄

通配符記錄覆蓋所有未明確定義的子域名：

*.example.com    A    93.184.216.34

效果： 任意子域名.example.com 都解析到同一個 IP

使用場景： - SaaS 產品（每個用戶有自己的子域名：user1.app.com、user2.app.com） - 測試環境（每個功能分支有自己的子域名）

注意： 通配符記錄優先級低於明確定義的記錄（www.example.com 的 A 記錄會覆蓋 *.example.com）

子域名接管（Subdomain Takeover）漏洞

危險場景：

你曾經設置：
CNAME    blog    username.github.io.
後來刪除了 GitHub Pages，但忘記刪除 DNS 記錄
攻擊者：
在 GitHub 創建 username 帳號
發布到 GitHub Pages
← 他們現在控制了 blog.example.com！

防護措施： - 刪除服務時，同時刪除對應的 DNS 記錄 - 定期審查所有 CNAME 記錄，確認目標服務仍然存在 - 使用 Subtake、Subzy 等工具掃描你的子域名是否有接管漏洞

子域名組織清單模板

建立一個文檔記錄所有子域名：

定期審查，刪除不再使用的記錄。

下一節：多雲與負載均衡 DNS——高可用架構的 DNS 配置。