驳回原因是工信部系统里该主体仍有“审核中”记录，腾讯云检测到就会拦截。小程序备案虽已注销，但管局审核需1-20个工作日，且通过后数据同步到接入商还需6-24小时，你看到的“有备案记录”可能只是注销流程尚未走完或同步延迟。 别反复提交相同订单，会触发风控。先打工信部热线，报统一社会信用代码确认是否还有在途备案；若确认无在途记录，等1-2个工作日让数据同步后再重新提交。若工商变更刚完成，工商信息库更新也需3-7个工作日。 若工信部确认无在途备案但腾讯云仍驳回，可联系客服提供工信部查询结果截图申请人工核验。目前公开材料未提及社会信用代码变更后需额外提交变更证明，建议以客服或管局答复为准。 官方详细解决方案：https://cloud.tencent.com/product/lighthouse?Is=sdk-topnav... 展开详请

别干等，先确认改没改对。用 dig @权威DNS服务器 域名 直接查权威源，如果返回的还是旧记录，说明配置根本没提交成功或主从同步延迟，跟ttl无关。 权威源已更新但本地解析仍旧，才是缓存问题。用 dig 域名 看返回的ttl剩余值，结合你修改的时间点推算是否还在缓存窗口内。也可以换台从未访问过该域名的机器或用公共dns（如8.8.8.8）测试，新环境能解析出新记录就实锤是本地缓存。 注意多级缓存陷阱：浏览器、操作系统、ldns、cdn都可能各自缓存。排查时逐级绕过：清浏览器缓存、刷新系统dns、指定公共dns查询，定位卡在哪一层。 还有个坑：修改前ttl设得很长（比如24小时），改完才调小，那旧缓存依然按原ttl生效。正确做法是提前48小时把ttl调到60秒，再改记录，否则只能等自然过期。 官方详细解决方案：https://cloud.tencent.com/product/domain?Is=sdk-topnav... 展开详请

自动续签（ACME 的 certbot 或云托管续签）拿到的证书是「文件」，CLB 用的证书是「云上资源」——两者之间要一条同步链路。四种方案按自动化程度排序：1. 全托管（最省心）：如果域名解析和负载都在腾讯云，直接用腾讯云 SSL 证书平台的托管证书：证书平台自动续期 + CLB 监听器直接引用平台证书，续期后 CLB 自动拿到新证书，零脚本。ACME 免费证书在证书平台申请时勾选自动续期即可；2. API 同步脚本（自管证书的标准方案）：续签工具跑在服务器上拿到新证书文件后，加一个 post-renew hook 脃用腾讯云 API 更新 CLB：流程是 UploadCert（或 ReplaceCert）传公私钥 → 拿到新证书 ID → ModifyListener 把监听器的 CertificateId 换成新 ID。hook 脚本十几行，配在 certbot 的 deploy_hook 里全自动。注意 API 调用要做幂等和失败告警（续期成功但同步失败 = 定时炸弹，监控要盯 CLB 上证书的到期时间而不是本地文件）；3. CI 定时任务：把「检测到期 → 续签 → 调 API 同步 → 验证」做成每日定时任务（cron 或流水线），任务输出证书指纹和到期天数到监控。比 hook 方案多了「验证」环节：同步后用 openssl s_client 连 CLB 的 443 端口看实际下发的证书指纹是不是新的——防止「API 返回成功但 CLB 缓存没刷新」的静默失败；4. 多层分发（证书用在多处时）：证书文件进对象存储/配置中心，CLB、CDN、nginx 各自的同步任务都从这一个源头拉。避免「服务器上续了、CLB 同步了、CDN 忘了」的半自动状态。两个必做的配套：a. 证书到期监控至少提前 21 天告警（到期 3 天才发现就等着手工救火）；b. 同步链路验证用「线上握手看实际证书」而不是「API 返回成功」，这是唯一不会骗你的验证方式。... 展开详请

