少写一个 else，我的外链跳转页成了黑产眼中的“香饽饽”？重构一个安全的外链跳转页（附 PHP 源码）
“CV工程师”的小白迷之自信
时光倒流回好几年前，那时我的 PHP 和 JS 水平还停留在相当小白的阶段（虽然现在也还是业余），用现在流行的话说，就是一名标准的 “CV 程序员”（Ctrl+C / Ctrl+V）。
当时看到一些 SEO 教程说，不要直接引用外链，不然网站权重会丢失，不利于SEO优化云云，虽然那时候博客一个月的访问量加起来都没现在一天多，我还是决定搞一个外链跳转页，实现外链SEO优化。那时候的我，写代码基本靠搜。我当时在网上东拼西凑，这里复制一段 PHP 代码，那里又找来一段 JS 脚本，缝缝补补一通 Ctrl+C / Ctrl+V 算是把功能跑通了。
那时候的我觉得自己做得挺周全：
- 既有「关键词过滤」：在后端的 PHP 里加了正则，拦截类似
eval、base64这种敏感词，防止有人注入代码。 - 还有「来源页检查」：在前端的 JS 里写了判断，判断访问来源是不是我的博客域名，如果不是就跳回首页。
看着这套“组合拳”，我心想：“这下稳了，既防注入又防盗链，妥妥的。” 这一用，就是好几年。
我变成了黑产眼中的“香饽饽”:遭遇 Open Redirect 漏洞扫描
部署后的头几年，一切风平浪静，看起来跳转页在忠实的工作着。直到大前年开始，因为《本地部署AI文生图工具 SD-webui 生成NSFW图》部署教程被广泛引用，博客的流量和热度突然上去了。那小半年的时间里，每日新访客（仅仅是新访客就）能稳定在 4位数，高质量反链好几个。在 Google 和 Bing 眼中，我的博客权重逐渐变高。
于是乎，树大招风，我的外链跳转页被盯上了。
最开始的端倪，是 Google Search Console 发来的“提示”。网域出现了大量“未编入索引”的提示，我点进去一看，全是 /goto/?url=… 后面跟一长串乱七八糟的垃圾网站链接（赌博、色情、灰产，应有尽有）。
紧接着，防火墙（WAF）开始频繁报警。日志显示，有大量的请求携带着奇怪的参数试图经过我的跳转页做XSS或者SQL注入。这是典型的 Open Redirect（开放重定向）漏洞利用尝试。
佛系站长的机械抵抗
面对这些攻击，当时的我虽然觉得烦，但并没有意识到问题的严重性。毕竟博客前台看着没啥异常，服务器也没崩，搜索引擎也没收录这些奇奇怪怪的跳转。
于是，一向 “佛系” 的我采用了最机械的应对方式：
- WAF 堵截：我在防火墙里加了几条规则，只要 URL 参数里包含某些特征，就直接拦截。
- GSC 移除：对于 Google 收录的那些垃圾跳转链接，我直接使用 Google 的移除工具申请删除。
“反正也没造成什么实质性的破坏，能拦就拦，拦不住貌似也没啥。” 就这样，我拖着这个隐患，得过且过地又混了两年多。
形同虚设的“来源检查”：一段被覆盖的 JS 逻辑
直到最近，那种久违的“折腾之魂”突然死灰复燃。趁着手里有干劲，我决定把这个陈年老页面彻底重构一下。
当我打开那个尘封已久的 index.php，仔细审视当年的代码时，冷汗下来了。不看不知道，一看吓一跳——当年我所谓的“安全措施”，简直就是“千疮百孔”，甚至是在对黑灰产说着“欢迎光临”，代码幼稚的简直想穿回去抽自己的嘴巴子。
当年写下（复制来）的防止非本站使用跳转页的代码是这样的
{
//禁止其他网站使用我们的跳转页面
// 第一步：获取我们自己的域名
var MyHOST = new RegExp("<?php echo $_SERVER['HTTP_HOST']; ?>");
// 第二步：判断来源
if (!MyHOST.test(document.referrer)) {
// 第三步：如果来源不对，准备跳转回首页
location.href="https://" + MyHOST;
}
// 第四步：正常执行跳转
location.href="<?php echo $url;?>";
}
看出问题来没？我感觉稍微有点开发经验的朋友都看出来了，因为跳转逻辑被覆盖了！！
我当年知道 JavaScript 是按顺序向下执行的，所以我想当然的认为当代码执行了location.href="https://" + MyHOST;之后，非法访问就会被跳转到我的首页了，后面的location.href="<?php echo $url;?>";不会被执行。
但实际上，修改（赋值） location.href 后代码其实会继续执行下去的，实际执行时是下边这样的过程
- 一个非法的来源，进入 if 了。浏览器接到指令：“准备跳转回首页”。
- 毫秒级的时间内，代码会继续往下跑，执行到了下一行。浏览器接到新指令：“准备去目标外链”。
- 后一条指令覆盖了前一条指令,浏览器会听从最后一句代码的指挥。
- 结果：无论来源是否合法，浏览器都会乖乖跳转到 $url（目标网站）。
- 纯纯拦截了个寂寞
当年的我犯了初学者最常见的认知错觉，是把 JavaScript 的 location.href 当成了 PHP 里的 header('Location: ...');了，殊不知在浏览器眼里，这只是一次变量赋值。（PS：其实PHP里这样写也是错的，后面需要写exit;,不然可能用户浏览器已经跳走了，但服务器还在空跑）
浏览器是单线程执行 JS 的。当它读到我的第一次赋值时，它在心里记下：“哦，待会儿脚本跑完了我要去首页”。但是！脚本还没跑完呢，它必须继续往下跑。 紧接着它读到了第二次赋值：“哦，不对，他改主意了，待会儿脚本跑完了，让我去外链”。 后面的赋值覆盖了前面的赋值。
就像我告诉网约车司机‘去机场’，结果还没等司机踩油门，我又补了一句‘去火车站’。那司机肯定听最后一句啊！缺少一个 else，让我的防御代码变成了一句废话。
也就是说，这里正确的写法应该写成
var MyHOST = new RegExp("<?php echo $_SERVER['HTTP_HOST']; ?>");
if (!MyHOST.test(document.referrer)) {
location.href = "https://" + MyHOST;
} else {
location.href = "<?php echo $url;?>";
}
亦或者封装成一个函数用return打断函数继续执行也可以
var MyHOST = new RegExp("<?php echo $_SERVER['HTTP_HOST']; ?>");
function CheckHOST() {
if (!MyHOST.test(document.referrer)) {
location.href = "https://" + MyHOST;
return; // <--- 让函数立即停止
}
location.href = "<?php echo $url;?>";
}
顺带一提，这个错误的代码至今仍在谷歌搜索结果的前五位，而且被多个外链跳转页所使用。😂
拒绝漏洞：使用 PHP filter_var 重构安全跳转页
痛定思痛，我彻底抛弃了原来的代码，基于 PHP 服务端重写了整个逻辑。
为什么抛弃使用 JS 的检查逻辑
原因很简单，正确的 JS 代码当然可以在跳转被恶意利用时拉回用户，但这无法阻拦黑产的自动化漏洞扫描。
扫描漏洞用的爬虫、脚本（Python、Curl 、Go 等）根本就不执行 JS 的！它们只看 HTTP 响应头和 HTML 里的链接。 在扫描器眼里，我的旧代码压根没有那个 if 判断，他直接看到了最后的跳转链接。扫描器只会给我的各种路径去发?url=http://www.baidu.com之类的命令遍历尝试，看会不会触发跳转，只要触发跳转到百度的首页，就标记为“存在 Open Redirect 漏洞”，自动存入“可用资产库”。于是就会被拿来做跳转了，至于实际环境访问时能不能完成跳转，不讲究的黑产并不会去核实。只是因为有 JS 的存在，实际用户访问时会被拦截罢了。
从 JS 到 PHP：真正的来源检查
现在来源检查在服务器端完成，不依赖客户端。直接在 PHP 顶部加入了核心校验：
// 获取来源
$referer = isset($_SERVER['HTTP_REFERER']) ? $_SERVER['HTTP_REFERER'] : '';
$host = parse_url($referer, PHP_URL_HOST);
// 只有从我自己域名点出来的链接，才放行
if (!in_array($host, ['tjsky.net', 'www.tjsky.net'])) {
header('HTTP/1.1 403 Forbidden');
die('非法请求：禁止直接访问或盗链。');
}
- 直接 403：即使被利用了，正经的爬虫也能发现报了“403 拒绝请求”
- 不依赖 JS ：彻底杜绝了扫描器把这里“误判”为开放重定向漏洞的可能。
放弃手搓正则，拥抱 filter_var：不再自己造轮子
当年真是的小白菜的常见状态，又菜又感觉自己强，当年的 URL 合法性检查是自己手搓的
strpos($_SERVER['REQUEST_URI'], "eval(") ||
strpos($_SERVER['REQUEST_URI'], "base64")||
strpos($_SERVER['REQUEST_URI'], "127.0.0.1")||
……
//省略其他过滤语句
$t_url = preg_replace('/^url=(.*)$/i','$1',$_SERVER["QUERY_STRING"]);
//判断非空
if(!empty($t_url)) {
//判断取值是否是base64
if ($t_url == base64_encode(base64_decode($t_url))) {
$t_url = base64_decode($t_url);
}
我当时防御漏洞的逻辑很直观：黑客可能想干嘛，我就拦什么。黑客想传 eval，我就在代码里搜 eval；黑客想传 base64，我就搜 base64。这在安全领域叫“黑名单防御”，但其实：
- 这本来不应该是跳转页该做的事，这种事情应该交给更前边的更专业的WAF去做。
- 这种方式就像玩“打地鼠”，只要稍微换个姿势（比如利用 URL 编码或者空格绕过），我的之前正则就成了摆设。
- 而且逻辑本来就有bug，我为了不让部分跳转目标直接能看出来，加了可以将跳转目标 base64 化的机制，但问题是，我当年光想着检查要最优先进行了，忘了检查在解码base64的之前的话，又一次导致检查了个寂寞。
这次重构，因为使用了PHP跳转而不是前端跳转，所以改用 PHP 内置的filter_var来检查跳转 URL 的合法性，并且先解码，再检查。再配合FILTER_FLAG_NO_PRIV_RANGE之类的参数去防止对内网和私有 IP 做跳转。
//base64解码部分代码就不写了，只看filter_var部分的。
$url_host = parse_url($final_url, PHP_URL_HOST);
//过滤本地主机
if (strtolower($url_host) === 'localhost') {
die('非法目标：你访问本地主机干啥。');
}
if (filter_var($url_host, FILTER_VALIDATE_IP)) {
//_PRIV_RANGE: 过滤 192.168.x.x, 10.x.x.x, 172.16.x.x 之类的大内网
//_RES_RANGE: 过滤 0.0.0.0, 127.0.0.1 等保留地址
if (!filter_var($url_host, FILTER_VALIDATE_IP, FILTER_FLAG_NO_PRIV_RANGE | FILTER_FLAG_NO_RES_RANGE)) {
header('HTTP/1.1 403 Forbidden');
die('非法目标：你访问内网地址干啥。');
}
}
//确保链接格式符合 RFC 标准
if (!filter_var($final_url, FILTER_VALIDATE_URL)) die('目标链接格式错误。');
- 防止跳转内网和本地主机，作为一个外链跳转服务，没有任何正当理由需要指向一个内网或本地的 IP 地址。（这里只堵了IP，毕竟使用域名指向内网IP需要DNS配合，这利用难度就高了）
- 防止包含了空格、非法字符，错误的协议头：仅这一条就能这直接过滤掉了 90% 的低级扫描和恶意注入。
- 防止 XSS 脚本注入：以前构造
?url=javascript:alert(1)的话。在老代码里，这会被当作合法 URL 运行。而filter_var会识别出这不符合 Web 协议规范，直接在入口处将其掐死。 - 防止畸形参数：恶意利用时，很喜欢在参数里混入换行符或特殊的二进制字符来试图截断逻辑。这些东西在
filter_var的眼里都是不合法的它只认符合 RFC 标准的纯净 URL。
当然filter_var本质上是一个“格式校验器”，挡不住顶尖高手的定向渗透，比如传入一个格式完全标准，但指向内网某个邻居的数据库的域名。filter_var 会因为它符合 URL 规范而放行。这就是所谓的 SSRF（服务端请求伪造） 风险，这类深层次的逻辑漏洞，单靠一个函数是无法完全杜绝的。但面对互联网上每天成千上万次的自动化扫描和脚本攻击，它表现得比我那些个漏洞百出的正则要好太多了。放弃对“手搓代码”的执念，承认现成工具套件，尤其是安全、密码方向的现成轮子专业能力。现在的外链跳转页代码已经是一份真正的PHP安全跳转代码了。
更多细节修改：交互和 SEO 的多重升级
把原来的“静默X秒后跳转”改成了“倒计时卡片”：
- 使用 10秒倒计时：给访客足够的时间看清“您即将离开博客”的提示。
- 在页面内显示目标网址，看清到底要去哪里，确认目标网址安全。
- 加一个立即跳转的按钮，让不想等自动跳转的人可以立刻去要去的地方。
增加 htmlspecialchars 防止 XSS 攻击
因为现在的跳转页有一个跳转URL“预览框”。如果万一黑产绕过了前面的检查，把一段代码伪装成 URL 传了进来，直接打印在 HTML 里是非常危险的，搞不好就引发 XSS 攻击了。 htmlspecialchars会把所有的 <、>、"等特殊字符全部转义成 HTML 实体，让前端可以安全展示URL。
$display_url = htmlspecialchars($final_url, ENT_QUOTES, 'UTF-8');
增加 noindex, nofollo 标头
额外增加 X-Robots-Tag：直接在 HTTP 标头中加入 noindex, nofollow，直接告诉搜索引擎爬虫：“这个页面通通都别收录，权重别传递”。这比在 <head> 里写 <meta name="robots" content="noindex, nofollow" /> 更优先，爬虫不需要解析 HTML 就能看到，从而更有效保护博客的 SEO 资产。（当然meta也要加，毕竟某搜索引擎的爬虫不认这个响应头）
<?php
header('X-Robots-Tag: noindex, nofollow');
进阶玩法：使用 AES 加密隐藏真实链接
本来这次对外链跳转页的重构也就止步于上一步了，有些熟悉本站的人，估计已经发现新版跳转页已经上线运行了一段时间了。
我最近在爬取一个图片资源站时，发现对方有个很有意思的设计，这个图片站为了防止遍历本地路径实现快速抓取图片资源，他把站内的图片链接都AES加密了。我只能看到他图片都是类似主域名/img/?url=OVA2Q……HBIdz09-d这样的地址。如果不知道加密密钥，就无法生成正确的资源地址。
我一琢磨，虽然我的跳转页有个来源域名检测，防止非本站访问。但 HTTP Referer 伪造起来难度也不高。要是真有人拿我的跳转页去搞伪装钓鱼的话，他自然能伪造请求头的。
于是我决定做个“二次进化”：使用 AES 加密跳转地址。
不过这个图片站的 AES 加密方案还是不太完善，因为很容易就能发现，他所有图片的开头和结尾字符串都是固定的。很明显是个使用 ECB 模式(固定使用同一个密钥)做对称加密的结果。
我打算更进一步使用 CBC 模式 （随机初始化向量）做加密，逻辑是：[ 随机生成的 16 字节 IV ] + [ AES 加密后的实际网址 ] 打包在一起再 Base64 编码。
这样服务器只要收到密文后，只需要先解码base64，截取前16个字节作为IV，用密钥和刚才拿到的IV，去解密后面的密文，就可以得到实际跳转地址。（从防止变成开放重定向跳板这个角度， ECB 模式已经能挡住黑产了，用 CBC 纯属为了“既然做了就做到极致”）
$final_url = '';
// 尝试 AES 解密
$binary_data = base64_decode($input_code);
if ($binary_data && strlen($binary_data) > 16) {
$iv = substr($binary_data, 0, 16);
$ciphertext = substr($binary_data, 16);
// 使用预设的密钥解密
$decrypted = openssl_decrypt($ciphertext, AES_METHOD, AES_KEY, OPENSSL_RAW_DATA, $iv);
if ($decrypted && strpos($decrypted, '://') !== false) {
$final_url = $decrypted;
}
}
这样带来的好处是巨大的：
1. 动态密文：因为 IV 是随机的，同一个网址每次加密出来的字符串都不一样，无法通过简单的特征分析来破解。
2. 杜绝搬运：那些喜欢“采集”我文章的爬虫（说的就是你，CSDN），搬运过去后跳转链接会直接失效，倒逼他们必须手动处理。
3. 无数据库：不需要像短链外链方案那样需要数据库来存链接白名单，我只需要保存好密钥就可以，只要解密失败，就说明这不是我自己生成的链接。
4. 防伪造：取消明文跳转和基础base64链接跳转后，可以彻底堵死跳转页可被第三方利用的可能性。只要解密失败直接不跳了。
其实从防止变成开放重定向跳板这个角度， ECB 模式已经能挡住黑产了，用 CBC 模式纯属“既然做了就做到极致”罢了。而且其实有了这个加密机制后，前边的什么来源验证啥的都可以不要了，毕竟未来只支持使用加密后的密文做跳转，只要没有密钥，第三方不可能构造出实际可用的跳转密文，也就无法利用我的跳转页。以 AES 加密的强度来看，想要根据已知「明文，密文」来反推密钥需要的算力资源过于庞大了。
结语
咋说呢，当年作为“CV 工程师”省下的脑子，最后都变成了日志里的红字报警。
现在的跳转页，虽然功能没变，但它不再是一个过于容易被攻破的漏洞，而是一个安全、可控的流量出口。如果你也在维护类似的跳转功能，不妨也检查一下：你的跳转页的“安全检查”，是真的在检查，还是在自欺欺人？
📂 源码下载
跳转页的代码已经在Github开源啦（含详细注释，适用于 WordPress / Typecho / Z-Blog 等一切 PHP 站点）：
👉 点击查看：安全的外链跳转页源码
前边这个外链的跳转就是使用AES加密后的跳转链接，只有到执行跳转时才会显示出真正的跳转目标。
小赵同学
2026-02-08 19:53
很专业 其实这种跳转页 还是很重要的 对于国内有备案审查的站点来说
去年夏天
2026-02-08 20:42
有备案的网站真的要很小心，管局的策略总是让人难以捉摸😮💨
Jeffer.Z
2026-02-04 22:58
大概是大佬的流量多，被盯上啦。小站其实很少遇到这种的。
去年夏天
2026-02-04 23:52
可不，之前没流量时完全没问题，现在每天仅被WAF拦住试图利用中转页搞XSS的恶意利用就能有几百次。
旺东
2026-02-03 22:11
我是第一个点 Star 的人！
去年夏天
2026-02-03 22:31
hhh，感谢star🙏
小草的日记本
2026-01-29 19:02
虽然看不懂。但我觉着现在有了AI可能对写不懂得代码能友好一点？
去年夏天
2026-02-03 16:19
AI的话，直接和他说“我需要一个基于PHP的文章外链跳转页，需要防范跳转页被恶意利用，用户体验友好”，基本顶部模型AI写出来的都能是用的。
石樱灯笼
2026-01-28 21:58
说到这我反而有一个疑问，你的网站，用国内IP打开的话，每个页面第一次速度都飞快，然后就卡死到超时了。我之前以为是IPv6抽风（因为我没有国外的IPv6地址），但是看nslookup却反现是IPv4 only的。
也不知是什么神奇的限制。
去年夏天
2026-01-29 09:59
你不会是联通吧，最近我观测到联通去新加坡的普通线路开始全面劣化，之前都是走联通自己的A网从广州直连新加坡交换点，现在会走联通169网去美国接入tata的线路再去新加坡。丢包和延迟整的比电信的163线路还大。
去年夏天
2026-01-29 10:46
你再试试，我删了一堆可能需要魔法的东西。应该能快点
石樱灯笼
2026-01-29 13:15
跟依赖没关系，就是直连你域名慢。
用ipip的traceroute看了下，联通的确是绕行美国tata AS6453的。
去年夏天
2026-01-29 14:17
开始我以为是腾讯云线路的问题，我又试了试阿里的和新加坡当地的，联通现在全绕路了，全是北京出口，不是绕美国就是绕东京，有点蛋疼。
哎，之前白嫖联通精品A网的日子一去不复返了。感觉要看看解决下了，要是一直这样，出口这台机器就要废掉了。
石樱灯笼
2026-01-29 14:46
我是不研究这玩意。个人控制不了的。我反正都套皮cloudflare。
去年夏天
2026-01-29 17:17
套cloudflare起码也要稍微折腾一下规则的呀，不然我之前测试，直接套CF，还不如我直连快呢（当然现在是套了CF和直连差不多一样了，反正都是绕美国）
我是军爸
2026-01-28 20:03
感觉很有用，很厉害。收藏备用
去年夏天
2026-01-28 20:28
整个试试吧
寻鹤
2026-01-28 18:46
不会开发，我就老老实实用博客系统了
去年夏天
2026-01-28 20:11
有些博客系统/主题自带跳转页，直接用就行。
快乐随风飘
2026-02-07 20:48
我只要用开源博客就会被挂马，实在没招了，摆烂了。最后发现ai生成的简单的网站反而没有被挂马
ACEVS
2026-01-28 14:07
好吧。没整这个，路过。
去年夏天
2026-01-28 20:10
按说，最好出站链接都经过中转页，不过很多人也就一直直链用下去了
Styunlen
2026-01-27 20:53
上面这个功能是因为更上面的Referer 来源检查吧？为啥放在了“使用 AES 加密隐藏真实链接”板块，有点没看懂。
不过我还想到了进阶版，跳转加密的的时候添加时间戳，同时对验证添加签名校验，防止参数被修改，这下真就只能从原站点老老实实跳转了，而且用户直接复制链接也不行，有时间限制~
去年夏天
2026-01-27 21:11
因为之前他们搬运的时候，会用正则直接把我前面的跳转链接“XXXXX/goto/?url=” 给删了，只保留最后的目标链接。（因为之前目标链接是明文的嘛），加密之后就必须经过跳转页的解析才能拿到跳转目标。虽然还是也可以用脚本实际访问一下拉到最终的链接，但这不就更复杂了嘛。很多自动搬运的没这个技术水平。
Styunlen
2026-01-27 21:19
太强了hhh，我好久不用国内搜索引擎了，已经很少检索到 csdn 的文章了。我现在遇到问题，搜到最多的几个网站是 reddit、stackoverflow、github，其中提供的解决方案都是能一步到位解决问题的，如果解决不了，那就是软件的 bug。
时间就是生命，如果用 csdn 的话，得多费一条命来解决问题，另外还需加点钱充个会员😂😂
依云
2026-01-27 19:56
我一直没明白为什么要设计这种中转页面——Google、YouTube、Mozilla的中转页面会告诉用户正在跳转到第三方网站，姑且算是一种免责声明。那base64甚至加密的目的何在？向用户隐藏链接目标，难道不是非常可疑的行为吗？用户根本无从判断链接目标是正常网站、还是浏览器0day漏洞利用页面。
去年夏天
2026-01-28 09:24
跳转页本质是告诉搜索引擎：
1. 用户要去的这个地方和本站没关系，不对此负责。不要因为一个优质站点内，写了他的链接就认为在推荐他，提高他的搜索权重。
2. 不要告诉目标页，访客是从我这里点进去的。
3. 留评论的人，写下的网站链接不一定是正经网站。之前就有一个评论他的域名到期后被一个博彩站用了，还导致我被必应警告了，说我页面上存在钓鱼链接。:joy:
至于在文章内对用户加密隐藏链接（我这个隐藏不了，跳转页上会写具体将要去哪里）
有两个情况：
1. AFF链接：有些软文引导用户点击的网址是带返利尾巴的，如果直接展示出来，用户就可以去掉AFF访问。
2. 隔离爬虫：虽然跳转链接写了标头noindex, nofollow，但搜索引擎爬虫还是能看到网址本体的，他还是会认为我在推荐那个站点。加密后爬虫看不到网址了，在跳转页因为延迟了10秒，爬虫也不会顺着跳转页爬过去。就完全不会认为我在推荐那个站了。
为了防止被当作开放式重定向漏洞，让跳转页仅自己可用
你说的这种情况对推特，脸书，知乎等社群是对的，如果加密用户根本无从判断链接目标是正常网站、还是浏览器0day漏洞利用页面。但对于个人博客站点，如果想要做坏事，不用这么费劲，“我都已经成功让你点进来我的网站了，我为什么不在这个页面上就想办法加载0day利用页面，反而额外增加一步用户交互过程，降低成功率呢”
依云
2026-01-28 09:58
有nofollow指示可以用呀。
网站可以配置referrer策略呀。另外现在默认跨站只给域名了。
是啊，所以nofollow呀。用户产生的链接都需要加这个。
有去aff意识的用户，可以在浏览器访问目标URL的前一刻干掉尾巴的
真的吗？正经搜索引擎不应该会无视nofollow指示才对，不然问题会很大
这不应该是检查referrer吗？加密确实没办法，但base64对程序来说约等于明文了。
因为提交链接的人不一定能够在页面上执行脚本呀。
另外中转页面还有个问题是会追踪用户访问了什么链接（我记得 t.co 主要就是干这事的）。有些用户并不喜欢这样。
去年夏天
2026-01-28 10:24
nofollow的直链只阻止了爬虫沿着外链继续抓取并索引，而不会阻止搜索引擎认为你在推荐这个链接，也不会阻止搜索引擎去看一眼，搜索引擎还是会分你的权重给外链，并且依然会因为这个链接后面是问题网站，而给你的站点扣一个“存在欺诈页面”的帽子，导致用户访问时出现红屏警告。（不然我也不会被评论区的博彩站连坐了，之前是有写nofollow的直链）if ($http_referer ~* "(aabbcc|ddeeff)\.(com|vip)") return 444; }但很快他就开始伪造来源为谷歌。请求头属于防君子不放小人，真打算恶意利用的很容易就绕过了。依云
2026-01-28 10:37
呃，那确实如此啊。所以需要及时处理垃圾信息啦。
在浏览器里是没法伪造的，所以无法给普通用户点击的时候用。
我会啊。手机里长按链接也可以看到URL，虽然没有%解码有点不好看。
诶，你不是说加密重定向是给UGC用的吗？
link audit？还是监听click事件？无论哪种，用户不想让网站知道的话都是有办法的。只有服务端处理的才没办法，所以b23.tv很讨厌。
另外，重定向链接也会给只复制链接目标（发给别人看）的使用场景带来额外的负担。
去年夏天
2026-01-28 11:46
处理不了:joy: 3年前他给我留言时，他的域名是个正常的个人博客，留言都是正常的交流，1年后他域名到期，几个月后域名被博彩站买走，不可能每天都遍历所有人的链接看还是不是正常站。（所以也有站长采用，超过3个月的评论，名称的超链不可点击的方案解决这个问题）
你说的对，确实浏览器内无法伪造，但
1. 写爬虫、刷流量脚本的人会用跳转页当中间脚本，他脚本伪造来自我的站点，然后用我的跳转页去访问，他实际想爬取的站点。（为啥绕一下不直接伪造成我的站点？因为这样更真实，这是一次真实的跳转）
2. 现在有个灵魂问题“没有 Referer 的请求（空 Referer），我放不放行？”从用户体验角度，其实是需要允许为空的，因为“HTTPS 页面跳转到 HTTP 页面时，标准规定不发送 Referer”，“右键 -> 新标签页打开”，Referer 可能会丢失。隐私浏览器（如 Brave）或插件，会屏蔽了 Referer。但如果允许为空，因为浏览器环境下还是可改no-referrer，邮件/IM软件中点击基本也是空的，那黑产依然可以实现「黑客给受害者发钓鱼邮件，IM消息，邮箱和IM的安全检测看到内容部分的链接来自
tjsky.net，可信链接，受害者点击链接，请求 Referer 为空，中转页代码放行，将受害者跳到有问题的网站。」的链条。你的安全意识挺高的，所以我实际做法是：不做静默跳转，而是让跳转页显示目标域名，强迫用户看一眼他要去哪里。加密只是为了不让爬虫看到，用户还是会看到目标网址，甚至是强制他去注意到。
所以还是那句话：我特意设计为跳转页，不做静默跳转和短链，而是让跳转页显示目标域名。这样只要用户想要不被跟踪，那就可以在10秒内复制走明文链接（并且处理好链接内可能存在的参数尾巴），自己粘到浏览器地址栏去访问。
目前我这个中转页，兼顾安全和隐私，当然不讲究的站长那就可以直接上短链和立刻跳转的中转页
去年夏天
2026-01-28 11:58
其实我感觉咱们的核心点在于：你感觉我加密了链接是为了搞事情，但我加密只是为了应付爬虫和被恶意利用。
但确实如你所说，虽然我特意在跳转页做了延迟+显示目标链接，这总兼顾隐私与安全机制，但“在点进去之前，谁知道这一坨加密的东西是啥，我自己会检查并处理链接的，请直接拿给我，我才信任你”
依云
2026-01-28 12:03
惨……想起libsoup以前的官网也是这样的命运。我从GTK那边的页面点过去，还疑惑了半天发生了什么。
我倒是没有遇到这种的。我手上的站，要么是被各种不正常或者疯狂的LLM爬虫盯上，要么是被pcdn刷流量。前者有些甚至连装都不装，直接用不存在的地区和浏览器版本的UA来访问……
反正给浏览器用的页面，我统一上浏览器验证了。有群爬虫似乎是用了真正的浏览器来爬，于是给它们上人机验证了。
去年夏天
2026-01-28 14:30
我去年被PCDN刷流的事情，你应该还记得，这家伙现在还在刷呢……全是广东家宽IP。爬虫我这里最多的是MJ12bot，也不知道为啥他特别喜欢爬我的站
不过咱俩这么一讨论，倒是有个新想法，可以再做一个“隐私不友好的邪恶版中转页源码”增加几种恶心用户利好站长的措施，比如
window.location.replace(...)改成<meta http-equiv="refresh" ...>。前一种实现用户点后退键是直接回到文章页。而后一个会回到跳转页，因为前边那条的存在，用户会被立马再跳到目标页。依云
2026-01-28 15:17
我遇到过这种 233，曾经从「Google新闻」跳转到的某些新闻资讯类网站是这样，后退之后会退到它们的首页。还有些广告网站，连续跳好几次，不右键/长按「后退」选择目标根本跳不回去。
J.sky
2026-01-27 19:11
WP 对于新手部署确实友好，但是运维想要做到熟练，真得花些时间。
去年夏天
2026-01-27 22:25
WordPress 毕竟是占据了全球网站最大比例的框架，无论是搜索引擎还是 AI，还是前端浏览器，还是后端服务器都能最大化兼容它
J.sky
2026-01-27 19:04
你俩都是真正的大佬。
17
2026-01-27 18:07
前排学习
J.sky
2026-01-27 17:20
膜拜了！
obaby
2026-01-27 17:08
这个属实专业了
去年夏天
2026-01-27 17:22
姐姐才是专业的，我这纯属业余水平😄