
DigitalPlat FreeDomain 实战从域名注册到静态站点公网上线的完整部署流程【免费下载链接】US.KGFree domain registration and practical DNS learning resources for everyone.项目地址: https://gitcode.com/GitHub_Trending/us/US.KG本篇技术指南对应 DigitalPlat FreeDomain 教程US.KG 仓库Capstone 项目第三阶段 7.3 Register, Deploy, and Connect讲解如何在真实环境中完成外部 DNS 区域准备 → DigitalPlat 域名注册 → 委托验证 → Linux 服务器准备 → 文件部署 → Nginx 虚拟主机配置 → 公网 HTTP 验证 → 变更记录的完整链路。读完后你将掌握dig逐级验证 NS/SOA/A/AAAA/CNAME 记录的方法、可复制的 Nginx 站点配置以及 rsync 首次部署的安全实践并能独立完成一次带证据链的公网发布。下图为注册与名称服务器环节涉及的真实界面DigitalPlat 域名注册控件、注册时填写外部名称服务器的界面以及外部 DNS 服务分配名称服务器的示例界面后文 Step 1 与 Step 2 将逐一说明如何核对这些界面上的值阶段定位本步骤会创建外部状态Capstone 项目的前两个阶段项目简报与架构、站点构建与本地测试都在本地完成而 7.3 阶段 是整个教程中第一个会产生外部副作用的阶段注册域名会占用命名空间资源可能消耗配额slot或产生费用名称服务器一旦提交将进入父级 DNS 的委托流程。因此文档开头就要求在提交任何表单之前先逐项阅读当前的政策policy、主机名hostname、配额slot、费用charge和名称服务器nameserver值。整个阶段的架构如下与 项目简报 中定义的分工一致——注册账户负责委托控制但不参与每次页面请求的路径Visitor browser | | DNS query v Authoritative DNS service | | A / AAAA answer v Linux server | | TLS on 443 v Nginx | v /var/www/example.dpdns.org | -- index.html -- about.html -- styles.css沿用教程的虚拟规划值真实操作前请保持虚拟值直到步骤明确要求使用真实账户/域名/服务器Registered domain: example.dpdns.org Canonical site: https://example.dpdns.org/ Alias: https://www.example.dpdns.org/ Practice server: 192.0.2.10其中example.dpdns.org为规范域名canonical namewww子域为别名并应指向它.dpdns.org与.us.kg等后缀均由 DigitalPlat 提供具体可选后缀列表以仓库 README 及 Dashboard 公告为准。Step 1准备 DNS 区域权威 DNS 服务侧在权威 DNS 服务外部 DNS 服务商中为你打算注册的那个精确域名创建 zone区域。关键点有三zone 域名必须与即将注册的完整域名逐字一致。拼写错误的 zone 是最常见的注册失败原因之一参见 1.3 连接外部名称服务器 中的常见错误表常见错误正确做法把服务器 IP 当作 NS 值填入填入服务商分配的权威名称服务器主机名只填入部分名称服务器填入完整分配集合用错误拼写创建了 zone在委托前先修正或重建外部 zone把分配到的每一台名称服务器逐一记入项目笔记。这些值是主机名如ns1.dns-service.example、ns2.dns-service.example不是 DNS 解析器地址也不是网站 IP。注册前验证服务已识别该 zone——即服务商界面确认 zone 已创建且处于可解析状态再把这些名称服务器用于注册提交。若权威服务器上没有 zone注册后的委托验证必然失败应先修 zone再等待缓存。Step 2在 DigitalPlat Dashboard 注册域名进入 DigitalPlat Dashboard 后按以下顺序操作与 1.2 域名注册 的完整流程一致阅读 Dashboard 当前公告supported suffixes、注册暂停、slot 要求、价格、限制、续费窗口与政策都可能变化打开Register入口阅读所选后缀suffix对应的政策输入意图的主机标签label复核可用性、slot 占用情况及任何显示的价格当系统要求时填入 Step 1 准备好的外部权威名称服务器主机名核对最终完整域名标签 后缀拼写无误只有当每个值都与计划一致时才提交。注册属于不可轻易撤销的外部状态变更。提交后在Domain List中定位该精确域名记录注册结果与界面显示的到期日期expiration date不要把私有账户数据密码、恢复码、API 密钥等复制到公开的项目文档中——这一条在 项目简报 Step 6 的公私数据划分 中已有明确清单。如果注册结果为 pending 或 rejected应从界面给出的原因出发排查名称不可用、外部名称服务器无效、注册数据不完整或当前命名空间限制都是可能原因。Step 3验证 DNS 委托Delegation注册完成后委托验证分三层进行对应 2.0 委托与外部名称服务器 中同一域名的三个视图注册视图、父级 DNS 视图、子级权威视图第一层查询父级返回的 NS 记录dig NS example.dpdns.org dig trace NS example.dpdns.org以上使用虚拟域名实际操作请替换为你真实注册的域名。返回的名称服务器必须与你填入 DigitalPlat 的意图集合一致。dig trace从根服务器逐级追踪用于区分父级委托问题与子级 zone 问题。第二层直接询问权威服务器dig ns1.dns-service.example SOA example.dpdns.org如果权威服务器不发布该 zone查不到 SOA不要继续后续步骤——先修复外部 DNS 服务端的 zone。第三层故障模式对照当验证结果异常时可按 2.0 委托 给出的故障模式表快速定位故障层结果可能的故障层父级指向旧的 NS 主机名注册或父级委托未生效NS 主机名正确但查询超时外部权威服务或网络问题一台名称服务器应答、另一台不应答外部 DNS 同步或可用性问题SOA 提示 zone 不存在外部 DNS 服务缺少该 zoneNS 正常但 A 记录为空外部 DNS zone 中缺少普通记录Step 4准备 Linux 服务器在与 Capstone 服务器准备一致的 Debian/Ubuntu 系服务器上通用要求见 3.4 准备服务器公网 IPv4/IPv6、非 root 的 sudo 账户、放行 80/443 端口执行sudo apt update sudo apt upgrade sudo apt install nginx sudo mkdir -p /var/www/example.dpdns.org sudo chown -R $USER:$USER /var/www/example.dpdns.org逐条说明sudo apt update upgrade先同步索引再升级生产环境升级前建议审阅包变更sudo apt install nginx安装 Web 服务器mkdir -p创建站点目录路径与域名同名便于多站点区分chown -R $USER:$USER把目录属主交给当前用户这样后续rsync以普通用户身份推送文件时不需要额外提权也保持站点文件不被 root 独占。确认监听器与防火墙意图sudo ss -lntpss -lntp列出所有处于 LISTEN 状态的端口及进程。预期 nginx 监听 80安装后默认与 443 预留不要暴露无关的管理端口到公网。此阶段防火墙只需放行 TCP 80HTTPS 在下一阶段 7.4 配置证书时启用 443。Step 5用 rsync 部署文件从本地项目的父目录执行./capstone-site/是 Capstone 项目简报 规划的两页静态站点替换服务器地址与用户rsync -av ./capstone-site/ user192.0.2.10:/var/www/example.dpdns.org/ \ --exclude .git/ \ --exclude notes/ \ --exclude .env参数解读-a归档模式保留权限、时间戳、软链接递归复制-v输出传输明细便于核对--exclude .git/排除版本库元数据--exclude notes/排除项目笔记其中包含私有操作信息绝不能上公网--exclude .env排除环境变量文件防止意外泄露密钥。首次部署不要加--delete。--delete会删除目标端本地不存在的文件在你尚未确认源路径与目标路径完全正确之前使用它可能误删服务器上已有的内容。确认目录结构稳定后后续同步可再启用。部署完成后在服务器上确认只拷贝了预期内的公开文件find /var/www/example.dpdns.org -maxdepth 2 -type f -print对照本地清单人工核对应只有index.html、about.html、styles.css等公开文件不应出现笔记、私有配置或仓库元数据。Step 6配置 Nginx 虚拟主机创建站点配置文件/etc/nginx/sites-available/example.dpdns.orgserver { listen 80; listen [::]:80; server_name example.dpdns.org www.example.dpdns.org; root /var/www/example.dpdns.org; index index.html; location / { try_files $uri $uri/ 404; } access_log /var/log/nginx/example.dpdns.org.access.log; error_log /var/log/nginx/example.dpdns.org.error.log; }各指令的作用指令说明listen 80; listen [::]:80;同时监听 IPv4 与 IPv6 的 80 端口server_name该虚拟主机响应的主机名集合根域与www别名都要覆盖Step 7 的 Host 头测试正是验证这两条root站点文档根与 Step 4 创建的目录一致index目录索引文件命中location /时优先返回index.htmltry_files $uri $uri/ 404先按文件、再按目录查找找不到则返回 404避免目录穿越或误命中默认页access_log/error_log独立日志文件按域名区分便于排障与后续 监控启用并通过校验后再重载sudo ln -s /etc/nginx/sites-available/example.dpdns.org /etc/nginx/sites-enabled/example.dpdns.org sudo nginx -t sudo systemctl reload nginxln -s是 Debian/Ubuntu 的 sites-available/sites-enabled 约定启用站点即建立符号链接nginx -t做配置语法与连通性测试systemctl reload nginx平滑重载不中断现有连接。文档特别强调一条铁律配置测试失败后绝不允许 reload——失败的配置不应被加载进正在运行的服务此时应修正配置文件并重新nginx -t通过后才 reload。Step 7先于 DNS 做 HTTP 测试在域名尚未被公网解析前用Host头直接指向服务器 IP 测试虚拟主机匹配curl -I -H Host: example.dpdns.org http://192.0.2.10 curl -I -H Host: www.example.dpdns.org http://192.0.2.10两条请求都应命中 Step 6 定义的虚拟主机并返回 200。这一步的意义在于把Web 服务器配置问题与DNS 问题彻底解耦如果这里失败说明 Nginx 配置、防火墙或文件问题与 DNS 无关如果这里成功而后续公网请求失败问题就集中在 DNS 记录上。Step 8在外部权威 DNS 服务添加记录打开 Step 1 使用的外部权威 DNS 服务创建以下记录。注意记录必须建在外部 DNS 服务而不是 DigitalPlat——DigitalPlat 的职责止于委托delegation不提供普通 DNS 记录编辑器这一点在 1.3 章节 中有明确说明。根域 IPv4A 记录Name: Type: A Value: real-server-ipv4 TTL: 3600根域 IPv6AAAA 记录——仅在 IPv6 路径经过实际测试后才发布Name: Type: AAAA Value: real-server-ipv6 TTL: 3600www别名CNAME 记录Name: www Type: CNAME Value: example.dpdns.org TTL: 3600三个要点代表 zone 根即完整域名example.dpdns.orgTTL 统一取 3600 秒属于可快速回退的保守值日后调整记录时最长一小时缓存即过期CNAME 指向根域而非 IP这样www与根域始终解析到同一地址后续更换服务器只需改 A 记录一处。Step 9验证公网 HTTP记录生效后注意 TTL执行完整验证链dig A example.dpdns.org dig AAAA example.dpdns.org dig CNAME www.example.dpdns.org curl -I http://example.dpdns.org curl -I http://www.example.dpdns.org判读规则dig A返回的 IP 必须是真实服务器地址dig CNAME应显示www→ 根域的别名链两条curl -I都应返回 200且Server头来自你的 nginx。如果同时发布了 IPv6必须独立测试 IPv6 路径若 IPv6 不可达正确做法是删除错误的AAAA记录而不是留着它让一部分访客走上不可达的路径。经验法则见 3.5 部署与连接DNS 查询成功但 HTTP 超时通常指向服务器、防火墙或路由问题而不是 DNS 本身。Step 10记录本次变更文档要求把本次上线的全部关键值写入项目笔记私有清单如下域名与注册日期到期日期expiration date名称服务器集合DNS 记录及各自 TTL服务器地址部署修订版本deployment revisionNginx 测试结果nginx -t输出HTTP 验证结果Step 9 的 dig/curl 输出回滚值rollback values——即变更前旧的 DNS 值与文件位置供 7.1 项目简报 中 Rollback 计划使用。这份变更记录是后续验收的依据7.4 安全与运维阶段 将在此基础上签发证书、配置规范重定向与备份监控7.5 最终验收 则会逐条核对委托匹配、A/AAAA 正确、www 有意解析等 DNS 验收项。小结本阶段建立的证据链整个 7.3 阶段的价值在于每一步都留下了可验证产物形成一条完整的证据链zone 就绪外部 DNS 服务识别 zone 且名称服务器集合已记录注册完成Domain List 中的状态与到期日期委托成立dig NS/dig trace NS/dig ns SOA三层验证通过服务器就绪ss -lntp显示的监听器符合防火墙意图文件在位find输出只含预期公开文件虚拟主机命中Host头双请求均 200公网解析正确dig A/AAAA/CNAME与服务器一致curl -I双域名 200变更可回滚笔记中包含旧值与回滚值。任何一步缺少证据都应先补齐验证再继续下一阶段——这是 Capstone 教程完成 有证据的结果而非看起来正确的配置这一原则在部署阶段的直接体现。【免费下载链接】US.KGFree domain registration and practical DNS learning resources for everyone.项目地址: https://gitcode.com/GitHub_Trending/us/US.KG创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考