开通中国大陆节点 EdgeOne 主要分这几步： 前提条件：腾讯云账号完成实名认证，域名已完成工信部 ICP 备案，源站（CVM / COS 等）可正常访问。 操作流程： 登录边缘安全加速平台 EO 控制台，点击「添加站点」，输入域名。 选择套餐（付费套餐或免费套餐兑换），同意服务协议。 加速区域选「中国大陆可用区」或「全球可用区」——这一步决定了是否启用国内节点。 选接入模式： CNAME 接入：不改 DNS 服务商，加 CNAME 记录即可，适合已有解析的场景。 NS 接入：把 DNS 托管给 EdgeOne，一键生效，适合新域名。 DNSPod 托管接入：域名在 DNSPod 时最省事。 按提示完成域名验证（CNAME 接入需加 TXT 记录验证归属权，NS 接入需改 DNS 服务器）。 进入「域名服务 → 域名管理」添加加速域名，配置源站地址、回源协议等。 到 DNS 服务商处添加 EdgeOne 分配的 CNAME 记录，等待生效即可。 验证：nslookup 你的域名 看是否解析到 EdgeOne 的 CNAME，或者直接用 curl -I 看响应头里是否带 X-EO- 标识。 注意：如果域名还没备案，选中国大陆区域会提示受限，只能先选「全球可用区（不含中国大陆）」。 官方详细解决方案：https://cloud.tencent.com/product/teo... 展开详请

排查时应先区分 TCP 连接地址、TLS SNI、HTTP Host：源站 IP 决定连接哪台机器，SNI 在 TLS 握手阶段决定 Nginx 选择哪个证书，Host 则在握手完成后参与 HTTP 虚拟主机匹配，因此“访问 IP 并修改 Host 成功”不能证明 SNI 正确，若测试关闭了证书校验，更不能证明证书匹配；多域名共用 IP 时，SNI 缺失或错误可能命中默认 server，返回错误证书或直接拒绝握手，即使 Host 正确也无法挽救。EdgeOne 实际发送的 Host、SNI，以及源站证书校验能力与默认策略，应以当前站点的回源配置和官方文档为准，不能仅凭源站填 IP 就推断；建议显式将回源 Host 和 SNI 对齐到源站证书覆盖的域名，填 IP 不意味着证书必须包含 IP，关键是平台采用什么名称校验证书，填域名则还需检查 DNS 是否返回了多个配置不一致的源站，并避免解析回 EdgeOne 形成回环。可用 openssl s_client -connect 源站IP:443 -servername 加速域名 -verify_hostname 加速域名 -verify_return_error -showcerts </dev/null 检查指定 SNI 下的证书、链和名称校验，再用 curl -v --resolve 加速域名:443:源站IP --connect-timeout 5 --max-time 15 https://加速域名/路径 在保留正确 SNI、Host 和证书校验的前提下直连源站，不要加 -k；对照使用 openssl s_client -connect 源站IP:443 -noservername </dev/null 可识别默认虚拟主机问题。改 HTTP 正常只能缩小排查范围，不能直接证明是证书问题；固定配置的名称不匹配通常会稳定复现，间歇性 502 更应检查不同节点、源站地址或配置是否存在差异，并按失败时间和请求标识关联 EdgeOne 日志、Nginx error 日志、连接来源及抓包，必要时记录 $ssl_server_name、$host、$server_name，但握手失败不会进入 HTTP access 日志；若抓包显示 SYN 无响应，优先查安全组、防火墙、封禁与连接限制，若 TCP 建连后出现 TLS 告警则查 SNI、证书及协议兼容性，若握手成功后才超时则继续查 HTTP 和应用处理，不能仅凭一条握手错误认定是 EdgeOne 节点被封。... 展开详请

别慌，Makers 这平台底层是支持 HTTP/2 的，没开关是因为默认就开了。你测出来是 http/1.1，大概率是你测试姿势不对。 最简单的排查：别用普通 curl，加个 --http2 参数再试一次。如果返回 HTTP/2 200，那就是服务端没问题，是你之前用的工具太老或者没强制协商。 还有，浏览器里按 F12 看 Network 面板，Protocol 列要是显示 h2 才算真成功。要是全显 http/1.1，检查下是不是用了代理软件或者公司防火墙把 ALPN 包给拦了，切个手机热点试试。 只要证书没问题且走 HTTPS，基本都能跑通。实在不行，甩张 curl -v 的截图去腾讯云工单那边问，他们查得很快。 官方详细解决方案：https://cloud.tencent.com/product/workbuddy?Is=sdk-topnav... 展开详请

