域名先回答“去哪里”
DNS 记录把名称与相应目标联系起来，但不负责生成网站内容。域名已经解析，不代表目标上有服务；网站能通过平台地址打开，也不代表自定义域名关联正确。检查时分别记录解析、路由和部署目标。
代理不是万能加速开关
Cloudflare 代理模式与仅 DNS 模式的请求链路不同。是否适合代理，要考虑协议、端口和服务用途，不能把所有记录统一改成一种状态。NAS 管理、文件传输与静态博客的需求不同。“域名走了代理”也不表示 NAS 的所有出站请求都能走相同路径。
证书和访问权限分别验证
HTTPS 处理连接安全与服务身份验证的一部分，Access 等机制控制谁能访问。证书正常但要求登录，未必是故障；所有人能打开页面，也不能证明后台安全。测试公开博客时，应同时测试私人路径和备用入口。
一次只改一层
同时修改 DNS、代理、端口和后端地址，会让结果难以解释。保留原配置，再改一个变量，用相同方法比较前后。恢复正常后，记录真正起作用的变化，不把偶然恢复当作因果结论。
准备一份名称到内容的链路清单
本文的任务是给个人静态博客核对自定义域名，并在打不开时找到最先失败的一层。准备域名管理权、托管项目的公开标识、平台要求的记录类型，以及能匿名访问的测试文章路径。只读检查不需要服务器管理员权限；修改解析、代理状态与绑定配置属于写入，恢复旧配置可能中断当前访问。所有名称使用 example.com 占位，案例和响应均为示意，未对真实域名或设备运行。
先填清单：注册商管理域名归属与续期，权威 DNS 提供记录，代理可能接收浏览器连接，托管平台根据主机名和路径提供内容。几个角色可能由同一服务商提供，但仍要分别检查。尤其要区分“记录存在”与“这组名称服务器正在被使用”：改了未生效区域中的记录，界面看起来正确也不会改变访客查询结果。先核对委派关系，再考虑记录值。
| 层 | 预期 | 实际观察 | 下一步 |
| --- | --- | --- | --- |
| 域名归属 | 本人维护 | 待核对 | 查注册管理入口 |
| 权威DNS | 当前委派使用本区域 | 待核对 | 查名称服务器 |
| 记录类型/值 | 托管平台要求 | 待核对 | 分别看A/AAAA/CNAME |
| 代理状态 | 与服务协议相符 | 待核对 | 查代理支持范围 |
| 主机名绑定 | 个人博客项目 | 待核对 | 比较项目标识 |
| HTTPS/内容 | 证书正常，文章正确 | 待测 | 记录首跳与内容 |
| 私人入口 | 匿名被拦截 | 待测 | 检查其他入口 |可复制工作表，示意且未实机验证；填写自己的材料，待测项不代表实际成功。
按记录类型解释查询结果
查询时分别看名称、类型、答案和生存时间。地址记录与别名记录表达不同关系，IPv4 与 IPv6 结果也应分别核对；只有一族正确时，部分网络仍可能失败。递归解析器缓存答案，因此修改之后不同客户端短时间内看到不同结果不一定是新配置被覆盖。记录原答案及其剩余时间，在约定观察窗口内重复同一查询，不要每几秒换一次配置。
代理开启时，公共查询通常看到代理网络地址，而不是托管源站地址；此时“没有返回我的源站地址”并非充分故障证据。若使用平台托管的自动绑定，要依照该绑定文档确认记录由谁维护，避免手工添加另一条互相冲突的记录。本文不假定固定地址或固定全球传播时长，也不建议为了看见源站而临时关闭保护。查询答案只完成名称层验收，之后仍需检查 HTTPS 与内容。
从连接和证书走到 HTTP 路由
名称正确之后，用浏览器或只读请求观察 HTTPS 能否建立。证书错误先核对访问的名称、证书覆盖范围和有效状态，以及平台绑定是否完成；不能用跳过验证把身份错误变成成功。代理与源站之间还有独立的连接和证书要求，浏览器到代理正常并不代表后半段也正常。把错误页面上的公开错误类别记录下来，再对照对应平台说明。
已经收到 HTTP 状态后，再检查它是不是预期站点：标题、文章路径和一项可辨识的公开文字比单纯二百状态更有用。四零四可能是路由没匹配，登录跳转可能是访问规则生效，五百类错误需要继续查服务端或代理层。不要自动跟随所有重定向后只保留最后状态，否则会丢掉从正式域名跳回平台地址的证据。先记录首跳，再有意识地检查完整跳转链。
nslookup -type=NS example.com
nslookup -type=A example.com
nslookup -type=AAAA example.com
curl -sS -D - -o /dev/null --connect-timeout 5 --max-time 15 'https://example.com/'逐条观察；example.com 是占位演示，只可替换为自己授权检查的地址；不会跟随跳转。未实机验证。
完整案例：平台入口正常，自定义域名出现旧内容
构造情景是新部署的文章在平台预览入口可见，自定义域名仍显示旧标题。先用同一文章路径比较内容版本，排除拿首页与文章页互相比较。接着核对正式主机名绑定的项目标识、DNS 记录目标以及代理状态，观察请求是否被重定向。若绑定仍指向旧项目，就有一条能解释现象的因果链，而不是先清浏览器缓存。
只修改确认错误的绑定关系，保留原值和旧部署供恢复。之后先查平台显示绑定已完成，再请求正式域名文章路径，最后检查图片与样式是否也来自预期版本。若绑定正确但内容仍旧，才查看缓存头、部署版本和浏览器是否保留旧资源。修复后至少从一个未登录会话重复相同步骤，记录结果为待测或实测，不伪造秒数。私人写作入口仍需通过身份检查，不能随公开文章一起放开。
症状表如何决定下一步
无法解析时回到权威记录与委派；连接超时则核对地址族、目标监听和现有网络路径；证书不匹配则查名称与绑定；拿到错误站点则查主机名路由；仅文章深链接四零四则查托管回退规则。每一步都应能说明为何前一层已排除。譬如已收到正确站点的错误页，通常不该继续反复更换 DNS，因为名称与连接至少已经走到应用。
macOS 自带工具和 GNU/Linux 发行版安装的 DNS 工具版本可能不同，先看本机帮助；DSM 可能使用精简命令或没有相同工具，优先在受控客户端诊断，不为一次查询修改 NAS 系统。下方 curl 示例在 macOS 与常见 GNU/Linux 可用，选项仍应按安装版本核对；它会发网络请求并留下访问日志，但不修改站点配置。模板适用于任何平台，不依赖控制台按钮位置。
# 域名变更记录
目标主机：example.com（替换）
本次只改：<记录值/主机绑定/其他单项>
旧值：<待填>
新值：<待填>
依据：<哪条观察证明旧值错误>
保存前内容版本：<待填>
保存后解析、HTTPS、文章、私人入口：<分别填>
观察窗口及原因：<按实际缓存与平台状态>
恢复对象与旧值：<待填>
恢复后复测：<待测>
说明：保存配置为write；覆盖/中断既有访问为danger。可复制工作表，示意且未实机验证；填写自己的材料，待测项不代表实际成功。
完成与恢复的边界
验收清单需要同时包含正式域名、代表性文章、静态附件、非存在路径，以及私人入口的匿名响应。公共文章可读只证明公开阅读链路成立；后台被拦截也不能代替后台接口和附件的检查。如果某个备用入口还保留旧内容，写明它是否应保留、重定向或停用，不要因为不常使用就从资产清单中删掉。
恢复时按最小变化反向处理，例如仅恢复原绑定，不一并改代理和证书策略。DNS 缓存使恢复也需要观察窗口，因此恢复按钮按下不代表所有访客立即回到旧版本。收尾保存最终记录值、绑定项目和已核对日期，删除的是笔记中的过时假设而非未经确认的服务记录。官方 DNS 与代理文档提供机制依据，本篇的逐层工作表是围绕个人博客任务组织的实践方案，仍待读者在自己的环境验证。
填写工作表，把示例变成自己的记录
填写文中的记录时，先在“预期目标”一栏抄下托管平台针对这个主机名给出的要求，再填“实际观察”。不要把猜测中的源站地址写作预期答案，代理模式可能刻意返回另一组地址。查询示例采用 nslookup，只用基本语法避免平台专属选项；若工具缺失，可使用自己已经授权的 DNS 管理界面记录答案，无需为此进入 DSM 安装软件。curl 示例不带登录凭据、不跟随跳转，目的是保留第一跳证据，example.com 只展示语法，不能验证你的个人站点。
观察表中的“下一步”应由差异决定。例如答案符合代理模式而 HTTP 返回旧站，应继续核对项目绑定；若答案不存在，则先停在解析层。完成后将待测替换为真实观察，写明查询位置与是否使用同一客户端。变更表只记录一项实际修改及旧值，恢复时按同一对象处理。若没有修改，就写“仅检查，无配置回退”，这样下一位读者不会误以为每次排障都必须动 DNS。