1Panel申请ACME证书时卡在“DNS记录异常”上，坦白说这是用面板类工具配置HTTPS时遇到率最高的报错之一。很多朋友看到这个提示第一反应是“我域名解析明明没问题啊，网站都能打开”，结果反复重试还是一样失败。我早期也被这个问题折腾过好几个晚上，后来把整套逻辑捋清楚之后，发现这类报错其实就集中在几个固定的环节上，绝大部分都能在十分钟内定位。
这篇文章就围绕1Panel里ACME证书申请失败、提示DNS记录异常这件事，把背后的判断逻辑、排查顺序和可落地的修复方案完整拆一遍。内容基于我自己的实测和常见实践的补充，适合正在被这个报错卡住的人直接照着操作。
1. 先搞清楚ACME证书申请为什么会校验DNS记录
1.1 ACME验证域名的两种主流方式
ACME协议（也就是Let's Encrypt这类免费证书签发的底层协议）在颁发证书之前，需要证明“你确实拥有这个域名”。目前最常见的有两种验证方式：
- HTTP-01验证：证书申请方在服务器上的指定路径放一个token文件，CA服务器通过HTTP访问
http://你的域名/.well-known/acme-challenge/xxxx来确认文件存在。 - DNS-01验证：证书申请方在自己的DNS解析记录里添加一条指定的TXT记录，CA服务器通过DNS查询来确认这条TXT记录存在。
1Panel在申请证书时，会根据你在面板里的设置选择验证方式。当出现“DNS记录异常”提示时，说明走的几乎是DNS-01这条链路——也就是面板需要你到域名DNS管理后台手动添加(或通过API自动添加）一条TXT记录，然后CA服务器去公共DNS上查询这条记录。
这里有个非常核心的逻辑点：CA服务器查的不是你本机、不是你路由器里的DNS缓存，而是全球公共DNS服务器。你在域名商后台添加了解析记录，并不等于CA服务器马上就能查到。中间要经过解析生效、缓存更新等多个环节，任何一环出问题，都会直接表现为“DNS记录异常”。
1.2 为什么1Panel选择DNS验证但仍然失败
1Panel申请证书的流程大致是这样的：面板向ACME服务商发起申请 → ACME服务商要求验证域名所有权 → 面板把TXT记录信息展示给你(或通过DNS服务商的API自动写入） → ACME服务商去查询DNS → 查询结果和预期不匹配则报错。
失败的核心原因基本可以分成三类：第一类是记录真的没生效，比如刚添加记录不到几分钟就去申请；第二类是记录内容和格式不对，比如漏了双引号、填错了主机记录；第三类是验证服务器查询不到，比如你用的DNS解析服务商有故障或者存在解析分区。
这三种情况在1Panel的报错信息里往往都只显示一句概括性的“DNS记录异常”，并不会精确告诉你到底是哪一种。所以排查的关键不是盯着报错文字看，而是自己手动去验证TXT记录的“可见性”。
我建议所有遇到这个问题的朋友，先把目光从1Panel的报错弹窗上移开，转到域名DNS管理后台和命令行工具上。确认这几件事：记录是否添加成功、记录值是否完整无误、记录是否已经在公共DNS上能被查询到。通常情况下，问题就出在这三件事中的一件上。
2. 手动验证DNS记录的最快路径
2.1 使用dig命令验证TXT记录
当1Panel提示DNS记录异常时，最直接的验证方法是到一台独立的服务器(或者本地电脑）上执行dig命令查询TXT记录。注意，最好别在申请证书的同一台服务器上查询，因为某些极端情况下服务器本地的DNS缓存会把问题掩盖掉。
dig TXT _acme-challenge.yourdomain.com +short这条命令会返回当前TXT记录的文本内容。如果返回结果是一串以引号包裹的随机字符(通常是长字符串），那说明记录已经能在公共DNS上被查询到了。如果什么都不返回，或者返回NODATA，说明解析还没生效或记录根本没写对。
在Windows上没有dig命令，可以用nslookup替代：
nslookup -type=TXT _acme-challenge.yourdomain.com 8.8.8.8注意我把最后的DNS服务器指定为8.8.8.8，这是为了绕过本地DNS缓存，直接查询公共DNS。如果你用默认的本地DNS，可能会查到缓存中的旧结果，导致误判。
2.2 在线DNS查询工具辅助确认
除了命令行，在线DNS查询工具也非常实用。这类工具一般会同时查询多个地区的DNS服务器，能非常直观地看到TXT记录是否在全球范围内生效。操作时输入_acme-challenge.yourdomain.com，类型选TXT，查询即可。
这里有个使用技巧：如果某个地区的DNS节点能查到TXT记录，而另一个地区查不到，通常是记录还在传播中，多等几分钟就好。如果所有节点都查不到，那就是记录本身没有生效或者没有正确创建。
2.3 检查记录内容是否完全一致
很多朋友在复制粘贴TXT记录值时，会不小心把记录值弄丢一部分，或者多复制了一些空格。ACME验证是严格进行字符串匹配的，任何一个字符不对都会导致验证失败。
我的习惯是把1Panel界面展示的TXT记录值复制到一个纯文本编辑器里，然后和DNS管理后台添加的记录值进行逐字符比对。尤其注意这几点：记录值末尾是否有空格、是否有不可见的换行符、中间的横线和下划线是否齐全、是否有多余的引号。
之前帮一个朋友排查过一个问题，他添加TXT记录时不小心把记录值末尾的一个字符删掉了，表面上看起来几乎一样，但ACME服务器验证时就是不过。这种低级错误排查起来最花时间，因为它不会产生任何格式上的异常提示。
3. 从定位问题到解决问题的完整排查路径
3.1 排查链路全景图
整个ACME证书申请的DNS验证链路可以拆成这么几段：
1Panel生成TXT记录 → 你在DNS服务商后台添加记录 → DNS解析生效 → 公共DNS缓存更新 → CA服务器查询并比对 → 签发证书
任何一环出现故障，最终都会表现为1Panel上那个刺眼的“DNS记录异常”。所以排查时不要只盯着某一环节，而是要从上到下把整条链路快速过一遍。我整理了一套固定顺序的排查流程，照着走基本能在十分钟内定位问题。
先看1Panel生成的记录值是否完整。再确认你在DNS后台添加记录时的主机记录是否填对(通常填_acme-challenge，这个下划线不能省略）。然后到独立环境用dig查询确认记录是否公开可见。最后检查是否存在多条TXT记录残留的情况，以及域名本身是否有其他解析层面的问题。
3.2 场景一：记录刚添加不久，dig查询无结果
这是占了差不多一半比例的情况。很多朋友在DNS后台添加完TXT记录后，马上点击申请，结果失败。原因很简单：DNS记录从添加生效到全球公共DNS缓存更新，通常需要几分钟时间，有时甚至长达十几分钟。
这个等待时间不是由1Panel控制的，也不由你控制，而是取决于DNS服务商的解析生效速度和各级DNS节点刷新缓存的速度。
我个人的建议是：添加完TXT记录后，别急着点申请，等上5到10分钟再操作，会大大降低失败概率。如果你用dig查询发现记录已经可见，再点申请，那就是秒过。
注意：不要反复点击申请证书。几次失败之间，ACME服务商可能会对你的域名申请频率做出限制，反而把简单问题搞复杂。
3.3 场景二：dig查询返回多条TXT记录
如果dig返回的结果不止一行，比如显示了多条TXT记录，情况就要复杂一些。ACME服务商在验证时，会查找与当前申请匹配的那条TXT记录。但如果同一个主机名下存在多条TXT记录，某些DNS服务商或某些CA服务器可能返回全部记录，甚至出现解析结果顺序不稳定。
这种情况通常发生在你之前申请过证书但失败了，或者同一域名在多个平台申请过证书。每次申请都会生成一条新的TXT记录值，而旧的记录值在申请失败后并不会自动删除。
解决思路很明确：登录DNS管理后台，把该主机名下所有旧的TXT记录全部删掉，只保留当前1Panel界面展示的那一条。然后重新等待生效，再次申请。
这个动作很关键，因为ACME服务商在验证时取到的TXT记录值必须和它期望的值完全匹配。如果DNS返回了多条记录，部分CA服务器会取第一条或者随机一条来比对，一旦取到旧记录，验证就会失败。
3.4 场景三：DNS服务商解析异常
还有一种情况是DNS服务商本身出了问题。这种情况在国内某些小型DNS服务商、或者刚刚做完域名转入/转出的场景下会有一定概率出现。具体表现为：你在DNS后台能看到记录，网页访问域名也正常，但TXT记录就是查询不到。
遇到这种情况，我的建议是直接用公共DNS查询多试几个不同服务商：
dig TXT _acme-challenge.yourdomain.com @8.8.8.8 dig TXT _acme-challenge.yourdomain.com @1.1.1.1如果多个公共DNS都查不到，而你的DNS后台确实显示记录已添加，那大概率是DNS服务商侧数据同步有问题。这已经超出1Panel能控制的范围了，最直接的解决办法是更换DNS解析服务商，或者联系当前服务商的技术支持。
考虑到DNS解析稳定性对证书申请的直接影响，我更推荐使用大厂或专业DNS服务商的解析服务。域名托管在哪儿和DNS解析在哪儿是可以分开的，后者只需要把域名的NS记录指向对应服务商即可。
3.5 场景四：CNAME记录冲突
TXT记录和CNAME记录存在一个容易让人忽略的冲突点：同一个主机名下，如果已经存在CNAME记录，那么再添加TXT记录在某些DNS服务商那里可能会被拒绝，或者虽然能添加但不生效。
_acme-challenge这个主机名通常在干净的域名下不会有什么冲突。但如果你之前配置过其他服务，比如邮件验证、SPF验证，或者某些CDN服务在该主机名下添加过CNAME记录，就存在冲突风险。
处理方法：到DNS管理后台检查_acme-challenge主机名下是否已有非TXT类型的记录。如果有CNAME记录，先删掉CNAME记录，添加TXT记录，完成证书申请后再把CNAME记录加回去。大部分情况下_acme-challenge这个专用前缀不会和其他业务冲突，但检查一下花不了十秒钟，值得做。
3.6 场景五：泛域名证书的多条TXT记录问题
如果你的证书申请的是泛域名(比如*.yourdomain.com），情况又不一样了。根据ACME规范，泛域名证书验证时，需要同时验证根域名本身和泛域名对应的记录，也就是要为yourdomain.com和_acme-challenge.yourdomain.com都添加或已经存在对应的TXT记录。
这个细节很多朋友没注意到，只添加了_acme-challenge.yourdomain.com的记录，结果报DNS记录异常，怎么排查都找不到原因。
正确做法是在你查询TXT记录时，同时验证这两种情况：
# 查泛域名验证记录 dig TXT _acme-challenge.yourdomain.com +short # 查根域名验证记录(部分场景需要) dig TXT yourdomain.com +short如果缺少根域名的TXT记录，在DNS管理后台按1Panel界面展示的信息补上即可。同样的，确认新旧记录不冲突，等待生效后重新申请。
4. 1Panel界面内的操作细节与日志排查
4.1 申请证书时的参数选项怎么选
在1Panel面板里申请ACME证书时，有几个关键参数直接影响到DNS验证的结果。首先是验证方式。如果你选择了DNS验证，面板会展示需要添加的TXT记录信息。如果你选择了HTTP验证，但服务器80端口没有正确开放，或者域名没有正确解析到当前服务器，同样会报错——但那个报错文案通常是“HTTP验证失败”，和“DNS记录异常”不是同一个。
所以看到“DNS记录异常”，第一反应就锁定DNS验证链路，不用往HTTP方向排查。
其次，域名类型有单域名和泛域名之分。选择泛域名时，要确认DNS服务商支持自动添加记录，或者你手动添加的时候有没有遗漏根域名的验证记录。
另外，1Panel还支持通过DNS服务商的API自动添加TXT记录。如果你用的是支持的DNS服务商，可以直接选择自动方式，面板会帮你完成记录添加和删除。这种方式的失败率远低于手动方式，因为它省去了“等待人工添加记录”这个环节。但前提是你在1Panel里正确配置了DNS服务商的API密钥。
4.2 通过面板日志定位具体失败原因
1Panel的好处是操作界面友好，坏处是错误提示过于抽象。“DNS记录异常”这个提示并没有告诉你到底是哪一步出错了。好在面板保留了详细的日志，通过日志能看到更多线索。
在1Panel中，任务执行日志通常在证书申请记录页面或者后台任务的日志里可以查看。日志内容一般会包含ACME服务商返回的具体错误信息。常见的包括：
No TXT record found at _acme-challenge.yourdomain.com：TXT记录不存在，说明记录没添加或未生效。Timeout during validation：验证超时，可能是网络原因或DNS查询超时。Wrong TXT record value：TXT记录值不匹配，记录内容填错了。Too many certificates already issued：短时间内申请次数过多。
看到这些具体错误信息后，排查方向就非常明确了。日志是定位问题的第一手信息来源，比任何猜测都可靠。
4.3 1Panel中证书续期与DNS记录的关系
很多朋友以为只有初次申请才会遇到DNS记录异常，实际上证书续期时同样可能踩坑。1Panel会自动续期证书，续期时同样需要通过ACME验证。如果首次申请时使用的DNS服务商API密钥失效了、或者你在DNS后台手动删除了验证记录，续期时就会再次遇到DNS记录异常。
所以遇到续期失败时，不要觉得奇怪，用同样的排查流程走一遍即可。尤其注意检查API密钥是否还有效，DNS服务商账号是否还能正常访问。
我在实际使用中发现，1Panel的续期任务一般会在证书到期前30天左右发起，留出了足够的时间余量。只要DNS配置没有问题，续期通常在几秒内完成。但一旦DNS配置有问题，续期会反复失败，需要及时发现。所以建议打开面板的通知功能，有异常时第一时间收到消息。
5. 实操演示：一个完整的修复过程
5.1 模拟故障现场
为了演示，我模拟一个典型故障场景：某域名example.com，通过1Panel申请单域名证书，报错“DNS记录异常”。
登录DNS服务商后台，发现记录里已有一条TXT记录，主机记录为_acme-challenge，记录值是一串字符。1Panel界面展示的TXT记录值也是一串字符，看起来两者一模一样。这时候如果只是肉眼看，很容易误判为配置无误。
5.2 逐层排查找到真相
按排查流程，先在一台独立服务器上执行dig命令：
dig TXT _acme-challenge.example.com +short返回内容为空。说明从公共DNS层面查询不到这条TXT记录。
接着检查DNS后台的记录列表，发现该主机名下其实有两条TXT记录，一条是旧的(肉眼看起来很像，但已经失效），一条是刚添加的(1Panel这次要求的）。由于公共DNS返回时可能会把两条记录一并返回，ACME服务器取到的值无法与期望值完全匹配。
这个场景在实际中非常典型。很多DNS服务商在展示TXT记录时，并不会把记录值的高亮、格式做得特别清楚，导致两条记录在界面上看起来几乎一样，人眼识别非常困难。
5.3 修复并验证
找到原因后，修复动作就很简单：删除旧的TXT记录，只保留当前1Panel界面要求的那一条。然后重新查询：
dig TXT _acme-challenge.example.com +short这次返回了一条记录，且内容和1Panel页面上展示的完全一致。回到1Panel点击申请，证书签发成功。
这个例子充分说明，大部分DNS记录异常的根因都在“记录可见性”上，不是1Panel自身的问题，也不是ACME服务商的问题，而是DNS解析链路中存在不一致或无效的记录。
5.4 一键申请失败后的重试节奏
如果你执行完清理、修正操作，不要急着重试太多。我测试下来的合理节奏是：做完DNS调整后等待5到10分钟，用dig确认记录无误，再回1Panel点击申请。
如果申请失败，重新查看日志确认错误信息是否有变化。如果同样的错误信息出现多次，不要直接重复申请，而是再走一轮排查流程。快速重试解决不了问题，反而可能触发ACME服务商对申请频率的限制。
提示：Let's Encrypt这类ACME服务商对同一域名有证书签发数量限制(包括失败和成功的申请）。虽然限制通常比较宽松，但如果连续失败几十次，大概率会被短暂封禁。到时候就不是DNS的问题了，而是等待解封的问题，非常耽误事。
6. 网络环境与基础配置的隐性坑
6.1 服务器时间不同步导致验证失败
有一个很少被注意到的原因：申请证书的服务器系统时间不同步。ACME验证在发起时会带一个时间戳，CA服务器收到请求后会校验时间偏差。如果服务器时间偏差过大(比如超过几分钟），CA服务器会直接拒绝验证请求，报错信息也可能被归类为验证失败，其中就包括DNS记录异常的模糊提示。
排查方法很简单：在服务器上执行date命令查看当前时间，然后和你手机上的时间对比。如果偏差超过1分钟，建议配置NTP时间同步：
# Debian/Ubuntu sudo timedatectl set-ntp true # CentOS/RHEL 7+ sudo yum install -y ntpdate sudo ntpdate ntp.aliyun.com这个坑其实不少见，尤其是长期不维护的服务器或刚迁移过的机器。我之前在一台新开的服务器上遇到过诡异问题——HTTP验证失败、DNS验证也失败，换证书服务商也一样。最后排查半天，发现系统时间慢了将近5分钟。时间一校准，问题彻底消失。
6.2 服务器出站网络对验证的影响
ACME证书申请过程需要服务器与CA服务器进行HTTPS通信。如果你的服务器出站网络不稳定，或者所在网络环境对国外CA服务商的连接做了限制，同样可能导致验证流程中断，最终报错。
这种情况的排查方法是：在服务器上手动模拟一次证书申请请求，看能否正常完成与CA服务商的通信。如果超时或者失败，基本可以确认是网络链路问题。
处理思路也很直接：换个网络环境、检查防火墙出站规则、或者使用1Panel中配置的HTTP代理进行证书申请。如果面板不支持直接配置代理，也可以通过系统环境变量注入代理设置，让证书申请请求走代理通道。这个方案我之前在受限网络中验证过，是可行的。
6.3 防火墙对验证请求的影响
如果你选择的验证方式是HTTP-01，那就要确认服务器的80端口是否对外开放，并且没有任何反向代理或CDN把验证请求拦截。但正如前面说的，DNS-01验证不需要服务器开放任何入站端口，它只通过DNS查询来完成。
所以你如果走的是DNS验证且报错“DNS记录异常”，防火墙一般不是直接原因。但有一种间接影响：如果服务器无法访问CA服务器的接口(出站被防火墙拦截），面板可能无法正确发起或确认验证流程，导致超时后显示一个模糊的错误提示。这种情况下日志会显示网络类错误，需要结合实际日志来判断。
7. 多个域名批量申请时的常见问题
7.1 每个域名都需要独立验证记录
用1Panel申请多域名证书(即SAN证书，一张证书包含多个域名），ACME服务商会要求每个域名都通过验证。这意味着你需要在DNS后台为每个域名都添加对应的TXT记录，而不是添加一条记录就能覆盖所有域名。
常见的错误场景是：申请包含a.example.com和b.example.com的证书，只给a.example.com添加了TXT记录，忽略了b.example.com，结果报DNS记录异常。
正确做法是确认证书申请列表中的每个域名都有对应的验证记录。检查时要逐一使用dig查询，确保每个域名的TXT记录都可见且内容正确。
7.2 批量申请时记录残留的影响
批量申请失败后，DNS后台会很热闹——每个域名下可能残留了多条未清理的TXT记录。如果这时候你反复申请，记录会越积越多，干扰后续验证。
我的建议是：批量申请之前，先对DNS后台做一次清理，把历史遗留的TXT记录删干净。然后再发起申请。批量任务跑完后，立即回DNS后台清理验证记录，避免对后续其他证书的申请产生影响。
7.3 泛域名与多域名混用时的验证差异
泛域名证书和多域名证书可以混合使用，比如一张证书同时包含example.com、*.example.com和www.example.com。这种情况下，验证要求更复杂：泛域名部分需要验证根域名的TXT记录，普通域名部分需要验证各自的主机记录。
实操时我建议分两步走：先确认普通域名的TXT记录都齐了，再确认泛域名关联的根域名TXT记录是否存在。不要想当然地认为添加一条就万事大吉。这个场景稍微少见，但一旦遇到，排查成本会比单域名场景高不少，毕竟涉及多个主机记录的管理。
8. 从报错到稳定运行的长期经验
8.1 我的推荐配置组合
在1Panel使用一段时间之后，我沉淀了一套相对稳妥的证书申请配置组合，分享出来供你参考：
DNS解析托管在可靠的专业DNS服务商上，同时在DNS服务商后台开启API访问并生成专用密钥。在1Panel中添加DNS服务商的API凭证，申请证书时选择DNS验证并勾选自动添加记录。这样从申请到验证到签发的全过程基本自动化，人工介入点只有一个——首次配置API密钥。
这套组合最大的好处是省心，而且自动添加记录了，就不存在手动填写记录时容易出现的格式和遗漏问题。
8.2 容易反复踩坑的几个细节
有几个细节是我踩过坑之后才总结出来的：首先，1Panel的DNS API集成对DNS服务商有适配范围，使用前要在面板里确认你自己的DNS服务商是否在支持列表内。如果不支持，就只能手动添加TXT记录，那就要把手动添加的耐心和细心都拿出来。
其次，DNS API密钥一般建议设置最小权限，只授权DNS解析记录的修改权限，不要直接给账号最高权限。这既是安全习惯，也能避免误操作影响其他DNS配置。
第三，如果你同时使用CDN、邮件服务等，注意这些服务会对DNS解析记录有依赖。清理TXT记录只清理_acme-challenge相关记录，不要顺手把其他记录删了。我在早期有一次批量清理时误删了某个邮件验证记录，导致邮件服务异常了一整天。
8.3 关于证书续期的自动化维护
1Panel的证书续期是自动的，但这不意味着你可以完全不关注。只要DNS记录链路是健康的，自动续期一般会安静地完成，你甚至感知不到证书已经换了新的一张。
但有一种情况需要你特别注意：如果当初申请证书时使用了手动的DNS验证方式，而DNS后台的记录没过多久被某个自动化脚本或人工操作清理了，那么续期时面板会重新走一遍DNS验证，面临着和首次申请一样的DNS记录异常风险。
我的习惯是每季度登录一次1Panel，在证书列表里检查每个证书的到期时间和最近续期状态。发现有续期失败的记录，立即排查。没事的时候就完全不用管它，让自动化机制自己去跑。
9. 最后的实践经验总结
整个“1Panel申请ACME证书失败提示DNS记录异常”的排查过程，说到底就是一件事：确认TXT验证记录能否被CA服务器从公共DNS上正确查询到。只要这一条链路是通的，99%的申请失败问题都能迎刃而解。
我个人在实际操作中的体会是：看到报错不要慌，先把1Panel的日志翻出来看具体错误信息，比对着那一句笼统的文案凭空猜要有效得多。然后依次检查记录值内容、记录数量、生效时间、DNS服务商状态这几个环节。如果这些都没问题，再考虑时间同步、出站网络等偏门因素。
最后再分享一个小技巧：在你的常用电脑或服务器上，把dig查询命令存成一个顺手的小脚本或者别名，遇到证书问题时直接调用，能省去每次重复敲命令的时间。我现在遇到DNS相关的问题，基本都是先跑一遍dig确认记录可见性，再决定下一步排查方向，效率比之前瞎试高了太多。遇到过一两次问题并彻底解决之后，后面基本就顺了。