别慌，这通常是链路问题。按这个顺序排查： 分层测试：用 curl -v 或 ping 测具体超时节点 IP。如果 Ping 通但 HTTPS 超时，说明 TCP 通了，SSL 握手被劫持或丢包；如果 Ping 不通，直接找运营商或 EdgeOne 工单。 抓包分析：在本地或边缘节点用 tcpdump 抓包，看 TLS Handshake 阶段（Client Hello -> Server Hello）哪一步断了。如果是 SYN-ACK 丢失，大概率是中间节点丢弃了特定端口流量。 对比测试：切到 HTTP 试试。如果 HTTP 正常而 HTTPS 超时，90% 是 SNI 污染或证书校验问题，检查域名是否备案、证书是否有效。 查状态页：先看 EdgeOne 官方状态页有没有区域性故障公告。 优先联系 EdgeOne 客服提供具体超时节点的 IP 和 TraceID，他们后台能看到精确的阻断原因。 官方详细解决方案：https://cloud.tencent.com/product/teo... 展开详请

先说结论：这基本不是配置错了，是边缘节点上的旧缓存还没失效。源站改了内容，不等于 EdgeOne 边缘节点手里的副本也跟着变，缓存 TTL 没到期之前它会一直吐旧文件。 排查和处理的顺序我建议这样走： 第一，先确认到底是哪一层在返回旧内容。用 curl 打边缘节点，带上 -H "Cache-Control: no-cache" 和 -I 看响应头里的 x-cache（是 HIT 还是 MISS）、age、etag。如果加了 no-cache 还是旧内容，说明是边缘缓存没清，需要去控制台主动「清除缓存 / 刷新」对应 URL 或目录前缀；如果加了 no-cache 就变新了，那问题在浏览器本地缓存层，得让用户强刷或调 Cache-Control。 第二，别靠「覆盖同名文件」指望它自动更新。静态资源同名覆盖是最容易踩的坑，边缘根本不知道你源站换过内容。两条更稳的路：要么改完主动 purge，要么从根上给文件加版本号或内容哈希（比如 app.3f2a.js），URL 变了自然绕开旧缓存。 第三，注意缓存键（cache key）的配置。如果你开了「按查询参数 / 按特定 Header 区分缓存」，你本地测的那个 URL 和别人实际命中的可能不是同一份，会出现「我看着是新的是不是别人还是旧的」的错觉。统一用 curl 带相同参数验证才准。 第四，CDN 缓存和浏览器缓存是叠层的。就算边缘清干净了，用户浏览器还揣着 304 和本地副本，所以上线后如果发现还有人报旧内容，先让他们强刷，再回头查是不是自己的 Cache-Control 头写得太长。 一句话：改源站之后，凡是同名静态资源，养成「改完即 purge 或换版本号」的习惯，比事后排查省事得多。... 展开详请

别慌，这是 EdgeOne 的“透明代理”特性在作祟。既然桶不在你控制台，说明是系统托管资源，你没法直接改 COS ACL。 解决思路分两步： 源头封堵（推荐）：直接提工单给腾讯云，要求将源站 COS 桶权限改为“私有”，并授权 EdgeOne 服务账号读取。这是最彻底的办法，让外部根本无法直连 COS。 边缘拦截：如果无法改源站，必须在 EdgeOne 控制台加一道锁。去【站点配置】->【安全策略】或【自定义规则】，添加一条规则：若请求无鉴权 Header（如 Token），直接返回 403。这样即使 COS 开着匿名读，用户也得先过 EdgeOne 这一关。 防收录的话，在 EdgeOne 响应头里加上 X-Robots-Tag: noindex, nofollow 即可。记住，CDN 只是通道，权限还得靠后端或者边缘节点硬控。 官方详细解决方案：https://cloud.tencent.com/developer/article/2696268... 展开详请

区域加运营商同时出问题，优先排查 DNS 解析和节点覆盖。用不同运营商网络 dig 域名，看返回的 EdgeOne 节点 IP 是否一致；再 telnet 80/443 端口确认连通性。免费版节点覆盖和调度策略通常比付费版弱，部分地区可能回源路径绕远或被中间网络拦截。抓包看 TCP 握手在哪一步失败，如果 SYN 无响应，基本确认是接入层或运营商路由问题；如果 TLS 阶段失败，再查证书链和 SNI。同时去 EdgeOne 控制台看对应区域是否有异常告警。... 展开详请

