
简介这是一套面向域名服务从业者与Web系统开发者的二级域名分发管理系统源码适用于需统一管理多平台DNS解析、订单支付及用户权限的中小团队或SaaS服务商。资源包含完整可部署的迅风DNS Pro V3.1.2系统支持阿里云、Cloudflare等十余家主流DNS服务商插件化接入覆盖解析管理、工单系统、实名认证、违规检测、多主题界面等核心功能模块。压缩包共2000个文件主体为1257个PHP后端逻辑文件、269个JS交互脚本、116个CSS样式文件及85个Markdown文档含搭建教程与配置说明辅以SQL数据库结构、YML配置、环境变量与License等配套文件总大小11.26MB。目前已有198人学习下载提供开箱即用的目录结构、清晰的模块划分如tree-select、el-table-column等组件化命名体现Element UI深度集成、完整的日志审计与权限分级体系便于二次开发与生产环境快速落地。1. 这套二级域名分发系统到底解决什么问题——先看使用场景和底层逻辑先说个场景。我自己维护过一个面向会员提供免费二级域名的服务平台最初用的是最原始的方式用户在表单里提交想要的子域名前缀我收到申请后登录DNS服务商后台手动添加一条解析记录再把结果反馈给对方。前几十个还好一旦用户量起来一天几十上百条申请手工操作根本扛不住漏加、错加、重复加各种问题接踵而至光是核对谁申请了什么域名就能耗掉半天。那会儿市面上确实有现成的二级域名分发系统但要么收费太高要么代码老旧、界面停留在十年前更麻烦的是很多系统绑定特定面板或特定DNS服务商想换一家接口就要动源码。直到我拿到“迅风DNS Pro V3.1.2”这套源码把整个流程跑通之后才发现原来这类系统的核心逻辑并不复杂关键在于它把“用户提交申请—系统校验—自动调API添加解析—返回可用域名”这条链路做得足够顺滑。这套系统说到底解决的是三件事让最终用户能自助申请二级域名、让管理员能用一套后台管理所有域名和套餐规则、让域名解析的整个流程自动化掉。简单说它就是一个把你的主域名“发牌”给用户的自动化分发中心。适用对象也很清晰做免费空间、博客平台、个人导航站、短链接服务、临时测试环境分配或者任何需要频繁给用户开子域名的业务。你现在做的项目如果也在这类场景里那这套源码的价值就不只是省下手工操作的力气而是把整个分配过程变成了可配置、可追溯、可限制的产品化功能。系统底层的工作流程大致是这样管理员在后台添加主域名配置泛解析或授权API用户在前端提交想要的前缀系统校验前缀是否可用、是否包含敏感词、是否符合长度规则接着调用DNS服务商的开放接口自动创建一条解析记录指向你设定的目标地址最后把分配结果和解析状态回写到数据库用户在前台能看到自己的域名和生效状态。整个过程绕开了人工操作也绕开了容易出错的各种中间环节。这一版V3.1.2相比旧版主要改动集中在域名对接方式的灵活性和后台套餐管理的细化程度上。新版本里你可以为不同的会员等级配置不同的子域名后缀、不同的解析目标、不同的每日申请上限这些都是在后台可视化配置的不需要动一行代码。对运营者来说这意味着“卖点”可以做成不同的套餐包而不是所有用户挤在同一条分配规则里。2. 搭建之前必须想清楚的三件事——域名方案、服务器环境和DNS服务商选择这套系统听起来是“装上就能用”但真正部署之前有几件事如果没想清楚后面会反复返工。我先把这三个最核心的决策点讲透。2.1 主域名用什么接入方式泛解析还是API自动添加这是决定整套系统工作模式的分水岭。第一种方式是泛域名解析也就是在主域名下配置一条 *.yourdomain.com 的解析记录把所有不存在的子域名统一切到一台服务器上然后由系统在收到请求时按前缀逻辑做判断。这种方式的优势是配置简单、解析生效快缺点是所有子域名都指向同一个目标如果想给不同套餐分配不同服务器就得靠系统层做转发或代理灵活性受限。第二种方式是由系统调用DNS服务商的API按需创建真正的解析记录。比如用户申请了 blog.example.com系统自动去你的DNS服务商后台创建一条 A 记录或 CNAME 记录指向指定目标。这种方式每个子域名都是独立的解析记录能做到真正的差异化分配但前提是你用的DNS服务商必须提供开放API并且你在系统里要配置好API密钥。迅风DNS Pro V3.1.2对这两种模式都支持不过我强烈建议有条件的话优先走API模式。泛解析虽然省事但很多情况下会导致“用户申请了一个未配置的域名也能访问”的尴尬局面因为泛解析本身就涵盖了所有子域名你很难在DNS层面区分哪些是合法分配出去的、哪些是用户随手试出来的。API按需添加就没有这个问题解析记录可控、可查、可删和业务数据能一一对应。2.2 服务器环境别在版本上踩坑搭建教程里通常会写“PHP 7.x MySQL 5.7 Nginx”但我实测下来这套V3.1.2对环境的要求有几个容易忽略的细节。第一个是PHP版本。源码在PHP 7.4下运行最稳定8.0以上部分老扩展可能报兼容性警告尤其是某些加密组件或缓存扩展。如果你用的面板默认装了PHP 8.1建议优先切换回7.4避免在排查问题上浪费时间而不是在上线之后跟警告信息干瞪眼。第二个是必须开启的PHP扩展。Fileinfo、OpenSSL、PDO、Curl、Mbstring 这几项缺一不可。特别是Curl它承担了所有与DNS服务商API通信的任务如果没装好后台配置API密钥时测试连接会一直失败而且报错信息很笼统让你以为是密钥写错了实际是扩展缺失。第三个是伪静态配置。系统前台页面依赖伪静态路由来生成友好URLNginx下需要在站点配置里追加一段规则Apache下则要开启 mod_rewrite。源码包里带了对应的伪静态规则文件搭建时直接复制到站点配置里就行但很多人会漏掉这一步导致前台页面全部404。后面我会把完整的Nginx配置贴出来直接抄就行。2.3 DNS服务商API选哪家接口稳定性和权限范围系统内置了几个主流DNS服务商的API适配包括阿里云DNS、腾讯云DNSPod以及最常见的Cloudflare。选择哪家主要看你的域名注册在哪、你对权限的容忍度有多高。阿里云和DNSPod用AccessKey授权但要注意密钥权限范围。给这套系统使用的密钥建议只授权DNS解析管理权限不要用主账号密钥更不要用一个拥有所有产品权限的密钥。原因是这个密钥要被写在站点的配置文件里一旦站点出现代码漏洞攻击者拿到高权限密钥就等于拿到了你整个云账号的控制权风险很大。Cloudflare的API Token则更灵活你可以创建一个只允许编辑指定Zone即指定域名的受限Token这样即便泄露影响范围也控制在一个域名之内。这是我最推荐的做法安全边界清晰得多。另外还需要考虑到DNS服务商的接口响应速度和解析生效时间。有的服务商接口调用后解析记录秒级生效有的则需要几秒到几十秒的传播时间。迅风DNS Pro后台有“解析状态检查”功能它通过模拟查询来判断域名是否已经生效但你心里要有数——如果服务商那边普遍有延迟前端用户看到“等待生效”的状态就属于正常表现不代表系统出故障了。3. 从零部署V3.1.2完整安装步骤与关键配置说明我假设你已经有一台Linux服务器装了宝塔面板或同类管理面板并且已经把你的主域名解析到了这台服务器的IP上。如果你连这一步都还没做先去把域名和服务器准备好回头再看这一段。3.1 源码上传与目录权限设置把下载好的源码包解压后你会看到主要的程序文件、安装向导目录、以及若干个文档文件。将整个目录上传到站点根目录比如 /www/wwwroot/dns.example.com/。上传完成后先别急着打开安装页面先把运行目录的写权限做好。多数这类系统运行过程中需要写入缓存文件、日志文件以及上传目录所以 storage 或 runtime 这类目录权限要设置为755或775属主改成www用户。如果你用的是宝塔直接在文件管理器里右键设置权限即可注意“应用到子目录”选项要勾上。然后创建站点数据库。在面板里新建一个MySQL数据库数据库名和用户名随意但密码务必用高强度随机密码安装向导里会用到。我见过很多人图省事设了个123456结果站点上线没几天数据库就被扫了这种低级错误別犯。3.2 安装向导一步步说清楚每项填什么浏览器访问你的站点域名系统会自动跳转到安装向导页面。整个过程大概三四步每步要填的信息我逐个说明。第一步是环境检测。页面会把需要的PHP版本、扩展、目录权限状态列成一排有问题的项会用红叉标出来。如果这里出现红叉对照上一节的内容去面板里开启对应扩展全都变绿再点下一步不要强行跳过。第二步是填写数据库信息。把刚才创建的数据库名、用户名、密码填进去数据库主机一般填127.0.0.1或localhost均可端口默认3306。这里有个坑如果你的面板为数据库单独设置了访问端口比如3307一定要在主机或端口字段里一并写清楚否则会提示数据库连接失败。第三步是配置管理员账号。这个账号是后台登录用的超级管理员用户名建议别用admin这种默认值换成不好猜的组合密码至少大小写字母加数字加符号长度不低于12位。后台登录入口文件路径在安装完成后也可以改教程里有说明我会在后面单独讲加固措施。第四步是填写站点基础信息。包括站点名称、SEO关键字、以及最重要的——主域名绑定。这里的主域名指的是你要用来分发二级域名的那个根域名比如 example.com而不是你安装系统的那个域名。两个域名可以是同一个也可以不同具体看你的业务设计。安装完成后安装向导目录会自动锁定或提示你手动删除。无论提示与否都去服务器上把 install 目录整个删掉这是最基本的安全习惯防止他人通过安装脚本重置你的站点。3.3 品牌配置与邮件通知上线前先调好的两处细节安装完先别急着去添加域名和套餐先把后台的基础配置过一遍。第一个是网站名称、Logo、备案号这类品牌信息它们会展示在前台页面和邮件模板里。第二个是SMTP邮件服务配置。邮件通知在二级域名分发场景里特别重要。用户的域名开通成功、即将到期、解析失败系统都会发邮件通知。如果SMTP没配好这些通知全部发不出去用户只能干等着刷新页面看状态体验很差。SMTP配置时注意填写正确的发件人地址尽量和你的域名保持一致。比如你用的是 example.com 的域名发件人最好是 no-replyexample.com这样投递成功率会高很多。很多服务器自带的mail函数发信经常被收件方列为垃圾邮件有条件的话建议直接用QQ邮箱、163邮箱或阿里云邮件推送的SMTP服务。4. 核心功能实操添加主域名、配置DNS接口、设计分发套餐安装向导走完系统能登录后台了接下来才进入真正的业务配置阶段。这一步做得好不好直接决定你后续运营时省不省心。我会按后台的菜单顺序一步步演示。4.1 接入主域名先在DNS服务商那边做好准备工作点击后台左侧“域名管理”—“添加域名”填入你要分发的主域名。这时候系统会要求你选择DNS服务商类型并填写对应的API密钥信息。以阿里云DNS为例你需要先去阿里云控制台的RAM访问控制里创建一个用户赋予AliyunDNSFullAccess权限然后生成AccessKey ID和Secret。把这两个值填到系统的对应字段里。填完之后点击“测试连接”系统会调用一次查询解析列表的接口来验证密钥是否有效。测试通过后保存再点击“同步域名”按钮系统会把该账号下所有可管理的域名拉取过来你要确保列表里能看到你的主域名。如果看不到大概率是RAM权限范围设置错了回去检查权限绑定。DNSPod的流程类似在dnspod.cn控制台创建API Token密钥形式是一串ID加一串Token。Cloudflare则是在My Profile → API Tokens里创建权限选择Zone → DNS → EditZone Resources限制为你要分发的那个域名。接入成功后建议在主域名下先手动添加一条解析记录测试确认服务商的API链路是通的。比如添加一个 test.example.com 的A记录指向你的服务器IP等生效后删掉。这一步能够把“API密钥配置问题”和“系统自身问题”区分开后续排查时会省力很多。4.2 套餐规则设计把“给谁发、发什么、发多少”变成可配置项迅风DNS Pro V3.1.2的核心亮点是“分发套餐”功能。你可以在后台创建多套分发规则每套规则可以独立配置以下参数允许申请的二级域名后缀比如统一使用 *.example.com还是允许用户自选前缀解析记录类型A记录还是CNAME记录解析目标地址可以是固定的服务器IP也可以是固定域名可申请的前缀长度范围比如最少4位、最多20位前缀允许的字符集默认是字母、数字、中划线但禁止中划线开头或结尾每日申请数量上限以及用户总保有数量上限域名保留时长比如30天、90天、永久是否允许用户删除已申请的域名我举个真实业务的配置例子。假设你在做一个给开发者用的免费测试环境平台提供 *.dev.example.com 的二级域名所有解析都指向你的一台测试服务器。可以建一个“免费套餐”每天限申请5个总保有量限20个前缀长度最少6位解析类型选A记录目标IP填测试服务器的IP保留时长30天。当用户用满20个还想申请时系统会提示清理不用的域名形成一个良性的循环也避免了资源被无限消耗。再建一个“VIP套餐”把每个用户的总保有量提高到100个保留时长改为365天同时允许自定义解析目标。这样免费用户和付费用户的差异就很明显了运营上也有了做转化的抓手。每个套餐创建完成后还可以设置关联的用户分组。系统内置了用户管理功能你可以手动添加用户也可以开放前台注册。前台的注册页在安装后默认开启注册时可以选择申请哪个等级的套餐。4.3 前端申请流程实测从提交前缀到解析生效的完整链路配置完套餐之后我用真实验证跑了一遍完整流程这里把用户视角的操作过程也同步给你方便你自查。用户注册登录后进入“申请域名”页面输入想要的前缀比如想要 myblog系统会实时校验这个前缀是否可用。判断逻辑包括前缀是否已被分配、是否在系统黑名单里、是否包含敏感词、是否符合当前套餐的字符和长度规则。校验通过后点击提交系统返回“申请成功解析正在配置中”的提示。通过数据库查询可以看到这条域名记录的状态是“pending”等待解析。系统会在后台触发一次异步任务调用DNS服务商API创建一条 myblog.example.com 的A记录。任务执行完成后记录状态更新为“active”用户的前台页面同步显示“已生效”。从提交到生效的时间取决于DNS服务商的接口响应时间。我自己测试的时候DNSPod大概在几秒内完成阿里云也基本在10秒以内。如果超过两分钟状态还是pending就需要去后台查看任务日志了。系统后台的“任务列表”页面会记录每一次API调用的请求参数和返回结果这个功能在排查问题的时候简直救命。4.4 解析状态自动检测与失败重试机制遇到API调用失败的情况不要慌系统内置了重试机制。默认每个域名最多重试3次每次间隔5分钟。3次都失败的话记录状态会标记为“failed”同时系统会发邮件通知管理员和用户。我在实际运营中遇到过一种情况用户在前台提交申请时系统校验说“前缀可用”但提交后API创建记录时却提示“记录已存在”。这是因为DNS服务商那边已经存在一条手工添加的同名记录而系统本地数据库里没有同步到。解决办法是在系统的“同步解析记录”功能里手动触发一次从DNS服务商拉取全量解析记录的同步操作把云端已有的记录导入本地之后就不会再出现这种冲突了。5. 部署和运营中反复出现的几个坑——我的排查与修复过程任何一个开源或商业源码系统都不可能完全规避环境差异带来的问题。下面这几个坑是我在部署和使用V3.1.2的过程中真实遇到的我把完整排查链路写出来你遇到类似问题时可以照着排查。5.1 解析记录一直在“配置中”到底卡在哪一步第一次用这套系统时我提交了一个测试域名结果等到五分钟状态还是“配置中”没有变成“active”。当时的处理过程先看后台“任务列表”发现任务状态是“等待执行”。这意味着任务没有被消费问题不在DNS服务商而在系统内部。接着查看系统的队列或定时任务配置。这类系统通常用宝塔面板的“计划任务”功能来触发任务消费需要在面板里添加一条每分钟执行一次的Shell脚本内容指向源码里的artisan调度文件。安装教程里其实写了这一条但我当时粗心漏掉了。添加计划任务后再次提交域名状态在几十秒内正常变为“active”。所以如果你遇到同样的情况第一时间去检查计划任务是否已配置成功。如果计划任务没问题再去看PHP-FPM日志和系统日志定位是不是调用API接口时超时或报错。5.2 域名前缀明明没有被占用系统却提示“已存在”这个问题比较隐蔽根源在数据库的字符集排序规则上。当时我用的MySQL库默认排序规则是 utf8mb4_unicode_ci它把大小写字母视为相同这个没问题但同时它把一些字符也视为相等恰好影响到了部分拼音或英文场景下的判断。举个例子系统里已经存在 users 这个域名当新用户申请 Users 时被拦截是合理的但用户申请 user-s 时也被提示“已存在”就说明判断逻辑出现了意外匹配。排查后确认是系统查询语句里使用了 LIKE 匹配来比较前缀是否已存在而排序规则影响到了比较结果。解决办法是把数据表的排序规则从 utf8mb4_unicode_ci 改为 utf8mb4_general_ci或者升级到更新的 utf8mb4_0900_ai_ci问题就消失了。如果你在线上已经遇到了同样的情况直接把对应表的排序规则改掉再重新测试即可。5.3 前台页面能打开但所有内部链接全部404这个基本可以断定是伪静态没配置好。Nginx环境下仅开启伪静态开关还不够站点配置文件里必须加载系统自带的 rewrite 规则。下面是我在Nginx里实际使用的一段配置你可以直接拷贝到站点配置文件的 server 块内location / { try_files $uri $uri/ /index.php?$query_string; } location ~ \.php$ { fastcgi_split_path_info ^(.\.php)(/.)$; fastcgi_pass unix:/tmp/php-cgi-74.sock; fastcgi_index index.php; include fastcgi_params; fastcgi_param PATH_INFO $fastcgi_path_info; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; }注意 fastcgi_pass 的 socket 路径要根据你实际使用的PHP版本调整。如果你用的是宝塔默认的PHP 7.4 socket路径就是 /tmp/php-cgi-74.sock装了多版本PHP的话别搞混了。Apache环境下则要确保 .htaccess 文件没有被禁用并且 AllowOverride All 已配置。5.4 系统后台突然无法登录或登录后报错这类问题多半是会话文件目录权限或缓存文件异常导致的。我遇到过一次后台登录后直接白屏的情况查日志发现是 storage/logs 目录已满导致日志写入失败进一步拖垮了会话处理。解决办法是先清理 runtime 和 storage 下的缓存文件再把目录权限重新设置为755最后重启PHP服务。下次如果还有人遇到类似情况别急着重新安装系统先看日志文件是不是异常膨胀了。6. 二次开发从哪里入手看懂关键代码结构与可扩展的功能点如果你只是拿来跑业务第五章结束就可以直接上线了。但如果你对这套系统有更长远的规划比如要根据自己的业务逻辑做深度定制那我会建议先花一点时间搞懂它的代码组织方式而不是东改一行西改一处。V3.1.2虽然是商业源码但整体结构还算清晰下面是我梳理出的几个切入点。6.1 核心模块分布路由、控制器、服务层与队列任务这套系统采用了类似MVC的分层结构。前台请求通过路由分发到对应的控制器控制器里的核心逻辑放在了服务层数据操作则封装在模型层。其中和域名分发强相关的代码集中在几个关键文件里域名申请控制器负责接收前台提交的前缀、校验、生成域名记录DNS适配器目录每种DNS服务商的API对接都做成了一个独立的适配器类队列任务类负责异步创建解析记录、检测解析状态、发送邮件通知如果你想增加一个新的DNS服务商适配方法很简单参照已有的适配器类实现同样的接口然后在配置文件里注册新的服务商名称即可。整个过程不需要修改其他模块的代码这也是我比较满意的地方扩展性比大多数同类源码都好。6.2 可以扩展的实用功能方向基于这套系统的现有架构有几个功能方向是你能比较轻松加进去的。第一个是域名到期自动回收。V3.1.2本身有保留时长的设置但定时任务里并没有内置“到期自动删除”的逻辑。你可以在现有计划任务基础上新增一个每日执行的任务脚本查询所有超过保留时间且未被续期的域名调用DNS API删除对应解析记录同时更新本地域名状态为“已回收”。这在免费服务场景里完全是刚需不回收的话资源会被占用殆尽。第二个是API开放接口。如果你想把这套系统做成开放平台比如让第三方应用通过API申请和释放二级域名可以在现有控制器基础上增加一组token鉴权的API路由。每次申请前校验调用方的token、套餐余额、域名配额复用现有的服务层逻辑即可开发量很小。第三个是自定义解析目标的管理。目前后台的解析目标是在套餐里固定的如果你想实现更灵活的“用户可自定义解析目标”前端加一个输入框后端增加一步校验目标IP或域名格式是否合法然后把目标值传给队列任务去创建解析记录就能实现。6.3 修改代码时需要注意的两个安全细节第一个任何用户可输入的内容域名前缀、解析目标、备注都要做合法性校验尤其要确认前缀里不能包含点号、斜杠、下划线以外的特殊字符避免构造出类似 api.example.com.evil.com 这类混淆值或注入内容。系统本身做了基础过滤但二次开发时你自己加的功能接口一定不能漏。第二个日志文件里会记录完整的API请求参数包括密钥信息吗取决于开发者写日志时是否做了脱敏处理。如果你在调试过程中发现某些服务商适配器把整个密钥拼到了日志里务必在下线前把日志清理掉并调整代码只记录密钥后四位即可。这是安全问题不是洁癖问题。7. 上线前最后的加固清单——都是拿真金白银换来的经验很多人以为部署完成、能正常申请域名就算大功告成了但线上环境远比本地复杂我在这里最后分享一份自己沉淀下来的上线前检查清单每一条都在实际运营中出过事。后台入口和默认密码必须改。安装完成后默认的登录入口是 admin.php 或类似路径教程里通常建议你改成一个随机名称。这是最基本的安全要求不要因为图省事就跳过。管理员密码也务必是强密码并且开启登录验证码。本站后台如果支持二步验证建议直接开启。API密钥权限最小化。前面提到过给系统的密钥只授权DNS解析管理的权限。如果你用的是云服务商的主账号AccessKey一旦泄露后果不亚于服务器被攻破。阿里云RAM用户和Cloudflare受限Token都是成熟方案务必用起来。定期备份数据库。这个系统运行过程中产生的核心数据是域名分配记录、用户数据、任务状态。域名分配记录一旦丢失线上所有已分配的二级域名将变成无人认领的孤儿状态用户那边会立刻出问题。宝塔面板有定时备份功能建议至少每天备份一次并保留最近7天的备份。关注DNS服务商侧的配额和频率限制。不同DNS服务商的API调用频率限制差异很大有的服务商单账号每分钟请求次数上限非常低。如果你的业务量大单次申请批处理或任务重试时可能触发限流导致大量任务失败。建议在系统里把任务队列的并发数调低或在DNS适配器代码里增加一个简单的限速逻辑。前台隐私政策和使用条款别跳过。既然系统面向用户提供二级域名分发你就需要明确写出服务条款比如禁止将域名用于违法违规用途、系统有权回收违规域名等内容。这不只是法律层面的问题也是后续处理纠纷时的重要依据。模板可以自己写但一定要包含免责条款和回收规则。我在实际运营这套系统的过程中最深的体会是这类DNS分发系统的价值不在于它替换了多少手动操作而在于它让“域名资源”真正变成了一种可量化、可管理、可运营的资产。每一个域名从分配到回收都有迹可循每一个套餐的消耗情况都能实时掌握这些能力才是支撑业务长期跑下去的关键。如果你正准备上线一套二级域名分发服务建议你按照本文的步骤先把基础跑通然后从最刚需的扩展功能开始入手。遇到环境兼容性问题时优先检查PHP版本、扩展、伪静态和计划任务这几项八成以上的问题都能从这里找到答案。等系统稳定运行一个月后你再回头看当初手工配解析的日子应该会和我一样有“为什么不早点用上”的感慨。本文还有配套的精品资源点击获取