别慌，这通常是链路问题。按这个顺序排查： 分层测试：用 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。控制台配置和实际生效之间还有缓存延迟，改完等几分钟再测。还不对就带域名和请求时间提工单，让后端查实际回源记录。... 展开详请

先泼个冷水：workers.dev 这个域名对云机房 IP 很不友好，Cloudflare 对来自数据中心 IP 的请求风控很重，而 EO 回源节点全是机房 IP，握手被丢包或直接 RST 太常见了，522 多半不是你配置错，是对端在拒你。验证很简单：找台云服务器 curl -v 那个 workers.dev 地址多试几次，再用家庭宽带对比访问，机房必挂基本就实锤了。解法两条：给 Worker 绑自己的自定义域名走 CF 接入，风控策略宽松很多；或者干脆把同样的逻辑搬到 EO 边缘函数里实现，去掉跨云回源这一跳，延迟和稳定性都更好，也省得两头排查。... 展开详请

这种情况八成是微信侧的备案缓存还没同步。工信部备案公示后，微信安全中心一般要3到5天才能刷新，不是你腾讯云这边没备好。 可以先做这几件事：去工信部备案查询站确认域名已经公示；在微信里长按链接，用右上角菜单里的“申诉”走一遍；检查一下域名实际访问的跳转链，有时候 www 和根域、http 到 https 的跳转中间夹了没备案的域名，也会被微信拦。 还有个常见坑是企业备案主体和公众号主体不一致，微信某些场景会额外校验。如果只是时间差，等两天基本自己就好了，不用折腾服务器。... 展开详请