不一定，几个常见坑先排查。第一，确认配的是「强制 HTTP 回源」还是「跟随协议」，跟随协议模式下客户端用 HTTPS 访问就会以 HTTPS 回源，这是最常见的误会。第二，检查是否有「强制 HTTPS」或「强制跳转」类配置开了，这类配置优先级高于回源协议设置。第三，如果源站 80 端口有 301 跳转到 HTTPS，回源请求会被跟随跳转，最终实际走的就是 HTTPS，抓包或看边缘日志能看到跳转链。第四，注意配置生效有延迟，改完等几分钟再看实时日志。定位方法很简单：看回源日志里记录的回源协议和端口，对不上配置就是被上面某条规则覆盖了。遇到这种配置「不生效」的问题，先怀疑配置优先级，再怀疑源站行为，别急着重配。... 展开详请

这是一个非常典型且令人头疼的 DNS 缓存 + 平台状态不同步 问题。EdgeOne Pages（以及类似的静态托管平台如 Vercel, Netlify）在删除域名后，底层资源可能因为 CDN 节点缓存、DNS 记录残留或平台内部异步清理延迟而未能立即释放。 官方具体解决方案：https://curl.qcloud.com/egLwddIX 以下是针对“域名已存在”报错和持续 404 问题的逐步排查与解决方案： 🚨 核心原因分析 平台侧状态未同步：你虽然在控制台点击了“删除”，但 EdgeOne 后台可能仍在处理资源回收，或者该域名被标记为“保留/冲突”状态。 DNS 解析残留：你的 DNS 服务商（如阿里云 DNS、Cloudflare）中仍存有指向 EdgeOne 的 CNAME 或 A 记录，导致流量继续到达边缘节点。 CDN 缓存污染：即使源站返回 404，全球 CDN 节点可能缓存了旧的 404 页面或错误状态，导致用户一直看到 404。 浏览器本地缓存：浏览器强制缓存了之前的 404 响应。 ✅ 解决方案步骤（按优先级排序） 第一步：彻底清除本地与全局缓存（立即生效） 浏览器无痕模式测试： 使用 Chrome/Firefox 的**无痕模式（Incognito）**访问域名。如果正常，说明是浏览器缓存问题。 快捷键 Ctrl+F5 (Windows) 或 Cmd+Shift+R (Mac) 强制刷新。 清空本地 DNS 缓存： Windows: 打开 CMD，输入 ipconfig /flushdns Mac: 打开终端，输入 sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder Linux: 根据发行版使用 systemctl restart systemd-resolved 或 nscd -i hosts 使用公共 DNS 验证： 将电脑 DNS 临时改为 8.8.8.8 (Google) 或 1.1.1.1 (Cloudflare)，再次访问域名，看是否恢复。这能排除本地运营商 DNS 缓存干扰。 第二步：检查并清理 DNS 记录（关键步骤） 即使你在 EdgeOne 删除了域名，如果你的 DNS 服务商里还有记录，流量依然会过去。 登录你的 DNS 服务商（如阿里云万网、腾讯云 DNSPod、Cloudflare）。 查找所有相关记录： 搜索域名的 CNAME 记录（通常指向 *.pages.edgeone.net 或类似地址）。 搜索 A 记录 或 AAAA 记录（如果使用了 IP 直连）。 搜索 TXT 记录（用于验证所有权）。 删除所有旧记录： 务必删除所有指向 EdgeOne 的 CNAME/A 记录。 如果你打算重新绑定同一个域名，请确保这些记录已被物理删除，而不是仅仅修改。 第三步：解决“域名已存在”报错（平台侧操作） 这是最棘手的部分，因为涉及 EdgeOne 后台状态。 等待 24-48 小时： 平台侧的资源释放通常是异步的。如果刚删除不久，系统可能仍在锁定该域名以防止冲突。建议等待至少 24 小时再尝试重新绑定。 联系 EdgeOne 客服/提交工单： 如果超过 24 小时仍提示“域名已存在”，必须提交工单。 话术模板： “您好，我在 [日期] 删除了域名 [example.com] 的站点配置，但当前尝试重新绑定时提示‘域名已存在’。同时，该域名在全球 DNS 中已无相关记录，但访问时仍返回 404。请协助检查后台资源是否已完全释放，并解除该域名的占用状态。” 提供截图：包括删除操作的日志（如果有）、DNS 查询结果（使用 dig 或 nslookup 证明无记录）。 尝试更换子域名绑定（变通方案）： 如果主域名 example.com 被死锁，可以尝试先绑定 www.example.com 或 app.example.com，看是否能成功。如果能成功，说明只有根域名被占用，可进一步确认是平台 bug。 第四步：处理持续 404 问题 如果平台侧已释放，但访问仍 404： 检查 EdgeOne Pages 控制台： 确认没有处于“草稿”、“构建失败”或“暂停”状态的站点占用该域名。 如果有旧的部署任务卡住，尝试终止构建或删除整个项目（Project），而不仅仅是删除域名关联。 重新绑定流程： 在 EdgeOne 控制台创建新站点 -> 绑定域名 -> 等待 DNS 验证通过。 在 DNS 服务商添加新的 CNAME 记录。 关键点：新绑定后，首次访问可能会因 CDN 预热而短暂 404，请耐心等待 5-10 分钟。 使用命令行验证： # 检查 DNS 解析是否正确指向 EdgeOne dig example.com CNAME # 检查 HTTP 状态码（忽略缓存） curl -I -H "Cache-Control: no-cache" https://example.com 如果 dig 显示无记录，但 curl 仍有响应，说明流量仍被某些中间节点劫持或缓存，需等待更长时间或联系 CDN 提供商。 🛡️ 预防建议 删除前先解绑 DNS：在 EdgeOne 控制台删除域名前，先在 DNS 服务商删除所有相关记录。这样可以从源头上切断流量，避免平台侧误判。 使用子域名隔离：对于测试环境，建议使用 test.example.com 而非 example.com。这样即使测试环境出问题，也不会影响主域名。 定期审计：每季度检查一次 EdgeOne 控制台的站点列表，及时清理不再使用的旧项目。 总结行动清单 现在：清 DNS 缓存 + 浏览器无痕模式测试。 立刻：去 DNS 服务商删除所有指向 EdgeOne 的记录。 明天：如果仍报错，提交 EdgeOne 工单，要求人工释放域名资源。 之后：等待平台确认后，重新绑定并添加新的 DNS 记录。 如果以上步骤执行后仍无法解决，极大概率是 EdgeOne 后台的域名锁（Domain Lock） 未解除，此时只能依赖官方客服介入手动解锁。 官方具体解决方案：https://curl.qcloud.com/egLwddIX... 展开详请

