网站被劫持后，最先要做的不是马上改密码或重装系统，而是先确认劫持发生在哪一层：是域名解析被改，是 CDN 回源指向了别处，是服务器上的配置被加入跳转规则，是页面源码被插入脚本，还是只有某个网络环境或某台设备访问异常。这四种情况要处理的位置完全不同；处理位置搞错，清理完文件后往往还会复发。可以先做两件不改变现状的取证动作：在不同网络环境下分别解析域名，并对比“直连源站 IP 返回的内容”和“走域名返回的内容”。如果两边不一致，问题多半在解析或 CDN 层；如果两边一致，但源码里多出陌生 script、iframe 或跳转逻辑，就应往后端和站点目录检查。
判断顺序建议是：先比对域名解析与源站直连结果，确认劫持发生在解析层、传输层还是应用层；再对现状做快照（保留配置、日志和可疑文件），然后切断入口、清理注入点，最后从多个网络环境复核。需要留意边界：如果异常只在用户本地或运营商侧出现，服务端怎么清理都不会消失；如果服务器已被拿到高权限，单靠删除几个文件不足以恢复，应考虑迁移到干净机器并轮换全部凭据。
先厘清问题真正指向
搜索“网站被劫持怎么办恢复正常”的人，遇到的往往是几种具体现象：从搜索结果点进来后被跳到无关站点；手机访问正常，电脑访问异常，或者反过来；页面能打开，但源码里多出陌生外链和统计脚本；浏览器提示证书与域名不匹配；输入域名后跳到一个仿冒的登录页。这些现象对应的位置并不相同，恢复动作也不一样。
读者要完成的动作可以概括为一条链路的复位：让“域名解析 → 源站或 CDN 回源 → 正确的站点配置 → 正确的页面内容”这条路径重新对上。可以先按三个问题划分范围：解析结果是否被改过、服务器上返回的内容是否被改过、只有特定访问者看到异常。把这三问回答清楚，再决定先动 DNS、先查 CDN，还是直接进服务器。
从关键条件开始处理
动手前建议先做一次静态快照，目的是留证据、方便对比，而不是修复。可导出当前 nginx 或 Apache 配置、站点目录文件清单、近期被修改的文件、计划任务和系统账号列表。之后按下述条件逐项判断：
- 解析是否一致：用多个公共 DNS 分别查询 A 记录和 CNAME，与自己在域名服务商后台配置的记录对比。记录值被改成陌生 IP，或 CNAME 指向不认识的域名，说明问题在解析层。
- 源站是否干净：在服务器本机用带 Host 头的请求直接访问回环地址，绕开 CDN 和外部解析。若本机返回正常、走域名异常，问题更可能在 CDN 缓存或回源配置。
- 配置是否被插改：检查站点配置里的 rewrite、return 30x、proxy_pass 等指令，以及
.htaccess、伪静态规则；被劫持时常见手法是加入按 User-Agent 或 Referer 判断的条件跳转，正常访问看不出来。 - 文件是否被改：按修改时间筛选站点目录，重点看首页、公共头部文件、JS 文件和上传目录中的可执行文件。
- 是否存在持久化入口：检查 crontab、/etc/cron.d、systemd 自定义服务、Web 服务进程的启动参数，以及是否多出陌生系统账号。
操作顺序上，建议先切断入口再清理：暂停解析或下线入口、封存可疑文件副本、轮换数据库和后台密码，然后再删除注入内容。反过来先删文件，容易丢掉判断依据，也容易漏掉定时任务这类会再次写回文件的入口。
给出一个可执行的示例
下面是一组通用检查骨架，域名、路径和 Web 服务名需要按自己环境替换，命令在服务器上执行，只读取、不修改内容。
# 1. 对比不同解析来源的记录
dig +short www.example.com A @8.8.8.8
dig +short www.example.com A @1.1.1.1
dig +short www.example.com CNAME @8.8.8.8
# 2. 对比源站直连与走域名的返回
curl -sI http://127.0.0.1 -H 'Host: www.example.com'
curl -sI https://www.example.com/
curl -s https://www.example.com/ | grep -nE "<script|<iframe|window.location" | head -20
# 3. 查看配置中是否被插入跳转或回源改动
nginx -T 2>/dev/null | grep -nE "rewrite|return 30[12]|proxy_pass"
# 4. 找近期被修改的文件
find /var/www/site -type f -mtime -7 -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort | tail -30
# 5. 查看持久化入口
crontab -l
ls -la /etc/cron.d /etc/cron.daily执行完可以整理成一张对照清单：解析记录是否与后台一致、源站直连返回是否与域名访问一致、配置中是否出现非本人添加的跳转、近七天内是否有非预期修改的站点文件、计划任务中是否有陌生条目。任何一项答案为“是”，就先处理该项，再复查其他项，因为多处被改的情况并不少见。
验证结果并看清边界
清理后建议从多个角度复核：换一到两个不同网络或使用移动数据访问；用无痕窗口避开本地缓存；再跑一次解析对比和源站直连对比；对比首页源码与版本库或备份文件；查看 Web 访问日志中是否还有异常跳转和陌生来源的请求。若使用 CDN，需要刷新缓存后再验证，否则可能看到的是旧缓存，误判为未修复。
需要看清的限制条件有几点。第一，如果异常只在某一台设备或某个网络出现，问题可能出在本地路由器 DNS、设备上的恶意插件或被劫持的本地 hosts，服务端清理不会有任何变化。第二，如果清理后发现入侵者已获得系统高权限、或无法确认修改范围，比较稳妥的做法是保留数据、迁移到干净服务器并轮换所有凭据，而不是在原机上反复删文件。第三，页面注入往往通过后台弱口令或上传漏洞进入，清理内容的同时需要修补对应入口，否则同一路径可能再次被利用。第四，不同站点架构差异较大，上述命令只提供判断思路，具体路径、服务名和缓存机制需要结合自己的环境确认后再执行。