简介面向网络推广与域名防红需求的用户这套最新域名防红跳转源码提供带后台管理的随机跳转方案。其核心机制是让访问者先从入口域名随机跳转到干净的中转域名再随机跳转到最终产品链接通过两次随机跳转分散风险即使某个域名被屏蔽仍有几率正常打开从而有效降低推广链接被封禁的概率。资源共10个文件包含PHP后台程序、SQL数据库文件、CSS样式、JavaScript及HTML页面等压缩包整体20.51MB解压后导入数据库并修改配置即可使用。后台支持域名管理与链接管理可同时配置多个中转域名和展示域名适配MySQL5.6、PHP7.2环境部署门槛低。目前已有109人学习下载适合需要稳定推广落地页的运营者作为防红方案参考。1. 域名防红跳转是什么一个被屏蔽网址是怎么靠跳转“活”下来的你有没有遇到过这种情况把一个网址发到微信群里点开后不是目标页面而是一句“已停止访问该网页”。这就是所谓的“红码”——域名被微信的安全风控标记了。做了正规备案也不代表不会被拦很多临时活动页、推广落地页、测试环境都可能在微信内置浏览器里直接吃红。于是就有了“域名防红跳转源码”这一整类工具它不直接给你一个能访问的页面而是给用户一个中间跳转层先判断访客用的是微信内浏览器还是普通浏览器再决定是直接放行到目标地址还是先打开一个引导页让用户“在浏览器中打开”。配一个后台你就能随时换跳转域名、改目标地址、调随机策略让屏蔽失效的速度追不上你换域名的速度。这个方向在求购源码的热词里一直很活跃但网上流传的版本大多要么是漏洞百出的老代码要么是打包卖钱的半成品。本文不评价其合规边界只从技术实现角度讲清楚一套能自己部署、带后台、支持随机跳转的防红系统该怎么写原理是什么、表怎么建、跳转接口怎么写、踩过哪些坑。适合手里有几个域名、想自己维护一套跳转中转页的人读不适合指望挂上就能一劳永逸的人读因为防红本身就是一场和风控策略的拉锯战。2. 防红跳转的底层原理与选型为什么是 UA 识别 随机域名池2.1 防红跳转的三个关键动作识别环境、决定跳法、甩掉追踪防红跳转不是玄学它核心就做三件事。第一识别访客的浏览器环境。微信内置浏览器、QQ 内置浏览器、普通浏览器它们的 User-AgentUA字符串里有明显特征比如微信的 UA 里一定有MicroMessengerQQ 的是QQ/。有了这个信息系统就能区分这个用户是不是在被风控的应用内打开的链接。第二决定跳转方式。对普通浏览器直接 302 跳转到目标页对微信/QQ 内浏览器则返回一个“非微信环境”的中间页引导用户点击右上角菜单选择“在浏览器中打开”。第三让每次跳转尽量不同。随机从域名池里挑一个当前可用的域名作为跳转入口这样同一个目标页在不同用户看来访问的中间域名是变化的风控系统更难把多个访问行为关联到同一个域名上。很多人以为“防红”是加密跳转参数其实参数加密只是辅助。真正有效的防屏蔽手段是域名池足够大、切换足够快以及中间页做得足够像正常页面。跳转本身用的是 HTTP 302没什么可加密的。判断逻辑也不复杂PHP 里一个strpos就能完成难点在于管理这些域名的状态以及让整个跳转流程在用户体感上不像是“被跳转了”。2.2 技术选型为什么用 PHP 写而不是 Python 或 Node.js防红源码适合用什么写我建议 PHP。理由有三条。第一部署门槛低虚拟主机就能跑而 Python/Node 至少要一个常驻进程很多人的域名服务器是 Windows 上的小主机跑 PHP 比跑 Python 省心。第二这类源码的常见形态就是一个index.php入口加一个后台目录PHP 天然适合这种小体量 Web 应用不需要额外框架。第三PHP 的header(Location: ...)做跳转极其直接配合 Nginx/Apache 的伪静态规则很快就能上线。但 PHP 也容易被写出漏洞尤其是后台登录。所以代码里必须有严格的 Session 校验、密码哈希和 SQL 预处理。不要为省事把登录密码 md5 一下直接存数据库更不能把后台文件暴露在 public 目录下。我会在后台入口加一层访问密码不是 Cookie 验证是请求头校验这样即使别人扫到后台路径也进不去。2.3 随机跳转的“随机”到底在随机什么“支持随机跳转”这个功能点很多人理解错了。以为随机是随机挑一个目标网址跳过去那叫随机轮播不是防红。真正的随机跳转随机的是“入口域名”。也就是当用户请求跳转接口时系统从当前状态为“正常”的域名列表里随机挑一个域名拼成跳转 URL然后再附加一个随机 token 参数。这样每次请求返回的Location头都不一样风控设备看到的是不同域名在发起跳转而不是同一个域名疯狂 302。随机算法这里有个细节不能纯用rand()因为同一秒内大量请求可能打到同一个域名。我一般这样做先把域名池按最后使用时间排序取最近 30 分钟内未使用过的域名从里面随机挑如果全部都用过就选使用时间最早的那个。这个策略既保证了随机性又避免了单个域名被短时间高频请求。后面第 4 章会给出完整代码。3. 带后台的防红跳转系统数据库设计与管理权限3.1 建表域名池、跳转记录、管理员三张表够了不要一上来就设计十几张表防红系统的核心数据模型就是三张domains放域名池logs放每次跳转记录admins放管理员账号。域名表字段我实际用过这些CREATE TABLE domains ( id INT NOT NULL AUTO_INCREMENT, domain VARCHAR(255) NOT NULL COMMENT 跳转域名如 jump.example.com, target_url VARCHAR(500) NOT NULL COMMENT 目标网址, status TINYINT NOT NULL DEFAULT 1 COMMENT 1正常 2暂停 3已失效, jump_type TINYINT NOT NULL DEFAULT 1 COMMENT 1随机跳转 2直接跳转, use_count INT NOT NULL DEFAULT 0 COMMENT 已使用次数, last_use_time INT NOT NULL DEFAULT 0 COMMENT 最后使用时间戳, create_time INT NOT NULL DEFAULT 0, PRIMARY KEY (id), KEY idx_status (status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;日志表单独说明一下。防红跳转的日志和普通的访问日志不一样需要记录的不只是 IP 和 UA还要记录命中了哪个域名、使用了哪种跳转方式、用户最终是否到达了目标页这需要目标页回传一个通知才会知道。前两者在跳转时就能写好CREATE TABLE logs ( id INT NOT NULL AUTO_INCREMENT, domain_id INT NOT NULL, user_agent VARCHAR(500) DEFAULT NULL, ip VARCHAR(64) DEFAULT NULL, jump_type TINYINT DEFAULT 1, is_wechat TINYINT DEFAULT 0 COMMENT 是否微信内打开, create_time INT NOT NULL DEFAULT 0, PRIMARY KEY (id), KEY idx_create_time (create_time) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;3.2 后台登录Session 请求头双重校验后台入口我建议单独建一个admin.php不要和跳转入口index.php混在一起。登录逻辑用 PHP 自带的 Session 就够了但密码校验要加一层管理员密码在数据库存password_hash()生成的哈希登录时用password_verify()校验不要用 md5。另外加一个“后台访问码”写在配置文件里请求头里带上特定字段才能访问后台页面这样能挡住绝大多数扫描器的直接访问。后台页面本身不需要多精致vue 后台管理系统那种复杂工程没必要纯 PHP 一个简单的 HTML 表格就够了。后台要支持的功能就四个添加域名、修改目标地址、暂停/启用域名、查看跳转日志。你甚至可以把这个后台当成一个单独的子路径部署例如/admin/然后用 Nginx 只对这个路径做 IP 白名单限制这才是最有效的安全管理方式比什么验证码都强。3.3 目标网址维护为什么不建议写死在表里有相当一部分防红源码把目标网址写死在 PHP 文件里换一次链接就要改一次代码。我建议把目标网址放在域名表里每个域名可以指向不同的目标地址也可以多个域名指向同一个目标地址。这样做的好处是当目标页面被微信拦截时你只需要在后台把对应域名的target_url改掉不需要重新保存代码也不影响其他域名。更细一点同一个目标可以在域名池里建多条记录每条记录对应不同的跳转域名但target_url相同。跳转随机到哪个域名最终都落到同一个目标页。风控封的是域名不是目标页本身只要目标页能换域名继续访问这套系统就还能运转。4. 核心跳转接口与随机策略让屏蔽失效的落地实现4.1 跳转入口 index.php只做一件事按环境分发入口文件不需要花哨一个index.php就能覆盖全部逻辑。它的任务顺序是拿到当前请求的域名与访问参数 → 查询数据库中该域名的状态 → 如果状态正常并且批次 token 合法则进入跳转分支。这里有一个很关键的点不要在入口文件里加任何“验证码”或“强制等待”功能。防红跳转的用户大多是从微信被拦后来找“后悔药”的如果中间页还要输验证码流失率极高。?php session_start(); require_once config.php; require_once db.php; // 1. 根据请求域名找到对应的跳转记录 $host $_SERVER[HTTP_HOST] ?? ; $stmt $pdo-prepare(SELECT * FROM domains WHERE domain ? AND status 1 LIMIT 1); $stmt-execute([$host]); $row $stmt-fetch(PDO::FETCH_ASSOC); if (!$row) { header(HTTP/1.1 404 Not Found); exit(page not found); } // 2. 记录日志这里不记录完整IP只记录前两段避免隐私问题 $ua $_SERVER[HTTP_USER_AGENT] ?? ; $ip_long $_SERVER[REMOTE_ADDR] ?? ; $is_wechat (strpos($ua, MicroMessenger) ! false) ? 1 : 0; // 3. 根据环境决定跳转方式 if ($row[jump_type] 1) { // 随机跳转从域名池随机挑一个其他可用域名作为中转 $stmt $pdo-prepare(SELECT domain FROM domains WHERE status 1 AND id ! ? AND last_use_time ? - 1800 ORDER BY RAND() LIMIT 1); $stmt-execute([$row[id], time()]); $alt $stmt-fetch(PDO::FETCH_ASSOC); if ($alt) { $token bin2hex(random_bytes(8)); $jump_url https:// . $alt[domain] . /go?token . $token; } else { // 没有可用备选域名就直跳目标但保留 UA 检测的引导逻辑 $jump_url $row[target_url]; } } else { $jump_url $row[target_url]; } // 4. 微信内打开时不直接302展示引导页 if ($is_wechat) { // 输出一个简易引导页JS 不做自动跳转必须用户点按钮 echo !DOCTYPE htmlhtmlheadmeta charsetutf-8meta nameviewport contentwidthdevice-width,initial-scale1; echo title正在打开/title/headbody; echo p请点击右上角 b···/b选择 b在浏览器中打开/b 以访问页面。/p; // 正式输出前记录日志 log_visit($pdo, $row[id], $ua, $is_wechat, 2); exit; } // 5. 普通浏览器直接 302 log_visit($pdo, $row[id], $ua, $is_wechat, 1); header(Location: . $jump_url, true, 302); exit;这段代码有两个我常用的细节。第一个是记录日志放在了跳转之前避免header()之后输出任何内容导致跳转失败。第二个是日志的 IP 我推荐只记录前两段例如192.168.x.x存成192.168减少隐私风险也能满足大多数“看来源地区”的需求。$is_wechat的判断用了简单的strpos如果 UA 为空也可能是爬虫这种情况直接按普通浏览器处理没必要单独拦。random_bytes(8)生成的 token 虽然没存库但可以在日志里拿到用来反查这条跳转是从哪个域名入口发出的排查问题很有用。4.2 随机策略再封装把“最近 30 分钟没用过”改成配置项第 4.1 节的随机跳转用了last_use_time NOW - 1800这个条件但 30 分钟间隔是个拍脑袋值。如果你手上只有 5 个域名30 分钟冷却会导致备选域名为空直接就跳到目标页了。更好的做法是把冷却秒数做成配置项 —— 放数据库没有意义因为每次都要查配置直接放在配置文件config.php里改起来也方便。// config.php 片段 define(JUMP_COOLDOWN_SEC, 900); // 域名冷却时间单位秒建议900-1800 define(FORCE_BROWSER, 1); // 1微信内强制引导 0微信内也直接302不建议然后 4.1 里的 SQL 改成$cooldown JUMP_COOLDOWN_SEC; $stmt $pdo-prepare(SELECT domain FROM domains WHERE status 1 AND id ! ? AND last_use_time ? - {$cooldown} ORDER BY RAND() LIMIT 1);冷却是随机策略里最重要的参数。太短比如 60 秒同一个域名会短时间内大量重复使用风控封域名往往就在这个窗口。太长比如 3600 秒域名池的利用率低备选容易空。我自己的经验是 900 秒能被风控接受的概率最高前提是域名池至少 5 个域名以上。如果域名池只有两三个再怎么调参数也是杯水车薪不如去买新域名。4.3 防屏蔽进阶域名池健康检查与熔断防红系统的核心资产不是代码是域名。所以必须有一个能自动把失效域名“熔断”的机制。常见做法是后台建一个jump_check.php用 curl 循环请求每个跳转域名状态码 200/302 视为正常被返回 403/405 或内容里出现“已被停止访问”关键字就把status改成 3已失效。这个脚本不需要常驻可以用系统 crontab 每 10 分钟执行一次。*/10 * * * * cd /var/www/html php jump_check.php /dev/null 21jump_check.php里需要注意curl 要带一个正常的浏览器 UA否则很多服务器默认拒绝无 UA 请求。另外不要同时并发请求所有域名一个一个来每个设 5 秒超时。检查完把结果写入日志这样你在后台看到域名状态发生变化时能知道是实际被禁还是临时网络波动误判。5. 防红跳转的 5 个常见问题与排查跳转失效、后台进不去、被二次拦截5.1 现象微信里打开跳转页点击“在浏览器中打开”后还是被拦截原因大概率不是你的跳转代码有问题而是目标网址本身已经被微信封了。注意防红跳转解决的是“中间跳转域名被拦截”不是“目标网址被拦截”。如果用户最终落到的目标页被拦换多少跳转域名都没用。解决登录后台把该域名的target_url换成新地址。如果目标地址不能换那就需要目标页本身做一层“站内防红”——在目标页也放一段 JS 判断微信内置浏览器显示引导按钮而不是直接渲染内容。这两层是配合的跳转层负责把用户带到一个能访问的中间页目标页负责在微信内显示引导。不要指望单靠跳转层解决所有问题。5.2 现象后台登录成功后刷新页面又跳到登录页这种十有八九是 Session 失效或 PHP 配置里session.cookie_path设置不对。如果你把后台放在/admin/子目录而登录页跳转时写的是根路径/刷新时 Cookie 带不上Session 自然丢失。解决在config.php里手动指定session_set_cookie_params([path /])。另外检查 PHP 的session.save_path是否可写虚拟主机经常把存储路径指到只读目录。用php -i | grep session.save_path查看如果路径不存在用session_save_path(__DIR__ . /tmp)改到项目自己的目录。5.3 现象日志里显示有跳转但用户说打不开这说明跳转规则生效了但目标地址或中间域名本身响应慢/超时。我排查这类问题第一步是先看日志里命中的是哪个域名、去 curl 那个域名看响应时间。很多防红源码不记日志等于瞎跳因为故障发生在“跳转之后”你是看不到的。解决日志表一定要记录domain_id和create_time。然后写一个check_latency.php脚本对日志里最近 100 条跳转记录对应的域名做延迟统计平均超过 3 秒的域名直接标记为status2暂停。网速慢和打不开是两码事但如果域名解析 DNS 出错或 SSL 证书过期必须直接在健康检查脚本里检测。5.4 现象后台添加域名时提示成功但访问跳转地址还是 404这是最典型的伪静态配置问题。很多 PHP 项目依赖index.php作为入口但你的跳转域名解析后并没有把请求重写到index.php。Nginx 配置里缺少rewrite规则就会这样。解决检查 Nginx 站点配置确保有类似下面的规则location / { try_files $uri $uri/ /index.php?$query_string; }Apache 则对应.htaccess里的RewriteRule ^(.*)$ index.php [L,QSA]。配置好后重启 PHP-FPM 或 Apache 再测试。还有一个小坑如果你用的是 IP 搭配多域名VPS 上绑了多个域名到同个站点必须确认站点配置里的server_name覆盖了全部跳转域名否则访问未知域名会落到默认站点。5.5 现象随机跳转总是跳到同一个域名没有“随机”效果这个我看过不少源码原因是ORDER BY RAND()在小数据量下是随机的但如果 SQL 查询条件里有last_use_time NOW - 1800而你的域名池里只有一个域名满足条件那无论怎么RAND()都是同一个。解决先确认域名池数量。如果域名少就把冷却间隔调短比如从 1800 改成 300。另外如果你在代码里用了rand(0, count($list)-1)取数组下标那也容易重复建议直接用 SQL 的ORDER BY RAND() LIMIT 1。真随机没必要跳转不是抽奖关键是不要连续多次到同一个域名。可以再加一层日志里记录这个 IP 最近访问过的domain_id随机时排除掉上一条。6. 让防红系统更耐用验证脚本、日志分析、与域名池维护防红跳转不是搭完就一劳永逸它更像养鱼每天要看水、喂食、清理残饵。我自己的维护习惯是从三个角度把系统打磨得“不那么容易翻车”。第一验证跳转是否正常不要用手机打开微信试完就算。我会写一个check.php带两个参数模拟不同环境一个参数值为wechat时输出“原样返回”手动观察返回的 HTML 里是否包含引导文字另一个参数值为browser时用 curl 加-I看响应头里的Location是不是 302。这个脚本帮我省了很多事因为微信的风控有时只针对特定区域你在自己手机上试是通的不代表全国都通。# 模拟微信UA请求跳转页 curl -I -A Mozilla/5.0 (iPhone; CPU iPhone OS 16_0 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 MicroMessenger/8.0.49 https://jump.example.com/ # 模拟普通浏览器 curl -I -A Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/125.0.0.0 Safari/537.36 https://jump.example.com/第二日志要定期看但不能只看源 IP。我更关注is_wechat字段的占比和失败率。如果微信来源占比突然从 70% 降到 20%可能是微信改 UA 规则了如果日志里出现了大量user_agent为空或python-requests的请求那十有八九是被人扫到接口在狂刷。这种情况我会在入口最前面加一个简单的合法性校验在 URL 上带一个动态 token登录后台时获取没有 token 的请求直接返回 404不在跳转逻辑里浪费资源。第三域名池维护要保持在“随时有备用域名可换”的状态。我每新到一个域名不是直接放进池子而是先在本地用 curl 连续请求 20 次确认不会被特殊处理再手工在后台添加并打上“待观察”标记。观察一周后如果日志里没有出现异常响应才把status置为 1。已经失效的域名我不会删掉而是改成状态 3 留在表里防止误用。这样做的原因很实际风控策略是持续更新的以前正常的域名可能哪天一觉醒来就红了留着失效记录能帮你做规律分析比如是不是某个批次的域名都被同时处理了。最后说一个我自己踩过的坑曾经为了追求“完美防红”在跳转接口里加了很复杂的加密参数和指纹采集结果用户加载速度从 200ms 变成了 1.2 秒微信内的引导页还因为进行了太多次异步请求被风控提前拦截。后来我全部删掉只保留 UA 判断 302 随机域名池速度回到 300ms 以内反而稳定跑了大半年。防红跳转的核心是“快、轻、够用”别把一个轻量中间层做成重型网关。希望这些落地的细节能帮你在部署防红跳转源码时少走弯路。按第 2、3 章的步骤把表和后台搭起来再对着第 4 章的接口代码做修改你的第一版就可以直接上线测试了。遇到问题时回第 5 章对照现象排查通常都能找到原因。本文还有配套的精品资源点击获取