[{"content":"“域名已经指向服务器了，怎么还是打不开？”这个问题看起来只有一句，实际上跨过了几层不同的系统。把它们混在一起，很容易改完 DNS 又改证书，最后连最初的问题都找不到。\n解析只是第一步 DNS 负责把名字映射到地址。A 记录返回 IPv4 地址，AAAA 记录返回 IPv6 地址。它并不检查服务器里有没有网站，也不负责替应用启动进程。\n在 Windows 上可以先查：\nResolve-DnsName www.example.com -Type A 这里需要关心两件事：结果是不是预期地址，以及有没有一条不再使用的 AAAA 记录。如果客户端优先访问 IPv6，而 IPv6 的网站入口没有配置好，可能出现有些设备能开、有些不能开的现象。\n接下来才是连接 拿到 IP 后，浏览器还要建立网络连接。HTTPS 通常使用 TCP 443，HTTP 通常使用 TCP 80。服务器上的进程监听、操作系统防火墙、云平台防火墙，都可能影响连接。\nss -lntp curl -I --connect-timeout 5 https://www.example.com/ ss 告诉你谁在本机监听，curl 则从发起请求的一侧观察结果。只在服务器自己访问成功，不能证明公网入口正常。最好再用手机网络或另一台机器验证。\nHTTPS 还多一层证书 连接成功后，浏览器会检查证书是否可信、是否过期，以及证书是否覆盖访问的域名。example.com 和 www.example.com 是不同的主机名，证书需要包含实际使用的名字。\n不要把忽略证书验证当作修复方法。它只能帮助区分问题在哪一层，不能让证书本身变得正确。\n最后才到网站 同一个 IP 可以运行多个网站。Nginx 会根据域名选择对应的站点配置；如果没有匹配，可能出现默认页、404，或者另一个站点。此时继续修改 DNS，通常已经偏离了问题。\n比较实用的排查顺序是：查解析 → 查端口连接 → 查证书 → 查站点路由 → 查应用日志。每一步只验证一件事，结果记录下来。遇到相似的问题时，能更快知道从哪一层开始。\n","permalink":"https://www.dopzn.cn/posts/dns-and-https/","summary":"\u003cp\u003e“域名已经指向服务器了，怎么还是打不开？”这个问题看起来只有一句，实际上跨过了几层不同的系统。把它们混在一起，很容易改完 DNS 又改证书，最后连最初的问题都找不到。\u003c/p\u003e","title":"域名能解析，为什么网页还是打不开"},{"content":"启动命令没有报错，终端里也出现了绿色的 active，很容易让人以为部署已经结束。实际上，进程存活、端口监听和业务可用，是三个不同的检查点。\n先看服务状态 以一个名为 example.service 的服务为例：\nsystemctl status example.service --no-pager journalctl -u example.service -n 80 --no-pager 状态里除了 active，还要看启动时间、主进程，以及是否反复重启。应用启动很快就退出，而 systemd 又把它拉起时，偶尔看到的绿色状态可能具有迷惑性。\n日志不要只截最后一行。真正的原因可能在前面，比如读取配置失败、工作目录错误，或者依赖的数据库连接不上。\n确认监听地址 ss -lntp 127.0.0.1:8080 表示只监听本机回环地址。它适合放在同机反向代理后面，但外部不能直接访问这个监听地址。0.0.0.0:8080 表示监听所有 IPv4 接口，也不等于云防火墙已经允许外部流量。\n先确定预期架构，再判断监听是不是正确。不是所有服务都需要暴露到公网。\n检查真实请求 健康检查返回 200 是一个信号，但不一定覆盖实际功能。一个博客至少要检查首页、文章页、样式文件和不存在的页面；有账号的应用，还要确认未登录时不会直接看到私密内容。\n如果使用反向代理，建议分别检查后端本地地址和公开域名。后端正常而公开域名异常，问题就更可能在代理、证书或者入口网络。\n留下一条恢复路径 变更前保留旧配置，修改后先做语法检查，确认无误再重载。Nginx 的常用做法是：\nnginx -t systemctl reload nginx 这两步有先后关系：第一步失败，就不应继续执行第二步。把恢复命令和验证地址一起记下来，比只留下“已经部署”四个字有用得多。\n","permalink":"https://www.dopzn.cn/posts/linux-service-checklist/","summary":"\u003cp\u003e启动命令没有报错，终端里也出现了绿色的 \u003ccode\u003eactive\u003c/code\u003e，很容易让人以为部署已经结束。实际上，进程存活、端口监听和业务可用，是三个不同的检查点。\u003c/p\u003e\n\u003ch2 id=\"先看服务状态\"\u003e先看服务状态\u003c/h2\u003e\n\u003cp\u003e以一个名为 \u003ccode\u003eexample.service\u003c/code\u003e 的服务为例：\u003c/p\u003e","title":"一个 Linux 服务启动后，还要检查什么"},{"content":"一次修改里面混着功能调整、格式整理和文件重命名，提交时很省事，回看时却很费力。尤其是需要撤销其中一项改动时，很难确定另一项会不会一起受影响。\n按目的拆分，而不是按文件拆分 假设要修复文章页面的目录链接，同时调整首页字体。虽然都属于博客样式，但它们解决的是两个独立问题，适合分成两次提交。\n反过来，一个功能可能同时涉及模板、样式和配置。这几个文件一起构成完整行为，放在同一个提交里更容易理解。\n提交之前看两次差异 git status --short git diff git add -p git diff --cached 第一次看全部修改，确认有没有临时调试代码或无关文件。第二次看暂存区，确认这次真正准备提交什么。git add -p 可以按片段选择，适合把同一文件里的不同目的修改分开。\n尤其要注意配置文件。测试时临时写入的令牌、账号或服务器地址，不应因为顺手执行了 git add . 就进入仓库。.gitignore 也不会自动停止追踪已经提交过的文件。\n提交说明写清结果 “修改代码”“修复问题”都没有留下太多线索。更有用的写法是说明触发条件和改变后的行为，例如：\n修复窄屏下文章目录遮挡正文的问题 如果原因不明显，可以在正文里解释为什么这样改、有没有取舍。无需把每个文件名再抄一遍，Git 本来就记录了这些信息。\n小提交也要完整 小不等于碎。一个提交最好可以独立构建或运行，不依赖下一次提交才能恢复正常。这样无论做代码审阅、定位回归还是回退，边界都更清晰。\n把提交当成写给未来自己的说明：当细节已经忘记，仍然能用几分钟重新理解当时的决定。\n","permalink":"https://www.dopzn.cn/posts/git-small-commits/","summary":"\u003cp\u003e一次修改里面混着功能调整、格式整理和文件重命名，提交时很省事，回看时却很费力。尤其是需要撤销其中一项改动时，很难确定另一项会不会一起受影响。\u003c/p\u003e\n\u003ch2 id=\"按目的拆分而不是按文件拆分\"\u003e按目的拆分，而不是按文件拆分\u003c/h2\u003e\n\u003cp\u003e假设要修复文章页面的目录链接，同时调整首页字体。虽然都属于博客样式，但它们解决的是两个独立问题，适合分成两次提交。\u003c/p\u003e","title":"让 Git 提交小一点，回头看时会轻松很多"},{"content":"看到备份任务显示成功，很容易松一口气。但“归档文件生成了”和“以后能够恢复服务”之间，还有不少细节。\n先列出恢复需要什么 对于静态博客，文章源文件、主题版本、自定义模板和配置通常比生成后的 HTML 更重要。对于数据库应用，还需要考虑数据库的一致性快照、上传文件和必要的密钥。\n不要仅凭目录名字决定备份范围。应用实际读取的配置可能不在安装目录，上传数据可能在另一个挂载点。记录版本和启动方式，也属于恢复资料的一部分。\n校验和能解决什么 sha256sum site-backup.tar.gz 校验和可以帮助判断文件传输前后是否一致。它不能证明归档里包含了所有必需文件，也不能证明数据库快照可用。备份完整性需要从“文件没坏”和“内容够用”两个角度确认。\n在隔离位置恢复一次 恢复演练应该写入新目录或独立测试实例，避免覆盖正在使用的数据。检查文件能否解压、权限是否合适、程序能否读取配置，然后用实际请求验证功能。\n如果涉及数据库，要使用与备份格式兼容的版本。直接把运行中的数据库目录复制出来，不一定能得到一致的数据，应优先使用数据库支持的备份方法。\n别把所有副本放在一起 同一块磁盘上的多个压缩包，可以应对误改文件，却无法应对整盘丢失。不同位置的副本、合理的版本保留和受限的访问权限，分别解决不同问题。\n备份记录里值得保留四项信息：备份时间、覆盖范围、恢复步骤和最近一次演练结果。真正出问题时，最需要的是可以照着执行的路径。\n","permalink":"https://www.dopzn.cn/posts/backup-restore/","summary":"\u003cp\u003e看到备份任务显示成功，很容易松一口气。但“归档文件生成了”和“以后能够恢复服务”之间，还有不少细节。\u003c/p\u003e\n\u003ch2 id=\"先列出恢复需要什么\"\u003e先列出恢复需要什么\u003c/h2\u003e\n\u003cp\u003e对于静态博客，文章源文件、主题版本、自定义模板和配置通常比生成后的 HTML 更重要。对于数据库应用，还需要考虑数据库的一致性快照、上传文件和必要的密钥。\u003c/p\u003e","title":"备份是否可靠，要从一次恢复开始判断"},{"content":"把一段命令复制到笔记里，并不意味着以后就会使用它。几周后再打开，最常见的疑问往往是：这条命令在哪台机器执行？它改了什么？当时为什么需要它？\n用问题作为标题 “Nginx 笔记”很难在一堆文档里被准确找出来。“Nginx 配置改完后如何验证并重载”就具体得多。标题里放入未来会搜索的关键词，通常比追求漂亮的分类更有用。\n环境只记关键差异 操作系统、软件版本、运行方式和相关路径，往往足以解释大部分差异。无需把整个环境信息全部贴上来，但会改变命令含义的条件应该说明。\n例如同样是启动服务，Docker Compose 和 systemd 的命令不同；同样是文件权限，容器内的用户 ID 和宿主机的用户名也可能不同。\n命令旁边写预期结果 一份简短模板可以这样组织：\n# 要解决的问题 ## 环境与前提 ## 操作步骤 ## 预期结果与验证 ## 回退方法 ## 参考资料 验证结果最好具体到状态码、输出字段或可见行为。“看起来正常”很难复查，“首页返回 200，缺失路径返回 404”就清楚得多。\n失败步骤也有价值 没有必要保留所有试错日志，但值得记下关键误区：为什么某种方法不适用，哪一个证据推翻了原来的判断。以后遇到相同症状时，这些信息能减少重复尝试。\n最后，发布前再检查一次敏感信息。真实密码、令牌和内部地址可以替换为明确的示例值；保留解释问题所需的结构就够了。\n","permalink":"https://www.dopzn.cn/posts/markdown-notes/","summary":"\u003cp\u003e把一段命令复制到笔记里，并不意味着以后就会使用它。几周后再打开，最常见的疑问往往是：这条命令在哪台机器执行？它改了什么？当时为什么需要它？\u003c/p\u003e\n\u003ch2 id=\"用问题作为标题\"\u003e用问题作为标题\u003c/h2\u003e\n\u003cp\u003e“Nginx 笔记”很难在一堆文档里被准确找出来。“Nginx 配置改完后如何验证并重载”就具体得多。标题里放入未来会搜索的关键词，通常比追求漂亮的分类更有用。\u003c/p\u003e","title":"一篇以后还能看懂的技术笔记，应该留下什么"},{"content":"一个个人博客的核心事情很简单：写文章，让读者找到并读完。如果暂时不需要账号、评论和复杂后台，静态站点是值得考虑的方式。\n内容先生成，再提供访问 Hugo 这类工具会把 Markdown 文章、模板和配置转换成 HTML、CSS 与 JavaScript。服务器面对访客时，只需要返回已经生成的文件，不必为每一次阅读查询数据库。\n这个站点使用 Hugo 和 PaperMod 主题。文章、导航和样式都保存在源文件中，修改后重新构建，再发布生成结果。\n优点来自少一些运行中的东西 不运行数据库，也不开放写入后台，意味着需要维护的服务更少。生成文件可以提前检查，发布时也比较容易保留旧版本。\n不过静态站点并不是不用维护。Web 服务器、HTTPS 证书、构建工具和主题仍需要更新，域名续费和备份也仍然重要。\n搜索不一定需要后端 文章数量不多时，可以在构建阶段生成搜索索引，让浏览器完成匹配。这种搜索不会把关键词发给第三方搜索服务，也不需要额外启动搜索数据库。\n代价是索引会下载到访客浏览器。内容规模很大时，需要重新评估加载大小和搜索效果，不能把小站的方案直接套用到大型文档库。\n写作流程需要适应 静态博客通常先编辑 Markdown，再预览、构建和发布。它不像在线编辑器那样点一下就保存，但版本管理可以记录每次修改，也方便比较和回退。\n如果未来需要多人协作、会员权限或复杂交互，再考虑增加相应系统。先让阅读体验和内容稳定下来，是这个小站当前的选择。\n参考：Hugo · PaperMod\n","permalink":"https://www.dopzn.cn/posts/static-blog/","summary":"\u003cp\u003e一个个人博客的核心事情很简单：写文章，让读者找到并读完。如果暂时不需要账号、评论和复杂后台，静态站点是值得考虑的方式。\u003c/p\u003e\n\u003ch2 id=\"内容先生成再提供访问\"\u003e内容先生成，再提供访问\u003c/h2\u003e\n\u003cp\u003eHugo 这类工具会把 Markdown 文章、模板和配置转换成 HTML、CSS 与 JavaScript。服务器面对访客时，只需要返回已经生成的文件，不必为每一次阅读查询数据库。\u003c/p\u003e","title":"只写文章的博客，为什么选择静态站点"},{"content":"这里是 Dopzn 的代码学习随记，一个整理学习笔记、工具用法与技术思路的个人博客。\n写一段代码只是起点。为什么这样写、哪里容易出错、怎样确认它真的工作了，这些过程同样值得留下。这里的文章尽量从具体问题开始，用小例子把思路讲清楚。\n会记录什么 代码与开发：命令行、版本管理，以及容易忘记的小细节。 Linux 与网络：从进程、日志到域名和 HTTPS，一点点串起服务运行的过程。 学习与整理：让笔记能够被检索、复用和修订。 阅读说明 本站于 2026 年 10 月上线，首批文章是建站时集中整理的技术笔记，发布日期以页面标注为准。部分内容由 AI 协助起草和整理；命令示例适用于文中说明的场景，具体使用前仍需结合自己的环境确认。\n网站仅提供文章阅读与站内搜索，不开放评论、账号注册或内容投稿。文章会随着理解加深持续修订。\n版权与引用 引用时请注明文章标题及本站链接。外部资料以原作者许可为准，文中的命令、地址和文件名示例不包含真实账号凭据。\n","permalink":"https://www.dopzn.cn/about/","summary":"\u003cp\u003e这里是 \u003cstrong\u003eDopzn 的代码学习随记\u003c/strong\u003e，一个整理学习笔记、工具用法与技术思路的个人博客。\u003c/p\u003e\n\u003cp\u003e写一段代码只是起点。为什么这样写、哪里容易出错、怎样确认它真的工作了，这些过程同样值得留下。这里的文章尽量从具体问题开始，用小例子把思路讲清楚。\u003c/p\u003e","title":"关于这本随记"}]