同IP网站改动前怎样保存原始状态：先留证据再动配置
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /48e21fba4c76.html
📄
同IP网站改动前怎样保存原始状态：先留证据再动配置
改动同IP网站之前，保存原始状态的核心是留下可回退、可对比、可验收的证据。至少应包括：当前页面与配置的完整快照、服务器与站点配置文件副本、数据库备份、DNS与解析记录、以及改动前后的检查清单。只截图首页不算保存原始状态，因为同IP网站的问题往往出在某个目录、某条规则或某台虚拟主机上。
先明确“原始状态”包含哪些层
同IP网站指多个站点共用同一个IP地址，通过不同域名、端口或虚拟主机配置区分。改动前要保存的不只是网页内容，还包括让这些站点能正常区分和访问的全部条件。可以按下面几层分别留证。
- 内容层：各域名首页、关键栏目页、404页面的完整HTML快照，最好用浏览器“另存为”或抓取工具保存，而不是只截可见区域。
- 配置层：Web服务器（如Nginx、Apache）的站点配置文件、虚拟主机配置、重定向规则、伪静态规则。复制整份配置目录，而不是只复制当前正在改的那一个文件。
- 数据层：数据库导出文件，记录导出时间、库名和字符集。如果站点有上传目录，也要记录其路径和大致文件数量。
- 解析层：同一IP对应的所有域名清单、各自的DNS解析记录、是否启用CDN或代理。这一层最容易被忽略，但同IP网站出问题时经常是解析指向被改乱。
假设例子：三个站点共用一台服务器
假设某台服务器IP上绑定了 a.example、b.example、c.example 三个站点，现在要调整其中一个站点的伪静态规则。以下是改动前可以实际执行的步骤。
- 在服务器上执行
nginx -T（Nginx）或apachectl -S（Apache），把完整配置输出重定向保存为文本文件，文件名带上日期。 - 用
curl -I分别请求三个域名的首页，保存返回的状态码、跳转目标和响应头。这一步记录的是改动前的真实访问结果，不是配置文件里的意图。 - 导出数据库，并记录导出命令和文件大小。如果站点没有数据库，则记录静态文件目录的清单。
- 把要修改的配置文件单独再复制一份，命名中标注“改动前”。不要只在原文件里加注释，因为注释可能被后续覆盖。
- 写下本次改动的范围和预期结果，例如“只改 b.example 的伪静态，a 和 c 不应受影响”。
常见错误有三种：只备份了要改的文件，结果回退时发现其他文件也被连带修改；只保存了配置，没有保存改动前的访问结果，导致无法判断问题是不是改动引入的；把备份放在同一块磁盘的同一目录，磁盘或目录出问题时备份一起丢失。
怎样判断保存得够不够
可以用一个简单标准检验：如果现在把改动全部撤销，能否只靠保存下来的材料恢复到改动前的状态，并且能证明恢复成功。检查项包括：
- 配置文件能否直接覆盖回原位置并正常启动服务。
- 数据库备份能否导入，导入后关键页面是否与保存的HTML快照一致。
- 改动前保存的
curl -I结果，能否在恢复后逐条对上状态码和跳转目标。 - 同一IP上的其他域名，恢复后是否仍然正常，没有被误伤。
如果其中任何一项做不到，说明原始状态保存不完整，应先补齐再改动。适用条件是：只要改动涉及共用同一IP的多个站点，就应按上述范围保存；如果只改单个站点的纯文字内容且不涉及配置和解析，可以适当缩减，但页面快照仍建议保留。
交接或验收时怎么用这份记录
准备交接或验收时，把改动前保存的材料整理成一份对照表：左边是改动前的状态，右边是改动后的状态，中间写清每项的判断依据。验收时逐项核对，而不是只看首页能否打开。需要注意，robots.txt 的抓取限制不等于可靠的索引移除，站点地图也不保证收录；如果改动涉及这些文件，保存原始状态时应同时记录改动前搜索引擎实际抓取到的内容，而不是只记录文件本身。
下一步：在真正改动之前，先按上面的清单完整执行一遍保存，并把保存文件放到服务器之外的位置，然后再开始修改配置。
