网站迁移实战：从HTTP到301重定向，避坑指南

把博客置顶公告改成暂停更新请到http://www.52brt.com上关注最新文章的那天后台私信一下子热闹起来。有人问是不是不写了有人问新站是不是要收费还有人一脸懵地问我这个http链接复制到浏览器怎么还是打不开——其实都不是。这就是一次很普通的站点迁移旧的博客我决定停掉内容搬到新域名继续更新公告里那个链接就是新家的地址。写这篇文章就是想把这个过程完整拆开讲一遍为什么要暂停、网站迁移背后涉及哪些HTTP相关的原理、旧链接怎么处理、新站上线过程中最容易踩哪些坑。无论你是打算给自己的博客搬家还是工作中要接手一次网站迁移这篇文章里的方案和排查思路都能直接参考。1. 先别急着搬想清楚暂停更新这四个字的份量1.1 这次暂停的真正原因老实说我没有卖关子的必要。这次暂停更新最直接的原因是旧的博客系统用了很多年底层框架已经跑不动了。文章多了以后后台发布越来越慢主题插件互相冲突好几次差点把数据库搞坏。与其在旧系统上缝缝补补不如趁内容还没有彻底乱掉之前整体搬到一套新的方案上。很多个人站点都是这么走过来的。早期随便搭一个博客那时候访问量小什么都将就等文章积累到几百篇图片几千张搜索引擎收录了几万条URL之后问题就一件一件冒出来了。最典型的是这三类第一后台编辑卡顿保存一篇文章要等好几秒甚至直接超时第二数据库表结构老旧想加一个功能要改一大堆代码第三HTTPS证书、CDN这些基础服务在旧架构里接起来很别扭。所以暂停更新不是一个随手的决定背后是旧站维护成本已经高于产出价值的判断。你去看很多技术站点隔几年就会有一次大规模重构暂停更新只是重构期对外的一个信号。读者不需要知道你到底换了什么框架但你得让他们知道接下来去哪里找你。1.2 新站上线前我做的三件事我给自己列了一个清单三件事顺序不能反。第一件是全量备份。旧站的数据库导出SQL所有附件、图片、主题文件打包下载包括多年没用的旧版本备份也留了一份。我习惯备份文件命名带上日期比如backup-20250112-全站.tar.gz这样回滚的时候知道哪份是最新的。第二件事是把文章的URL规则提前定好。这里必须提醒一句URL结构尽量保持和旧站一致。搜索引擎、外站转载、你自己在文章里引用的老链接全都依赖这些URL。你改了URL规则等于让所有老链接失效权重和流量一夜清零。第三件事是测试新站的访问链路。新域名解析是否正常、HTTPS证书是否部署、页面在手机和PC上是否都能打开这些在新站正式对外之前先通过预览环境跑一遍。不要等到公告发出去读者点进链接看到502那是最尴尬的开场。这三件事做完才有底气把暂停更新请到新地址这句话发出去。2. 换网址这件事绕不开的HTTP基础2.1 URL是怎么找到一台服务器的公告里的http://www.52brt.com看起来就是一个地址但它在网络上实际经历的是一整套寻址过程。你把URL输入浏览器第一步是DNS解析也就是把www.52brt.com这个域名翻译成服务器的IP地址。翻译完成后浏览器再通过HTTP协议向那个IP地址发起请求。HTTP协议本身做的事情很纯粹客户端发一个请求报文服务器回一个响应报文。请求报文里有请求行、请求头、请求体三部分。请求行规定了方法、路径和协议版本比如GET /index.html HTTP/1.1意思就是从根路径取首页使用HTTP/1.1版本。响应报文则包含状态行、响应头和响应体状态行里就是大家熟悉的200、301、404、502这些状态码。整个过程就是一次问与答。很多读者会困惑为什么我在公告里放的是http而不是https。这里得说明白从HTTP升级到HTTPS多了一层TLS加密握手数据在传输过程中不会被中间节点直接看到内容。如果你打开某些浏览器会发现带http的地址栏里直接提示不安全。所以新站上线后我第一时间配置了TLS证书把HTTP访问全部重定向到HTTPS。这里也建议所有维护网站的朋友新站点一律直接上HTTPS别再用纯HTTP一方面是安全另一方面搜索引擎对HTTPS站点也有偏好。2.2 HTTP和HTTPS的区别以及和TCP的关系从HTTP到HTTPS直观上的差别就是多了个S实际上多的是TLS层。HTTP是明文传输HTTPS在HTTP和TCP之间插入一层TLS负责加密、完整性校验和身份认证。身份认证这块容易被忽略证书由CA机构签发浏览器通过证书链验证服务器身份防止你访问到一个伪装成目标域名的恶意服务器。再往深一层说HTTP是应用层协议TCP是传输层协议。HTTP负责定义数据长什么样、该用什么格式沟通TCP负责保证这些数据完整可靠地到达对面。可以这么理解HTTP是信封上写的地址和内容格式TCP是负责把信送到目的地的邮差。如果TCP不可靠HTTP报文就会丢如果HTTP格式不对TCP就算把数据完整送到了服务器也没法正确响应。这个区分在实际排错时非常有用。比如你遇到请求超时第一步要想的是TCP层有没有通也就是服务器IP和端口能不能连通这可以用telnet或者curl -v来测如果TCP通但拿不到正确页面问题才回到HTTP层。2.3 HTTP连接复用一个新站必须关注的性能点新站上线后我认真调过的一项配置是HTTP连接复用也就是Keep-Alive。HTTP/1.1默认开启这个机制同一个TCP连接上可以连续发送多个HTTP请求不需要每个请求都重新握手。如果不使用连接复用一个页面如果引了30张图片浏览器就得多建立30次TCP连接而每次建立连接都伴随三次握手耗时翻好几倍。我把连接超时时间设置成了合理的区间一般Nginx里keepalive_timeout设60秒左右同时开启gzip压缩减少传输体积。这一顿操作下来新站的页面加载速度明显比旧站快。别小看这些细节读者从旧链接跳转到新站第一感知就是打开快不快体验差的话人留不住。3. 迁移实操从旧站到新域名怎么做到无缝衔接3.1 数据迁移与内容搬运的完整流程这里说的数据主要是三类数据库、附件文件、配置。数据库迁移我用的方法是导出SQL文件再导入。小站可以直接用phpMyAdmin之类的工具导出站点大到一定程度就改用命令行工具来做避免网页执行超时。导入之前先在新库建好空白库字符集一定要和旧库一致常见的是utf8mb4不一致会出现乱码。附件文件包括图片、压缩包、文档这些直接用rsync同步最稳妥。rsync同步时加上-a参数保留权限和时间戳加上-v看传输列表最后核对文件数量是不是对得上。config文件不能直接复制新旧环境参数往往不同例如数据库地址、缓存配置、上传大小限制凡是涉及环境的配置都要重新填一遍。3.2 301重定向让老链接自己带路内容搬完只是第一步更重要的是让访问旧链接的人自动跳到新站。我做了全站301重定向规则很简单旧域名下所有请求统一返回301状态码Location指向新域名下对应的URL。比如请求http://old.example.com/post/123就跳转到http://www.52brt.com/post/123。做301而不是302这一点必须说清楚。301是永久重定向搜索引擎会把旧页面的权重转移到新地址302是临时重定向搜索引擎认为这只是暂时跳转权重不转移。你做的是站点迁移是永久性的所以一定要用301。假设用的Nginx配置大概长这样server { listen 80; server_name old.example.com; return 301 https://www.52brt.com$request_uri; }$request_uri会把原始请求路径原样带到新站这样深链接也能一一对应。配完之后要立刻测试用curl -I看一下返回的状态码是不是301Location对不对。3.3 切换DNS时的生效等待与验证301配置好之后最后一步才是把DNS切过去。我用的域名DNS服务商支持直接修改解析记录把www和根域名都指向新服务器IP。这里要提醒一个常识DNS修改之后不会立刻全局生效它受TTL影响各地DNS服务器缓存刷新有快有慢短则几分钟长则48小时。为了减少切换等待我在切换前就把旧记录的TTL调低比如从默认的3600秒先降到300秒等缓存刷新后再修改解析。这个技巧做迁移的人都该知道先降TTL再改记录能明显缩短生效时间。切换后我在几个不同的网络环境里分别验证包括手机4G网络、公司网络、家里宽带再用在线DNS检测工具查各地解析结果。确认新IP已经稳定生效再放心地发出请到新地址关注的公告。4. 迁移路上常见的HTTP报错我都替你踩过4.1 502 Bad Gateway新站上线当天最怕见到的数字迁移过程中我最常遇到的就是502。有一次搭反向代理上游服务还没起来结果访问页面直接报502 Bad Gateway。这个报错的意思很直接网关或者代理服务器收到了无效的响应。排查502有一个固定套路。先看后端服务有没有启动进程是否存活端口是否在监听再看反向代理配置里的upstream地址和端口是否写对最后看日志Nginx的error.log里会记录具体的上游连接失败原因。多数时候问题就出在后端服务的启动方式上比如我用systemd管理服务忘记设置Restartalways进程挂了没人拉起来代理拿不到响应自然就是502。处理完这一轮我把服务的健康检查也加上了每30秒探测一次异常自动重启后面再没在访问高峰期收到过502的报告。4.2 403 Forbidden和404权限与路径问题403这个状态码遇到的时候也恼火它表示服务器理解你的请求但拒绝执行。最常见的原因是文件权限不对。有一次我同步附件时rsync同步过去的文件权限变成了600Web服务器的工作进程没有读权限访问图片直接403。解决思路就一条确认Web服务运行用户对站点目录有读权限。我习惯把站点目录属主改成Web服务运行用户目录权限755文件权限644这样既不开放不必要的写权限又能保证正常读取。404就更好定位了通常是迁移后路径变了。所以在迁移前我特意保持URL结构一致就是为了减少这类问题。如果确实发生了404优先检查是不是伪静态规则没配好很多博客系统的URL是靠伪静态规则重写的。4.3 请求超时与连接失败别只盯服务器还有一种情况页面一直转圈然后报连接超时。遇到这种问题先别急着怀疑服务器挂了网络链路也可能是瓶颈。我按这个顺序排查先ping服务器IP看网络通不通再telnet测端口通不通接着curl -v看完整请求过程确认握手、请求、响应各阶段耗时。这样一步步下来基本就能定位是网络延迟、防火墙拦截还是应用处理慢。迁移过程中我还遇到过数据库连接失败导致的500错误这个排查靠看应用日志最方便。应用日志里会直接写出连接数据库超时或者密码错误比你在浏览器里猜一百遍管用。建议上线前就把日志级别调好把访问日志和错误日志分开存放迁完站有问题可以直接翻日志说话。5. 一点个人经验写给同样在折腾网站的人5.1 迁移窗口与公告措辞说回最初那个公告暂停更新请到http://www.52brt.com上关注最新文章。现在回看这句话其实挺克制的。我个人的建议是迁移公告里至少要说清三件事旧站为什么停、新站的地址是什么、新站什么时候开始正常更新。如果连什么时候恢复更新都说不出来读者会觉得你是消失了而不是搬家了。预热也很重要。我在暂停前两周就开始在文章顶部放新站预告让老读者有心理准备。真正宣布暂停的那天再把新站地址加粗单独发一篇说明。正式公告发出后我在旧站首页放了一个醒目的横幅点击任何页面都会先看到新站入口。5.2 内容沉淀比形式折腾更重要折腾完这轮迁移我最大的感受是网站的外壳会过时但内容不会。几百篇文章、几千条评论、这些年积累下来的阅读数据才是站点真正有价值的资产。迁移过程中所有的技术决定都是为了把这些资产平稳地搬到新家。所以如果你也要做站点迁移我的经验是先盘点内容资产再谈技术方案。内容分类、标签体系、历史评论要不要保留、旧文章的失效外链怎么处理这些问题在动手之前就要有答案。技术上的坑我这篇文章基本都列了但内容层面的取舍只有你自己最清楚。5.3 几个容易被忽略的细节最后再分享几个容易被忽略的细节。第一迁完站之后记得把旧站服务器保留一段时间别急着销毁至少保留一两个月给搜索引擎重新抓取和读者习惯性访问留出缓冲。第二旧站的robots.txt要改别让搜索引擎继续抓取旧域名页面。第三评论功能如果接了第三方服务迁移后要去后台把域名白名单改掉否则新站评论会加载不出来。还有一个我自己踩过的坑迁移当天一定要选在流量低的时间段别选在工作日白天大流量时段。哪怕你有完整的备份操作过程中出现了意外流量低的时候试错成本也低。我这次是挑了一个周日凌晨操作的整个迁移过程不到两个小时天亮之前新站就已经正常对外服务了。这些经验都是真金白银踩出来的。如果你正准备给自己的网站或者博客搬家建议把这篇存下来迁移的时候对照着做能少走不少弯路。新站那边我们继续见。