简介PHP泛域名站群源码是一套面向需要批量建立子站点、实施SEO优化或集中管理多域名的开发者与站群运营者的完整代码方案。它通过泛域名解析配合.htaccess重写规则使主域名下的任意子域名自动指向同一服务器以index.php作为统一入口结合addtxt.php、u.php及inc核心模块实现站群站点快速创建、文本内容添加与用户权限管理适合中高级PHP学习者对照实践。压缩包共18个文件涵盖PHP脚本、txt说明与数据文件、HTML模板、CSS样式、htaccess配置及JS统计脚本整体大小仅304KB。当前已有594人学习。资源内含使用说明.txt、templets模板、dbs数据库相关文件、robots.txt等完整目录结构可帮助读者理解泛域名站群的URL请求路由、模板渲染、内容管理及SEO控制逻辑也能直接应用于多域名内容分发、小型站群系统搭建为自建或改造类似项目提供可复用的基础。1. 项目概述与核心思路拆解1.1 泛域名站群到底解决什么问题很多人第一次听到“泛域名站群源码”这个说法第一反应是这不就是批量做站的工具吗其实这么理解只对了一半。从技术本质上讲泛域名站群是一套基于“泛解析 动态路由 多站点数据集”的PHP应用系统它解决的核心问题不是“怎么生成一堆垃圾站”而是“怎么用一套代码、一台服务器同时承载成百上千个彼此独立的网站”。举个例子你手上有5个品牌、每个品牌面向3个地区总共需要维护15个官网。传统做法是装15套CMS各配一个数据库每次升级要重复操作15遍光是改个版权信息都得通宵。而泛域名站群的做法是只部署一套主程序通过域名自动识别用户访问的是哪个站点动态加载对应的配置、模板和内容。新增一个站点无非是在后台填一条记录、绑定一个域名的事几分钟就能上线一个新站。这类系统常见的正规应用场景有这么几类企业多品牌官网集群子品牌拥有独立域名但共用同一套技术底座多语言站点用不同子域名分发同一产品的不同语种版本区域性分站比如shanghai.example.com、beijing.example.com独立展示当地内容平台型SaaS为每个入驻商户提供独立子域名。我个人接触这类需求大多来自中小型外包团队和企业的IT部门。他们普遍面临着“站点数量多、预算有限、维护人力少”的矛盾泛域名站群恰好是一个性价比很高的解决方案。1.2 为什么选PHP作为核心开发语言选型这事不能跟风得看场景。泛域名站群这类系统对语言的核心要求有三个部署门槛低、生态成熟、文档多到“抄作业”方便。PHP在这三点上至今仍有很强优势。先把立场说清楚不是说其他语言不行。用Python的Django、Node.js的Express、Go的Gin都能实现泛域名路由但如果你去问一线运维和外包接单的老手他们大概率还是推荐PHP。原因很现实——这类系统的部署环境通常是云主机或VPSLNMPLinux Nginx MySQL PHP架构在市面上有大量一键脚本和镜像遇到问题搜一下几乎都有现成答案。PHP在处理“泛域名路由”这件事上有天然的语言级优势。$_SERVER[HTTP_HOST]直接拿到当前域名通过substr、explode或者正则把主域名和子域名拆开就能得到一个站点的唯一标识。这块逻辑在PHP里写起来非常直白不需要额外的路由中间件。相比之下如果要用Java重构这套逻辑光工程结构、依赖管理、打包部署这一套流程就能让不少小团队打退堂鼓。再一个关键点是PHP的模板引擎足够丰富。Smarty、Twig、Blade随便选一个都能实现“一程序多模板”的需求。每个站点独立绑定一套模板目录用户访问时根据站点标识动态加载对应模板这种机制在PHP生态里已经非常成熟。2. 核心机制拆解泛域名解析与动态路由2.1 在域名层面做全局泛解析泛域名站群的第一步并不在代码里而是在DNS管理后台。你需要把*.yourdomain.com这条解析记录指到服务器IP。这个操作在阿里云、腾讯云、Cloudflare等平台基本一致就是添加一条主机记录为*的A记录。添加完之后随便敲一个不存在的子域名比如sdiufh.yourdomain.com它也会解析到你的服务器。这一步是所有后续逻辑的前提没有泛解析程序端收到任何请求域名都不可能正确“落”到你这台机器上。这里有几个容易踩的坑泛解析记录生效有延迟通常几分钟到几小时不等别刚加完就急着重启服务如果你的域名本身有www解析www这条记录会优先于泛解析被命中两者不要冲突泛解析不能覆盖已经存在的具体记录例如你已有mail.yourdomain.com那么mail子域名的访问还是会走原来的记录而不是泛解析。2.2 Nginx层将不同域名交给同一个入口DNS解析到位之后Nginx配置是下一个关键节点。不用每个域名写一个server块那样维护成本太高了。正确做法是写一个泛域名server配置把所有请求统一转发给PHP入口文件。server { listen 80; server_name *.yourdomain.com yourdomain.com; root /data/wwwroot/station; index index.php; location / { if (!-e $request_filename) { rewrite ^/(.*)$ /index.php?$1 last; } } location ~ \.php$ { fastcgi_pass 127.0.0.1:9000; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } access_log /data/logs/station_access.log; error_log /data/logs/station_error.log; }这段配置的核心是server_name *.yourdomain.com。它让Nginx把所有子域名请求全部收下统一交给/data/wwwroot/station下的index.php处理。上面的rewrite规则是为了支持伪静态URL让站内链接更友好。如果你的站点需要HTTPS泛域名证书是一个绕不开的问题。单个证书无法覆盖所有子域名最经济的方案是使用Lets Encrypt的泛域名证书certbot certonly --manual --preferred-challenges dns -d *.yourdomain.com -d yourdomain.com注意泛域名证书的签发必须通过DNS验证你需要在自己域名的DNS管理后台添加一条_acme-challenge的TXT记录。签发成功之后证书有效期是90天记得配置自动续期任务。提示泛域名证书的成本现在很低市面上也有免费的泛域名证书服务但不要图省事直接关闭HTTPS。现在浏览器对无证书站点的警告越来越严格正规运营的站点必须上HTTPS。2.3 PHP路由层解析域名并匹配站点Nginx把请求交进来之后才是PHP代码真正发挥作用的时刻。这一层的目标非常明确解析当前访问的域名识别出“这是哪个站点”然后加载对应配置。一个基础的路由实现长这样?php class DomainRouter { protected $primaryDomain yourdomain.com; protected $config []; public function __construct() { $host $_SERVER[HTTP_HOST] ?? yourdomain.com; // 去除端口影响 $host strtolower(trim($host)); $host preg_replace(/:\d$/, , $host); // 如果是主域名本身站点标识默认是 www if ($host $this-primaryDomain || $host www. . $this-primaryDomain) { $this-siteCode www; } else { // 取子域名部分例如 demo.yourdomain.com - demo $prefix str_replace(. . $this-primaryDomain, , $host); $prefix trim($prefix, .); $this-siteCode $prefix; } $this-loadSiteConfig(); } protected function loadSiteConfig() { // 从数据库或缓存中读取站点配置 // 示例SELECT * FROM sites WHERE site_code {$this-siteCode} AND status 1 // 如果查不到可以给出默认模板或404 } }这段逻辑里最核心的部分是str_replace(. . $this-primaryDomain, , $host)这一行。它把域名里的主域部分剥掉剩下的字符串就是站点标识。比如shop.yourdomain.com会变成shopbeijing.yourdomain.com会变成beijing。每一个站点标识对应数据库里的一条站点记录记录里存着它的站点名称、模板路径、数据库配置、缓存配置等信息。需要注意的是如果你的域名体系包含多级子域名比如a.b.yourdomain.com上述代码拿到的前缀会是a.b这种情况需要特殊处理。要么在配置中对前缀做正则匹配要么限制子域名只能有一级。我实际项目中遇到过这种需求最简单的做法是在数据库站点表里指定domain_prefix字段完全匹配优先、二级前缀匹配兜底。2.4 多站点之间的数据隔离设计路由逻辑搞定后下一个核心问题是数据怎么隔离。一套系统撑多个站最忌讳的是所有站点共用一套内容表那样数据会乱成一锅粥。我推荐的做法是“单库多表 字段隔离”或“分库隔离”两种方案。第一种方案共享数据库靠site_id字段隔离所有站点共用同一个数据库每张内容表增加一个site_id字段。查询时强制加上WHERE site_id ?条件。好处是部署简单、备份方便坏处是一张表的数据量会随站点数量线性增长查询压力比较大。第二种方案每个站点一套独立数据库站点配置表里记录该站点对应的数据库名称和连接信息。PHP路由层识别出站点后从配置表中读取数据库连接参数动态建立连接。$config [ host 127.0.0.1, dbname db_ . $siteCode, user root, pass your_password, ]; $pdo new PDO( mysql:host . $config[host] . ;dbname . $config[dbname], $config[user], $config[pass] );动态连接数据库的最大好处是网站之间数据完全隔离安全性高、维护边界清晰。缺点是如果站点数量达到几百上千个每个站点都要维护一套数据库结构升级表结构时要批量执行脚本操作繁琐。我个人的建议是站点数量在50个以内用第一种方案就够了超过50个优先考虑分库。如果站点数量再上到几百个量级就该上Redis缓存和队列来处理高频读写不能完全依赖数据库裸查。3. 实操过程从零搭建一套泛域名站群3.1 环境准备与安装清单开始写代码之前先把环境准备好。以一台2核4G的Linux云主机为例操作系统选择CentOS 7.9或Ubuntu 22.04都可以我这边以Ubuntu 22.04为演示环境。需要安装的组件清单如下组件版本建议作用Nginx1.22处理HTTP请求反向代理PHPPHP7.4或8.1核心语言运行环境MySQL5.7或8.0存储站点配置和内容数据Redis可选6.0缓存热点站点配置、页面静态化安装命令这里不赘述直接用apt或yum即可。装完后重点确认两个扩展是否已开启pdo_mysql和redis。php -m | grep pdo_mysql php -m | grep redis如果没有安装一下apt install php8.1-mysql php8.1-redis -y3.2 数据库表结构初始化这一步很关键表结构设计直接决定了后期扩展的灵活度。我常用的基础表结构如下全套可以放进一个install.sql里。CREATE TABLE sites ( id int(11) NOT NULL AUTO_INCREMENT, site_code varchar(50) NOT NULL COMMENT 站点标识对应子域名前缀, site_name varchar(100) NOT NULL COMMENT 站点名称, template varchar(100) DEFAULT default COMMENT 模板目录名, status tinyint(1) DEFAULT 1 COMMENT 状态0停用1启用, created_at timestamp NULL DEFAULT CURRENT_TIMESTAMP, updated_at timestamp NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_site_code (site_code) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT站点信息表; CREATE TABLE site_config ( id int(11) NOT NULL AUTO_INCREMENT, site_id int(11) NOT NULL COMMENT 所属站点ID, config_key varchar(50) NOT NULL COMMENT 配置键, config_value text COMMENT 配置值, PRIMARY KEY (id), KEY idx_site_id (site_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT站点配置表; CREATE TABLE articles ( id int(11) NOT NULL AUTO_INCREMENT, site_id int(11) NOT NULL COMMENT 所属站点ID, title varchar(200) NOT NULL, content longtext, status tinyint(1) DEFAULT 1, created_at timestamp NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_site_id_status (site_id, status) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT内容表;这套表结构非常简单但它是泛域名站群的基础骨架。sites表管理站点site_config存扩展配置articles存内容。如果你需要更多功能比如友情链接、SEO参数、图片管理后续在前面加对应字段或表即可。3.3 后台管理功能实现没有后台控制的泛域名站群是不完整的。后台至少需要实现三个功能站点管理、模板配置、内容发布。站点管理提供一个表单填写站点标识、站点名称、模板目录、状态。提交后插入sites表。这里有一个细节站点标识只允许小写字母、数字和连字符禁止使用特殊字符因为子域名本身不支持很多符号。模板配置每个站点绑定一个模板目录后台通过下拉框选择。实现时用一个数组维护模板列表$templates [ default 默认模板, enterprise 企业商务模板, minimal 极简风格模板, ];内容发布内容表关联site_id后台选择某个站点后只能操作该站点的内容。注意后台的登录验证必须使用独立的后台域名或独立路径不能和前台混在一起。我的习惯是后台使用admin.yourdomain.com并在Nginx层单独配置访问IP白名单限制只有公司IP能访问。3.4 前端页面动态加载流程前台访问一个站点的完整流程如下浏览器输入demo.yourdomain.comDNS解析到服务器IPNginx接收请求匹配泛域名server转发给PHPPHP路由层识别site_code demo查询sites表拿到该站点配置加载对应模板文件查询该站点内容数据渲染页面返回。这个流程的每一步都不复杂关键在于第5步和第6步的性能。如果每次访问都实时查询数据库获取站点配置并发上来后数据库压力会很大。我的做法是引入Redis缓存$cacheKey site_config: . $siteCode; $siteConfig $redis-get($cacheKey); if (!$siteConfig) { $siteConfig loadConfigFromDatabase($siteCode); $redis-setex($cacheKey, 3600, json_encode($siteConfig)); }配置数据缓存1小时站点内容变更时主动清理缓存。这样大部分请求的站点配置读取都走内存性能提升非常明显。3.5 模板引擎封装技巧前台模板方面我不建议直接用原生PHP做模板拼接太容易出XSS问题。推荐使用Twig或Blade这类自带转义机制的模板引擎。以Twig为例安装和基本使用composer require twig/twig$loader new \Twig\Loader\FilesystemLoader(__DIR__ . /../templates/ . $templateName); $twig new \Twig\Environment($loader, [ cache __DIR__ . /../cache/twig/, ]); echo $twig-render(index.html.twig, [site_name $siteName, articles $articles]);这里的一个细节是FilesystemLoader的路径是动态拼接的每个站点对应自己的模板目录。模板文件名统一规划比如index.html.twig、about.html.twig、list.html.twig这样每个站点只需要创建对应的模板文件就能保持页面风格的一致性。4. 常见问题与运维要点4.1 高频故障排查速查表在实际运维这套系统的过程中我整理了一些高频问题记录成一张表遇到类似问题直接按表排查。现象可能原因排查/解决方式访问子域名打不开泛解析记录未生效检查DNS解析执行dig yourdomain.com查看结果所有子域名都显示同一个站点路由代码未生效检查PHP路由层代码是否命中site_code匹配逻辑子域名访问404Nginx server_name未配泛解析检查server_name中是否包含*.yourdomain.com页面样式全丢模板中的资源URL写死为绝对地址模板中静态资源建议用相对路径或通配符域名缓存未更新内容改了不变Redis缓存未清理后台操作内容时自动调用clearSiteCache($siteId)某个站点访问特别慢该站点数据量大SQL查询没走索引检查articles表的site_id索引是否存在4.2 性能优化与安全加固MySQL连接池问题。PHP-FPM模式下每个PHP进程都会维护自己的数据库连接。站点数量多时MySQL的最大连接数很容易被打满。解决方法有两个一是调大MySQL的max_connections二是在PHP-FPM配置中限制pm.max_children。但更根本的方案是引入代理中间件如ProxySQL或者用PHP的持久连接pconnect不过持久连接需要谨慎使用否则会因为状态残留引发奇怪问题。Redis缓存策略。除了站点配置缓存内容列表也可以做缓存。像首页的文章列表完全可以缓存10分钟$listKey site_articles: . $siteId . :page: . $page; $html $redis-get($listKey); if (!$html) { $html renderArticleList($siteId, $page); $redis-setex($listKey, 600, $html); }安全加固。泛域名站群这类公开项目很容易成为扫描目标。几条基本防护必须做到位后台路径改名不使用默认的/admin对所有用户输入做参数绑定查询防SQL注入上传目录禁止执行PHP脚本在Nginx里单独配置启用open_basedir限制PHP只能访问指定项目目录定期更新PHP版本PHP 5.x和7.0以下版本不要再用了漏洞太多。4.3 从单机到集群的演进思路如果你的站群规模持续扩大单台服务器的资源必然成为瓶颈。演进路径一般是这样单机时代全套服务部署在一台云主机上Nginx PHP MySQL Redis全在一台机器适合几十个站点、日均几千访问的规模。数据库与应用分离把MySQL和Redis迁移到独立服务器PHP应用服务器可以横向扩容前面挂一台Nginx做负载均衡。这个阶段可以扛住日均几十万访问量。全面微服务化把模板渲染、内容管理、用户系统拆分成独立服务通过API通信。这一步成本投入较大一般站点量级到不了这一步。我个人建议不要把架构想得太复杂。大部分泛域名站群项目的瓶颈从来不在架构而在内容生产效率和管理流程。架构简单、容易维护、稳定可靠才是这套系统的第一要务。根据我自己的实操体会泛域名站群这套方案最值钱的地方在于“复用”——一套代码撑起所有站点新增站点不用从零开始日常维护也集中在一个后台里完成。如果你正要接手这类系统建议先把路由层和缓存层吃透这两部分是整个项目的骨架骨架稳了后面的功能随便加。本文还有配套的精品资源点击获取