简介2025二级域名分发系统商业版网站源码是一套面向企业级用户的远程域名管理解决方案覆盖二级域名解析、分发、租赁等核心能力能够大幅简化子域名创建、解析与授权流程适合IDC服务商、建站公司以及需要批量管理域名的技术团队使用。资源整体约51.17MB共包含2000个文件以1219个php程序文件为核心配套json配置、md说明文档、png图标、js脚本与css样式等分别支撑后端业务逻辑、参数配置、界面展示及交互功能目录结构清晰。目前已有542人学习/下载。源码内置完整教程和演示站点前台可体验用户注册、登录及域名管理操作后台admin账户支持模板配置、权限分配和系统监控便于二次开发与快速部署。值得强调的是商业版采用前后端分离架构附带sql数据库文件及nginx/php等环境配置既可直接用于搭建域名租赁服务平台也可作为企业级PHP项目架构的参考范例。1. 二级域名分发系统是什么商业版源码到底解决什么问题2025 年做多租户 SaaS最绕不开的事就是给每个用户一个独立子域。人工去 DNS 控制台一条条加解析几十个客户还能忍几百个就是灾难。二级域名分发系统也叫二级域名解析平台就是把「开通子域、解析生效、绑定用户空间」做成自动化闭环后台点一下甚至让用户自助完成。商业版网站源码是指一套可部署的代码包管理后台、接口层、数据库脚本、部署配置都在里面域名和用户数据完全自己掌控。它的核心价值一句话开通从小时级变秒级所有子域统一入口做流量调度和管控。自己运营 SaaS、给客户开多租户站点、或者想把这套能力嵌进现有系统的开发者这篇就是给你写的。下面把原理拆开再用 Nginx 跑通最小分发链路最后把商业版源码部署时的高频坑一次说透。2. 分发链路拆解通配符 DNS 与动态路由为什么是这套系统的地基2.1 通配符解析一条 A 记录如何撑起所有子域二级域名分发系统最核心的地基是 DNS 的通配符记录。原理上只需要一条*.example.com的 A 记录指向入口服务器例如example.com. 600 IN A 203.0.113.10 *.example.com. 600 IN A 203.0.113.10当用户访问user1.example.com时递归服务器会到平台的权威 NS 查询权威 NS 找不到精确的user1记录就回退匹配*.example.com返回同一个 IP。这意味着无论开通多少个二级子域在 DNS 这一层都只占一条记录入口 IP 也只有一个真正的分流由应用层决定。这也是这套系统能支撑成百上千个子域而不需要反复改解析的根本原因。这里有两个容易理解偏的地方。第一通配符只匹配一层a.b.example.com不会命中*.example.com所以成熟的商业版都约定「只分发单层子域」想要多级子域就得自己另写规则。第二*.example.com和example.com本身是两条独立记录裸域名不会匹配通配符需要单独配一个 server_name 处理别指望泛解析能顺带覆盖。TTL 的设置直接影响开通报障的速度。有些平台为了省事把 TTL 设成 86400结果用户开通后小半天访问不通还以为是系统坏了其实是递归缓存没过期。我一般会把分发主域的 TTL 压到 600 秒既不会给权威 NS 造成明显压力也能保证最长 10 分钟全局生效。另外托管商对泛解析的支持有差异个别面板把*当非法字符需要提前确认否则后面所有子域都解析失败。2.2 动态虚拟主机把 Host 头变成路由键流量都汇聚到入口 IP 之后入口要回答第二个问题同一个 IP 上来了几百个不同 Host怎么知道每个请求属于哪个租户答案是把 Host 头当路由键在转发层动态查表找到真实后端再转过去。常见做法有三种。方案 A每个子域生成一段 server_name 配置再 reload Nginx。小规模没问题几十个用户还能忍一旦上百每次开通都触发 reload高峰期频繁重启 worker连接瞬间掉一批这是最容易翻车的实现。方案 BNginx LuaOpenResty在 access 阶段查 Redis 或共享内存把 Host 映射成租户 ID再传给后端全程不 reload。商业版源码里我见过的大多数走这条路因为它实时性好子域上下线只影响一次缓存读写不碰 worker 进程。方案 C用 Traefik 或 APISIX 这类云原生网关做动态路由。适合 K8s 环境规则通过标签或 API 下发同样不 reload但对单机部署来说太重杀鸡用牛刀。三个方案的取舍用对比表说清楚方案子域生效方式并发扩展性上手成本适合规模生成配置 reload改文件后 reload差reload 有毛刺最低50 个以内OpenResty Redis写缓存即生效好Lua 开销小中数百到数万网关动态路由配置下发好但组件重较高K8s / 大规模我基本都给这套分发系统定方案 B。理由很实际分发的本质就是「数据库里多一条记录 缓存里多一个键值」Nginx 只做查表转发。这个结构好排查缓存里有键就通没键就 404不会出现「配置到底 reload 没 reload」的玄学问题。后端拿到的租户标识建议放在自定义请求头里比如X-Tenant-Id业务代码不信任 Host 头本身只信这个由入口层写入的字段后续做租户隔离也以它为基准。3. 用 Nginx 跑通最小分发链路从一条 DNS 记录到首次派发3.1 通配符 DNS 与动态 vhost 的最小配置先做 DNS 前置准备在域名托管商的解析面板里把*.example.com解析到入口服务器 IPTTL 填 600。接着是入口配置。既然是「最小且可扩展」我建议直接采用带 Lua 的写法把查表逻辑单独拆出来lua_shared_dict tenant_cache 10m; server { listen 80; server_name ~^(?sub[a-z0-9-])\.example\.com$; access_by_lua_block { local key tenant: .. ngx.var.sub local t ngx.shared.tenant_cache:get(key) if not t then local red redis:new() red:set_timeout(500) local ok, err red:connect(127.0.0.1, 6379) if not ok then return ngx.exit(502) end t red:get(key) or red:set_keepalive(10000, 100) ngx.shared.tenant_cache:set(key, t, 60) end if t then return ngx.exit(404) end ngx.var.tenant_id t } location / { proxy_pass http://app_backend; proxy_set_header Host $host; proxy_set_header X-Tenant-Id $tenant_id; } }这段配置的逻辑是先用正则 server_name 把子域前缀sub抓出来在 access 阶段先查共享内存命中直接用没命中才回源 Redis并写回共享内存避免每个请求都打一次 Redis。查不到租户时返回 404而不是落到某个默认后端这一点是安全底线后面避坑章会展开说。参数上有几个细节。lua_shared_dict 10m大概能存几万个租户键值规模不大不用调。Redis 连接超时设 500ms连不上直接 502宁可失败不要排队。red:set_keepalive(10000, 100)让 worker 复用连接池100 个连接足够撑住几千 QPS 的查询。共享内存里的值设了 60 秒本地过期既有缓存收益又不会让下线和删除的操作延迟太久。注意新增配置前先执行nginx -t再 reload正则server_name写错位置会直接导致整个站点 404。3.2 管理端的分发接口绑定、校验与生效入口只是执行层真正决定「谁能拿到哪个子域」的是管理后台。先看数据表这是分发系统的核心表CREATE TABLE tenant_domain ( id INT UNSIGNED NOT NULL AUTO_INCREMENT, tenant_id INT UNSIGNED NOT NULL COMMENT 租户ID, subdomain VARCHAR(63) NOT NULL COMMENT 二级子域前缀, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待生效 1生效 2停用, created_at DATETIME NOT NULL, PRIMARY KEY (id), UNIQUE KEY uk_subdomain (subdomain) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;subdomain加唯一索引这一条就能挡掉「两个租户抢同一个名字」的并发竞争比应用层先查再插可靠得多。状态字段预留三个值方便做自助开通审核流先落库待生效管理员确认后改成生效并写缓存。对应地开通接口的核心逻辑可以写成这样app.post(/api/v1/domain/bind) def bind_domain(tenant_id: int, subdomain: str): # 只允许小写字母、数字和连字符且为单层前缀 if not re.fullmatch(r[a-z0-9]([a-z0-9-]{0,61}[a-z0-9])?, subdomain): return {code: 400, msg: subdomain 格式不合法} if cache.get(tenant: subdomain): return {code: 409, msg: 该子域已被占用} db.execute( INSERT INTO tenant_domain(tenant_id, subdomain, status) VALUES(%s, %s, 1) ON DUPLICATE KEY UPDATE idid, (tenant_id, subdomain), ) cache.set(tenant: subdomain, str(tenant_id), ex600) return {code: 0, access_url: fhttp://{subdomain}.example.com, ttl: 600}这段代码做了三件事正则校验拦截掉带下划线、大写字母或超长前缀的非法名字用 Redis 键加数据库唯一索引双重防抢占写入后立刻推缓存下一毫秒入口就能路由。ON DUPLICATE KEY UPDATE idid是常见的「拿唯一索引当锁」写法并发重复插入不会报错只会在冲突分支返回占用提示。很多商业版在这里还会加一层可用性探测开通后主动访问一下新域名的首页状态码不是 2xx 就自动把状态回滚成待生效。这个功能很实用能第一时间发现后端配置没跟上导致的「开通了但打不开」问题。3.3 商业版源码里值得照抄的目录划分与关键参数表拿到一套商业版源码先别急着装花十分钟把目录结构过一遍。不同产品布局大同小异基本是这套套路目录/文件作用部署时要做的处理install/安装向导部署完成后删掉或改名config/数据库、主域名、缓存配置逐项改成本机值app/控制器与业务逻辑不要随便改动public/Web 入口Nginx root 指向这里只暴露这一层sql/初始化脚本导入一次即可商业版的价值主要体现在配置和接口层其中和分发行为强相关的参数就这几个参数建议值说明分发主域名example.com必须与通配符 DNS 一致默认解析目标入口服务器 IP后端迁移时只改这里记录 TTL600 秒改短保证开通及时生效缓存驱动与时长Redis / 600 秒与入口查表共用同一套键绑定接口限流每个 IP 60 次/分钟防脚本抢注管理端会话有效期2 小时缩短误操作窗口我见过不少团队把这几个参数散在代码里硬编码换个域名要全局搜索替换非常痛苦。正规做法是把它们收口到配置文件部署脚本里做一次合法性检查主域名格式、IP 格式、TTL 范围任一不对就中止安装。这套习惯值得从第一天就坚持。4. 把商业版源码部署到生产环境体检、部署步骤与三个必调参数4.1 部署前的环境体检清单商业版源码形态主要有两种PHP 程序和编译型 Go 程序。PHP 版要确认扩展Go 版要确认 CPU 架构。曾有人把 x86_64 的二进制扔到 ARM 服务器上直接段错误这种低级错误在部署阶段出得最多。组件版本建议用途操作系统主流 64 位 Linux运行服务入口OpenResty / Nginx 1.20动态路由与 TLS 终结运行环境PHP 7.4 或 Go 1.20按源码类型二选一数据库MySQL 5.7 或 8.0租户与域名表缓存Redis 6路由表与限流证书工具acme.sh 或 certbot自动签发 HTTPS 证书PHP 版还有一个隐蔽门槛不少商业版用 ionCube 之类的组件加密了核心文件装了新版本 PHP 但缺对应扩展程序直接白屏。部署前先跑php -m看加密扩展在不在再跑php -l检查源码入口有没有语法错误避免上线前十分钟才发现跑不起来。4.2 从源码包到线上可用四步走拿到源码包之后流程我习惯固定成下面四条命令顺序不能乱# 第一步解压并最小化目录权限 unzip domain_dist_v2.zip -d /data/www/subdomain cd /data/www/subdomain chown -R www:www runtime upload install chmod -R 755 . # 第二步写配置并导入数据库 cp config/env.example.php config/env.php vim config/env.php # 改数据库、主域名、Redis mysql -uroot -p sql/init.sql # 第三步本地验证程序能起 php -l public/index.php curl -I http://127.0.0.1:8080/ # 预期返回 200 或跳转到安装页 # 第四步Nginx 指到 public 并 reload nginx -t nginx -s reload第一步值得多说两句不要对整个项目chmod -R 777这是源码部署最常见的坏习惯。可写目录只有runtime、upload这类运行期目录代码目录全部只读至少能挡掉一类「拿到写入权限后直接改启动脚本」的攻击。第二步里config/env.php是命门数据库账号、分发主域名、默认解析目标全在这里。改完主域名记得回托管商把通配符 A 记录一起改掉两边不一致时后台显示开通成功实际访问全是 404这是部署环节翻车频率最高的问题。第三步的curl -I必须在公网接入之前跑通。绑定接口依赖入口的 Host 识别本地访问和线上访问行为不完全一样但至少能确认程序进程、数据库连接、Redis 连接三件事全通。4.3 三个必调参数和调整逻辑第一个是 Redis 缓存 TTL。默认 600 秒适合大多数场景如果用户对「开通立刻能访问」有硬要求可以压到 120 秒代价是权威 NS 查询量和 Redis 读写量都会上升要同步把入口共享内存容量调大。反过来存量子域多、变更少调到 1800 秒也没问题。第二个是入口的连接参数。分发场景下所有租户共用同一个 upstream高并发时连接池不够worker 会频繁新建连接延迟和句柄数一起涨。我一般配worker_connections 10240;upstream 里keepalive 64;对几千个承租户的聚合流量足够。第三个是管理后台的安全参数。商业版默认的管理路径、默认管理员账号、默认密钥上线前必须全部改掉。把管理后台从/admin改成随机字符串路径API 加每 IP 每分钟 60 次的限流会话有效期压到 2 小时。这三件套做完被脚本批量扫描命中的概率会明显下降。5. 二级域名分发系统避坑指南DNS 缓存、证书覆盖与源码体检5.1 DNS 生效慢开通成功后为什么还是打不开现象后台显示子域已开通用户访问依然解析失败持续几十分钟到几小时。原因两种缓存叠加。先是平台主域 TTL 被设成几小时递归服务器缓存了旧的「查不到」结果再是用户本地运营商 DNS 又缓存一层。开通这套系统之前域名可能从未有过通配符记录递归侧对负结果的缓存有时比正常记录的 TTL 还长。解决平台分发的子域统一用 600 秒 TTL状态字段区分「已开通」和「解析生效中」开通后主动直查权威 NS确认 A 记录已返回再展示给用户托管商支持的话把负缓存 TTL 也调低。验证命令用dig ns1.example.com user1.example.com short绕开本地递归看到 IP 才算真生效。5.2 泛域名证书只覆盖一层一起上 HTTPS 就翻车现象用了*.example.com的通配符证书访问user1.example.com正常但访问更深一层的域名直接证书告警。有的平台页面能开接口却全部 http 跳转失败排查半天发现是证书链不匹配。原因通配符证书只能覆盖一层*.example.com只对单层子域有效。另一个常见场景是用户绑定了自己买的域名平台签发的泛证书完全不覆盖用户自有域名。解决产品边界锁死「只分发单层二级子域」入口就不支持多层对用户自定义域名走自动签发单域名证书用 DNS-01 方式验证所有权签发后按域名路由到对应证书。注意签发和路由有先后依赖得先让那个域名的请求能到达入口证书交付后才能正常出示这个顺序要写进部署文档不然每次续期都会吓一跳。5.3 Host 注入与租户越权默认落点是最危险的逻辑现象访问一个尚未开通的子域没有返回 404反而落到了系统里某个真实租户的首页或者一个默认的演示站敏感内容被意外暴露。原因动态路由的兜底写得太宽容。常见实现是查不到租户就转发到默认后端本意是给未开通用户一个提示页结果默认页和租户站用了同一个 upstreamHost 一换就串到了别人家。解决查不到租户一律 404不给默认落点后端根据X-Tenant-Id做二次隔离不信任 Host 头本身入口层把未匹配的请求返回 444 直接断开。另外绑定接口必须校验调用者身份防止脚本批量抢注别人已占用的前缀。这条规则宁可严不可松越权一旦发生不是修代码的问题是信任体系崩了的问题。5.4 商业版源码的隐藏后门体检现象上线后后台登录日志频繁出现陌生 IP 尝试记录数据库里多了不该存在的管理员账号服务器出现异常外连。原因来源不明的商业版源码里可能残留安装向导、调试接口、加密后门。加密文件没法逐行审但常见后门有规律install 目录未删、eval或base64_decode直接拼接请求参数、普通 PHP 文件里藏着下载器。解决部署前把能看的部分先扫一遍grep -rn -E eval\(|base64_decode\(|assert\(|system\( app/ public/ --include*.php | grep -v vendor然后把install/目录删掉后台路径改成随机串默认管理员账号和密钥全部换掉数据库里多余管理员直接清掉。上线后持续观察一周入口访问日志把非业务来源的 IP 段在网络层拉黑。这一步是商业版源码能不能省心的分水岭值得花半天做彻底。6. 进阶从二级域名分发升级到自定义域名绑定上线前必做的验证6.1 自定义域名绑定三步流程与验证命令分发系统做到后期客户不满足于user1.example.com这种子域想把自己买的域名带过来比如www.their-domain.com。流程其实可以复用现有框架客户在 DNS 面板把自有域名 CNAME 到平台分配的固定子域平台在自有域名下写入一段 TXT 记录做所有权校验校验通过后触发单域名证书签发再激活路由。CNAME 方案比 A 记录绑定更灵活后端换 IP 时客户侧不用动。前提是客户域名支持 CNAME且他愿意把子层级指过来而不是要求把主域也绑进来——主域涉及 MX 邮件记录一般不建议碰。上线前的验证我固定在三条命令内完成dig ns1.example.com user1.example.com short # 平台派发子域应返回入口 IP dig CNAME www.their-domain.com short # 客户自定义域应返回平台分配的 CNAME 目标 curl -I -H Host: user1.example.com http://127.0.0.1/ # 本地模拟线上 Host 路由直查权威 NS 绕开递归缓存确认解析真实生效CNAME 的返回值必须和管理后台分配的目标完全一致多个空格都不行最后的 curl 用 Host 头模拟线上访问验证路由表同步成功。HTTPS 验证再加一条openssl s_client -connect 127.0.0.1:443 -servername user1.example.com看证书链是否匹配。我自己的交付习惯是每次上线后用全新租户完整走一遍「开通 → 绑定 → 证书签发 → 访问」顺手把入口缓存清一次再验一遍整个过程不到三分钟却能覆盖整条链路最脆弱的每个环节。这套分发方案的复杂度在 DNS 和证书不在业务代码把这两处的验证做成肌肉记忆后面基本不会出大乱子。希望帮到你。本文还有配套的精品资源点击获取