EO回源体系本身支持IPv6地址，文档里禁的只是链路本地和私网网段（fe80::/10、fc00::/7这类）。但域名型源站只解析出AAAA记录、免费套餐能不能正常回源，文档确实没写死，这块别猜，直接提工单确认，附上zone ID和源站域名让官方查后端配置。可以先自查一步：给源站域名临时加条A记录，回源立刻正常的话，基本就是IPv6回源在这个套餐或加速区域下不生效。另外记得查源站IPv6防火墙和安全组，EO回源IP网段要放行，很多所谓的回源失败其实是源站把节点IP拒了，白查半天配置。... 展开详请

这是校验逻辑没区分接入模式的老问题。NS接入下权威解析已托管给EO，控制台里CAA/MX/TXT跟加速CNAME共存是正常的，邮件和证书验证本来就要配MX/CAA，跟站点加速的CNAME互不干扰。CNAME接入才有主机记录上CNAME与其他记录不能共存的约束。可以先自查两点：提示里的主机记录是否在EO DNS里真的同时配了CNAME和MX/TXT，确实配了才需要拆分主机记录；NS已生效但提示还在，大概率是状态同步延迟或校验没识别接入模式，直接提工单附上NS生效截图，让后端按NS场景关掉这条校验。这类误报催工单比自己在控制台折腾快得多。... 展开详请

典型的配置优先级问题。先查三个地方：一看回源协议的全局配置，确认选的是跟随协议还是固定HTTP，很多控制台里HTTPS相关配置会强制回源走HTTPS，优先级高于单条回源规则；二看有没有强制HTTPS跳转或回源HTTPS的开关在边缘层生效；三确认测试方法，用curl带响应头看边缘返回，或直接抓源站访问日志看实际进来的协议，别只看控制台显示。另外源站如果是443端口但回源协议设了HTTP，EO可能按默认策略自动走HTTPS。控制台配置和实际生效之间还有缓存延迟，改完等几分钟再测。还不对就带域名和请求时间提工单，让后端查实际回源记录。... 展开详请