短链接还原方法：日志追踪原始地址

短链接本质上无法被“解码”还原，所谓还原仅在自建系统且严格保留原始URL映射关系（通过结构化日志或数据库持久化存储）的前提下才可行；依赖HTTP重定向、cURL或file_get_contents不仅极易被反爬、限流和协议拦截击穿，还完全失效于微信私有短链、带签名Token的临时链接等场景——真正可靠的方式是早在跳转前就将short_code与original_url精准写入可审计的日志或数据库，并通过索引优化的精确查询实现毫秒级还原，否则一旦映射未留存，任何技术手段都束手无策。

短链接本身不自带还原能力，PHP 无法直接“解码”任意第三方短链（如 t.cn、bit.ly），所谓“还原”只在你自建短链系统且保留原始 URL 映射关系的前提下才可行。核心不是调用某个函数，而是查数据库或日志。

为什么 file_get_contents() 或 cURL 不能可靠还原短链？

HTTP 重定向（301/302）返回的是最终跳转目标，但很多短链服务做了反爬或限流：返回 403、429、空白页，甚至故意返回首页或错误页。更关键的是，部分短链（如微信内 weixin:// 协议、企业微信私有短链）根本不会在服务端暴露真实地址，只在客户端 SDK 解析。

• 依赖重定向会漏掉协议级拦截（如 UA 检查、Referer 校验）
• 高频请求触发风控，返回非真实跳转地址
• 无法处理带参数签名、时效性 Token 的短链（如阿里云 OSS 临时链接）

自建短链系统中，如何从日志还原原始 URL？

前提是你的短链跳转逻辑写入了访问日志（推荐结构化日志），而不是只记录 Apache/Nginx 默认 access_log。关键字段必须包含：short_code、original_url、timestamp、ip（可选）。

例如使用 PHP 写入 JSON 日志：

file_put_contents('/var/log/shortlink/access.log', json_encode([
    'short_code' => $_GET['s'] ?? '',
    'original_url' => $db->fetchOriginalUrl($_GET['s']),
    'timestamp' => date('c'),
    'ip' => $_SERVER['REMOTE_ADDR']
]) . "\n", FILE_APPEND);

• 不要依赖 Nginx 日志里的 $request_uri —— 它不含重写后的真实映射
• 日志需在 header("Location: ...") 之前写入，避免因跳转中断导致丢失
• 若用 Redis 缓存映射，记得同步写日志，否则缓存过期后无法追溯

从数据库直接查原始 URL（最可靠方式）

只要短码生成时存了映射，还原就是一次简单查询。重点是表结构设计和索引：

CREATE TABLE `short_urls` (
  `id` BIGINT UNSIGNED PRIMARY KEY AUTO_INCREMENT,
  `short_code` VARCHAR(8) NOT NULL,
  `original_url` TEXT NOT NULL,
  `created_at` TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
  `hits` INT DEFAULT 0,
  INDEX `idx_short_code` (`short_code`)
);

• 查询语句必须用 WHERE short_code = ?，别用 LIKE 或模糊匹配
• 如果支持大小写混合（如 aB3x），字段定义要加 COLLATE utf8mb4_bin
• 高并发场景下，UPDATE hits 和 SELECT original_url 建议合并为原子操作（如 MySQL 的 INSERT ... ON DUPLICATE KEY UPDATE）

真正难的不是“怎么查”，而是日志或数据库里压根没存原始 URL —— 比如用了纯算法生成（Base62 编码 ID）、没持久化映射、或把原始链接存在外部不可审计的存储里。这种情况下，没有回溯路径，任何 PHP 函数都无能为力。

今天关于《短链接还原方法：日志追踪原始地址》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！