短链接还原php后链接失效_确认原链接是否已过期【操作】

短链接还原后跳转404或空白，主因是目标URL失效而非短链服务问题；需检查原链接有效性、签名时效、服务器重写规则、数据库映射一致性及HTTPS迁移适配。

短链接还原后跳转 404 或空白，先查原链接是否还有效

短链接本身只是个指向，还原后失效，大概率不是短链服务的问题，而是目标链接（原 URL）已下线、重定向被移除、或资源被删除。PHP 端做还原时如果只解码或查表，不验证目标地址状态，就会直接返回一个早已失效的 Location 响应。

实操建议：

• 用 curl -I 或浏览器开发者工具 Network 面板，手动请求还原出的完整原链接，看 HTTP 状态码是不是 404、410、301（但新目标也失效）、或 200 但页面内容为空
• 如果原链接含时间戳、签名参数（如 ?t=1712345678&sig=abc），检查签名是否过期、时间窗口是否超限（常见于 PHP 的 hash_hmac() + time() 校验逻辑）
• 确认 Web 服务器（Nginx/Apache）没因路径重写规则误拦截，比如把带 .php 后缀的原始路径当成脚本执行，而实际该文件已被删

PHP 还原逻辑里没做 HEAD 请求预检，导致返回了死链

很多短链系统在还原时直接 header("Location: $long_url") 跳转，完全跳过对目标地址可用性的校验。这不是“还原失败”，而是“还原成功但目标已死”。

安全且实用的做法是：在跳转前用 get_headers() 或 cURL 发起轻量 HEAD 请求，仅检查响应状态：

立即学习“PHP免费学习笔记（深入）”；

function is_url_alive($url) {
    $ch = curl_init($url);
    curl_setopt($ch, CURLOPT_NOBODY, true);
    curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
    curl_setopt($ch, CURLOPT_FOLLOWLOCATION, false); // 不跟随跳转，避免误判
    curl_setopt($ch, CURLOPT_TIMEOUT, 3);
    $result = curl_exec($ch);
    $httpCode = curl_getinfo($ch, CURLINFO_HTTP_CODE);
    curl_close($ch);
    return in_array($httpCode, [200, 301, 302, 307]);
}

$long_url = get_long_url_from_db($short_code); // 从数据库查出原始链接
if (!$long_url || !is_url_alive($long_url)) {
    http_response_code(410);
    echo "Gone: original link no longer available";
    exit;
}
header("Location: $long_url");
exit;

注意：get_headers() 在部分主机上被禁用，cURL 更可靠；同时别忘了设置超时和关闭 CURLOPT_FOLLOWLOCATION，否则可能把 302 跳转后的最终地址状态误当作原链状态。

数据库里存的原链接被手动修改或未更新，导致还原结果错乱

短链还原依赖数据库中 short_code → long_url 的映射。如果运营侧曾手动 UPDATE 过 long_url 字段，但没同步更新签名、过期时间等关联字段，或者旧记录没软删除而是直接覆盖，就容易出现“能还原、但点不开”的情况。

排查重点：

• 查数据库该 short_code 对应的记录，确认 long_url 字段值是否与预期一致（尤其注意 URL 编码问题，比如空格变成 %20，中文是否被 double-encoded）
• 检查是否有 expires_at 或 is_active 字段，PHP 查询时是否加了 WHERE is_active = 1 AND expires_at > NOW()
• 如果用了缓存（Redis/Memcached），确认缓存键是否及时失效——例如更新数据库后忘了 del cache:short:abc123

HTTPS 协议升级或域名迁移后，原链接未做适配重定向

常见场景：站点从 http://old.com 迁移到 https://new.com，但短链系统仍保存着旧协议+旧域名的 long_url。PHP 还原时照搬输出，浏览器因混合内容或 HSTS 策略拒绝加载，表现为白屏或控制台报 Mixed Content 错误。

应对方式：

• 还原前做一次协议/域名标准化替换，例如用 str_replace("http://old.com", "https://new.com", $long_url)（仅适用于简单迁移）
• 更稳妥的是在短链生成阶段就统一用相对协议或新域名，或在数据库层加视图/触发器自动修正
• 检查服务器全局重定向规则，确保 http://old.com/path 会 301 跳到新地址；否则即使 PHP 返回了旧链接，用户点击后也会卡在中间跳转环节

真正难定位的，往往是原链接看似正常（curl -I 返回 200），但页面内嵌资源（JS/CSS/图片）路径写死在旧域名下，导致渲染失败——这时候得看浏览器 Network 面板里的具体失败请求，而不是只盯着主 URL。