1. 这不是“配个域名”那么简单App Platform 上的三层安全与加速链路本质你刚把应用部署到 App Platform本地跑得飞起一上线就发现访问地址是https://your-app.ondigitalocean.app丑、难记、不专业想绑自己的app.yourcompany.com结果提示“DNS 验证失败”好不容易加了自定义域名浏览器地址栏却显示“不安全”小锁图标打叉再一查加载速度首屏时间 3.2 秒用户还没看清按钮就划走了。这不是你代码写得差而是你漏掉了现代 Web 应用上线前必须打通的三层基础设施链路自定义域名Custom Domain→ TLS/SSL 加密SSL→ 内容分发网络CDN。这三者不是并列选项而是一条环环相扣的依赖链——没有正确配置域名SSL 就无法签发没有有效 SSLCDN 的 HTTPS 回源就会中断CDN 配置错误又会反向导致 SSL 证书验证失败。我去年帮 7 个客户做 App Platform 迁移其中 5 个卡在第二层 SSL2 个在第三层 CDN 的缓存策略上反复回滚。根本原因不是操作步骤复杂而是绝大多数教程把这三层当成三个独立任务来教而实际生产环境里它们共享同一套 DNS 解析逻辑、共用同一组证书生命周期、共担同一份缓存失效风险。比如你用 Let’s Encrypt 自动续期但 CDN 节点缓存了旧证书的 OCSP 响应用户访问时就会触发ssl: certificate_verify_failed再比如你改了 HTML 里一个link relstylesheet hrefhttps://cdn.example.com/style.css但七牛云 CDN 的缓存规则没排除.css后缀新样式压根刷不出来最后排查半天发现是icon 图标显示有误根本不是前端 bug而是 CDN 缓存了旧版 CSS 里的字体路径。所以这篇不讲“点击哪里填什么”而是带你从 DNS 解析器开始一层层拆开 App Platform 如何把这三层拧成一股绳——它不像传统 Nginx 需要你手写listen 443 ssl也不像宝塔面板能一键申请免费 SSL它的设计哲学是“托管式自动化”但自动化有前提你必须理解它自动化的边界在哪里。2. Custom Domain 配置DNS 解析不是“填个 CNAME 就完事”App Platform 的自定义域名配置表面看只有两步在控制台添加域名 → 按提示设置 DNS 记录。但真实世界里90% 的失败都卡在 DNS 这一步而且错误提示极其模糊——“DNS 验证失败”、“未检测到有效记录”、“验证超时”。这些提示背后是 DNS 解析链路上至少 4 个关键节点的协同问题。我们得先搞清 App Platform 的域名验证机制它不直接查询你的 DNS 服务器而是通过 DigitalOcean 自有的 DNS 解析器基于 PowerDNS向你配置的权威 DNS 服务器发起查询并要求返回特定格式的 TXT 或 CNAME 记录。这个过程不是“一次查询”而是包含 TTL 缓存、递归解析、权威响应三重校验。举个真实案例某客户用阿里云 DNS添加了CNAME app.yourcompany.com → your-app.ondigitalocean.app但始终验证失败。抓包发现阿里云 DNS 的 TTL 设置为 3600 秒1 小时而 App Platform 的验证服务每 5 分钟轮询一次前几次查询返回的是旧的 NS 记录缓存直到第 12 次才命中新记录。这不是 App Platform 的 bug而是 DNS 协议本身的最终一致性特性。所以第一步永远是检查 DNS 记录的传播状态而不是反复点击“重试验证”。2.1 三种域名类型对应三种 DNS 配置模式App Platform 支持三种域名绑定方式每种对 DNS 的要求截然不同域名类型示例DNS 配置要求常见陷阱实测验证命令子域名推荐app.yourcompany.com必须配置CNAME记录指向your-app.ondigitalocean.app错误配置为A记录CNAME 指向带路径如your-app.ondigitalocean.app/未关闭 DNSSECdig short app.yourcompany.com CNAME返回精确值根域名Root Domainyourcompany.com必须配置ALIAS或ANAME记录非标准 DNS 类型或使用A记录指向 App Platform 提供的 IP 地址池在不支持 ALIAS 的 DNS 服务商如部分企业内网 DNS强行用A记录导致 IPv6 不可用IP 地址池变更后未及时更新dig short yourcompany.com A对比官方 IP 池列表通配符域名*.yourcompany.com必须配置CNAME记录指向your-app.ondigitalocean.app通配符只匹配一级子域名api.yourcompany.com✅v1.api.yourcompany.com❌与根域名记录冲突dig short test.yourcompany.com CNAME提示DigitalOcean 官方明确建议优先使用子域名Subdomain因为CNAME是 DNS 标准协议所有主流 DNS 服务商Cloudflare、阿里云、腾讯云、GoDaddy100% 支持且无 TTL 传播延迟问题。根域名Root Domain虽可用但ALIAS记录依赖 DNS 服务商实现Cloudflare 的CNAME Flattening和阿里云的隐性 URL本质都是代理层转换一旦代理层故障整个根域名不可用。我经手的项目中100% 的根域名故障都源于 DNS 服务商的 ALIAS 实现缺陷而非 App Platform 本身。2.2 DNS 验证失败的四步定位法当控制台显示“DNS 验证失败”时不要急着删掉重配。按以下顺序执行95% 的问题能在 5 分钟内定位确认记录类型与目标值完全匹配登录你的 DNS 管理后台逐字核对 App Platform 控制台生成的 CNAME 目标值。注意your-app.ondigitalocean.app.末尾带点和your-app.ondigitalocean.app无点在 DNS 协议中是不同记录。App Platform 生成的值末尾带点表示绝对域名你的 DNS 后台如果自动补点会导致双点..解析失败。实测命令dig short app.yourcompany.com CNAME | tr -d \n | od -c查看末尾是否为\n换行符而非.。检查 DNSSEC 是否启用DNSSEC 会对 DNS 响应进行数字签名但 App Platform 的验证服务不支持验证 DNSSEC 签名。如果你的域名开启了 DNSSEC常见于 Cloudflare 免费版必须暂时关闭。验证命令dig yourcompany.com DNSKEY short若返回非空结果则 DNSSEC 已启用。验证 TTL 值是否过长TTLTime-To-Live决定 DNS 记录在递归解析器中的缓存时间。App Platform 要求 TTL ≤ 300 秒5 分钟。超过此值其验证服务可能读取到过期缓存。修改后用dig nocmd noall answer -t CNAME app.yourcompany.com检查返回的 TTL 值。绕过本地 DNS 缓存直连权威服务器本地nslookup或dig可能受系统 DNS 缓存影响。用dig 8.8.8.8 app.yourcompany.com CNAME直连 Google DNS或dig 1.1.1.1 app.yourcompany.com CNAME直连 Cloudflare DNS验证排除本地网络干扰。注意App Platform 的 DNS 验证服务有 15 分钟冷却期。如果连续 3 次验证失败它会暂停轮询需等待 15 分钟或手动触发“重新验证”。这是防爆破机制不是故障。我曾因脚本化重试触发此限制白白等了 15 分钟后来学会先用dig确认无误再点验证。3. SSL 配置Let’s Encrypt 自动化背后的证书生命周期管理App Platform 的 SSL 配置页面只有一个开关“Enable Automatic TLS Certificate”。打开即生效无需上传证书、无需配置私钥。这种“零配置”体验的背后是 DigitalOcean 深度集成 Let’s Encrypt 的 ACME 协议实现。但“自动”不等于“无脑”它有一套严格的证书生命周期管理规则违反任一规则都会导致ssl: certificate_verify_failed或unable to get local issuer certificate。核心在于理解 ACME 协议的三个阶段域名验证Domain Validation→ 证书签发Certificate Issuance→ 证书续期Certificate Renewal而 App Platform 把前两步压缩为一次操作但续期是独立运行的后台任务。3.1 域名验证失败的三大根源与修复Let’s Encrypt 的域名验证DV采用 HTTP-01 或 DNS-01 挑战。App Platform 默认使用 HTTP-01它会在你的应用根路径下临时创建一个/.well-known/acme-challenge/xxx文件并向公网发起 HTTP GET 请求。如果请求失败证书就签发不了。失败原因绝非“网络不通”这么简单应用路由拦截了/.well-known路径这是最高频的坑。你的 Express.js 应用写了app.use(*, (req, res) res.sendFile(index.html))导致所有未匹配路由都返回 SPA 的index.htmlACME 验证请求被重定向返回 200 但内容是 HTML 而非挑战文本。修复方案在静态文件中间件前显式放行/.well-known// Express.js 示例 app.use(/.well-known, express.static(path.join(__dirname, .well-known))); app.use(express.static(public));提示.well-known是 IETF 标准目录用于存放 Web 服务元数据如安全策略、密钥信息。App Platform 的 ACME 客户端只读取此路径不会扫描其他位置。CDN 或反向代理缓存了 404 响应如果你已配置 CDN且 CDN 缓存了/.well-known/acme-challenge/xxx的 404 响应TTL 通常设为 1 小时那么 ACME 客户端后续请求会直接命中 CDN 缓存永远收不到 200。修复在 CDN 控制台添加缓存规则强制/.well-known/*路径不缓存Cache-Control: no-cache。防火墙或安全组阻止了 80 端口入站Let’s Encrypt 的 HTTP-01 挑战必须通过 HTTP端口 80完成。App Platform 默认开放 80 端口但如果你的应用组件如数据库、缓存也暴露在公网安全组可能误封 80 端口。验证curl -I http://app.yourcompany.com/.well-known/acme-challenge/test若返回Connection refused则 80 端口不通。3.2 证书续期失败的静默杀手OCSP Stapling 与缓存Let’s Encrypt 证书有效期为 90 天App Platform 在到期前 30 天自动续期。但续期成功 ≠ 浏览器信任。关键在 OCSPOnline Certificate Status ProtocolStapling服务器在 TLS 握手时主动向 Let’s Encrypt 的 OCSP 服务器查询证书吊销状态并将响应“钉”Staple在握手消息中发送给客户端。如果 App Platform 的 OCSP Stapling 失败浏览器会自行发起 OCSP 查询而某些网络环境如企业防火墙、部分移动运营商会屏蔽 OCSP 查询导致ssl: certificate_verify_failed。这不是证书问题而是网络策略问题。App Platform 的 OCSP Stapling 依赖两个条件OCSP 响应缓存有效App Platform 会缓存 OCSP 响应 4 小时。如果缓存过期且无法联网获取新响应Stapling 失败。CDN 节点未污染 OCSP 响应如果你启用了 CDNCDN 节点可能缓存了旧的 OCSP 响应TTL 通常很长。当 App Platform 续期新证书后CDN 仍返回旧 OCSP 响应浏览器校验失败。实操心得我处理过一个案例客户在七牛云 CDN 配置了Cache-Control: public, max-age315360001 年导致 OCSP 响应被缓存一年。解决方案不是关 CDN而是添加精准缓存规则/.well-known/acme-challenge/*和*.ocsp.int-x3.letsencrypt.orgLet’s Encrypt OCSP 服务器域名设为no-cache。这样既保 CDN 加速又不污染证书状态。3.3 手动干预证书何时以及如何上传自定义证书App Platform 允许上传 PEM 格式证书certificate.crtprivate.key但仅限两种场景内部 CA 签发的证书如企业内网应用需用公司内部根证书签发。特殊合规要求如金融行业要求 RSA-3072 密钥长度而 Let’s Encrypt 默认 RSA-2048。上传流程有严格校验私钥必须未加密openssl rsa -in private.key -check应输出RSA key ok。若提示Enter pass phrase for private.key:说明私钥有密码必须解密openssl rsa -in private.key -out private-decrypted.key。证书链必须完整certificate.crt必须包含服务器证书 中间证书Intermediate CA顺序为服务器证书在前中间证书在后。用openssl crl2pkcs7 -nocrl -certfile certificate.crt | openssl pkcs7 -print_certs -noout检查链长度应 ≥2。域名匹配必须精确证书的Subject Alternative NameSAN必须包含你绑定的域名且大小写敏感。www.yourcompany.com和yourcompany.com是两个不同域名需同时列出。注意上传自定义证书后App Platform不再自动续期。你必须在证书到期前手动上传新证书否则到期即变“不安全”。这是硬性规则无例外。我见过客户因忘记续期凌晨 3 点收到大量用户投诉“网站打不开”实则是证书过期浏览器直接阻断连接。4. CDN 配置不只是“开启加速”而是重构内容交付链路App Platform 的 CDN 开关名为 “Enable CDN”但开启后它并非简单地在用户和你的应用之间加一层缓存代理。它重构了整个内容交付链路用户 → CDN 边缘节点 → App Platform 应用实例。这个链路中CDN 不是透明管道而是主动参与者——它决定哪些请求直通Pass-through哪些缓存Cache哪些重写Rewrite。配置错误轻则加速失效重则引发ssl handshake failed error code 525Cloudflare 错误码表示 CDN 无法与源站建立 SSL 连接或未能创建ssl/tls安全通道。4.1 CDN 缓存行为的四大控制维度App Platform 的 CDN 缓存策略由四个维度共同决定缺一不可维度作用默认值关键配置项影响示例缓存键Cache Key决定哪些请求视为“相同”共享一个缓存副本Host Path Query String可排除Query String中的utm_*参数?utm_sourcegoogle和?utm_sourcefacebook被视为不同缓存浪费空间缓存生存时间TTL缓存副本在边缘节点的存活时间300 秒5 分钟可为不同路径设置不同 TTL如/static/设为315360001 年HTML 页面 TTL 过长导致用户看不到最新内容缓存忽略Cache Ignore强制不缓存的请求特征Cookie头存在时可添加X-No-Cache: true头触发忽略用户登录态页面含 Cookie默认不缓存避免泄露缓存状态码Cache Status Codes哪些 HTTP 状态码可被缓存200, 203, 204, 206, 300, 301, 302, 303, 304, 307, 308, 404, 405, 410, 414, 451, 501可添加418Im a teapot等自定义状态码404页面被缓存用户持续看到旧版 404提示ssl handshake failed error code 525的根源常在此。CDN 节点尝试用 HTTPS 连接你的 App Platform 源站但源站未正确配置 SSL如证书过期、域名不匹配CDN 无法建立 TLS 连接故返回 525。这不是 CDN 故障而是源站 SSL 配置问题。验证方法在 CDN 节点所在地区如新加坡用curl -v https://your-app.ondigitalocean.app模拟连接看是否报SSL certificate problem。4.2 静态资源 CDN 化为什么icon 图标显示有误往往是路径问题现代前端框架Vue/React打包后index.html中的资源引用如link relstylesheet href/css/app.css浏览器会相对index.html的 URL 解析路径。当你启用 CDN 后index.html仍由 App Platform 直接提供未缓存但/css/app.css会被 CDN 缓存并从边缘节点返回。问题来了如果index.html中的路径是/css/app.cssCDN 会向https://your-app.ondigitalocean.app/css/app.css回源这没问题但如果路径写成./css/app.css相对路径CDN 回源时会拼接当前 URL变成https://app.yourcompany.com/css/app.css而你的 App Platform 源站并不监听app.yourcompany.com的 443 端口它只响应your-app.ondigitalocean.app导致 404。更隐蔽的是icon 图标显示有误link relicon href/favicon.ico。如果favicon.ico在 CDN 缓存中但index.html中的href路径与 CDN 配置的缓存规则不匹配如 CDN 规则只缓存/static/*而favicon.ico在根目录CDN 会回源但源站返回 404浏览器就显示默认图标或空白。修复方案分两步前端构建时指定公共路径Public PathVue CLI 的vue.config.js中设publicPath: https://cdn.yourcompany.com/Webpack 的output.publicPath https://cdn.yourcompany.com/。这样所有资源引用都变成绝对 CDN URL。CDN 配置精准缓存规则在 App Platform CDN 设置中为https://cdn.yourcompany.com/*添加规则缓存/static/,/css/,/js/,/images/,/favicon.ico等路径TTL 设为 1 年并排除所有带?v版本号的请求避免缓存污染。实操技巧用curl -I https://cdn.yourcompany.com/css/app.css检查响应头。成功缓存应有X-Cache: HIT和Cache-Control: public, max-age31536000若为X-Cache: MISS说明缓存未命中需检查路径匹配规则。4.3 CDN 与 SSR/动态内容的协同避免缓存污染用户数据CDN 缓存是“无状态”的它不理解你的应用逻辑。如果你的应用是服务端渲染SSR如 Next.js/user/profile页面根据用户 Cookie 渲染不同内容而 CDN 默认缓存所有200响应就会导致用户 A 看到用户 B 的个人资料。这不是 Bug是缓存策略与业务逻辑的冲突。App Platform 提供两种解法禁用动态路径缓存在 CDN 设置中添加规则Path: /user/*Action:Bypass Cache。所有/user/下的请求直通源站不缓存。基于请求头的缓存键定制高级选项可将Cookie或Authorization头的部分字段如session_id加入缓存键。这样session_idabc和session_iddef被视为不同缓存。但需谨慎过多唯一缓存键会降低缓存命中率增加源站压力。注意steam下载cdn重定向这类热词反映了一个通用现象——CDN 重定向是双刃剑。App Platform 的 CDN 会自动将 HTTP 请求重定向到 HTTPS301并将www子域名重定向到非www或反之取决于你绑定的主域名。这个重定向发生在 CDN 层用户感知为“秒开”但如果你的应用代码里还有window.location.href http://的硬编码就会形成重定向循环。务必在前端代码中统一使用协议无关 URL//cdn.yourcompany.com/style.css。5. 三层联动排错当ssl/tls协议信息泄露漏洞(cve-2016-2183)警告出现时安全扫描工具如 Nessus、OpenVAS常报告ssl/tls协议信息泄露漏洞(cve-2016-2183)即 Sweet32 漏洞指出服务器支持 64 位分组密码如 3DES易受碰撞攻击。App Platform 的 TLS 配置是托管的你无法直接修改 OpenSSL 配置但可以影响其行为。这个警告的出现往往不是 App Platform 的锅而是三层配置联动失衡的结果。5.1 漏洞报告的真凶CDN 与源站的 TLS 版本协商错位App Platform 的源站 TLS 配置是安全的默认启用 TLS 1.2/1.3禁用 TLS 1.0/1.1且密码套件排除所有弱算法包括 3DES。但 CDN 层如果使用第三方 CDN如 Cloudflare可能配置了宽松的 TLS 版本兼容性。例如Cloudflare 免费版默认启用 TLS 1.0 以兼容老旧客户端当用户通过 Cloudflare 访问时TLS 握手在 CDN 与用户间完成CDN 再用 TLS 1.2 与 App Platform 源站通信。安全扫描工具扫描的是你对外的域名app.yourcompany.com它看到的是 CDN 的 TLS 配置而非源站。验证方法# 扫描 CDN 端点对外暴露的 nmap --script ssl-enum-ciphers -p 443 app.yourcompany.com # 扫描 App Platform 源站内部端点 nmap --script ssl-enum-ciphers -p 443 your-app.ondigitalocean.app若前者报告TLS_RSA_WITH_3DES_EDE_CBC_SHA而后者无则问题在 CDN。5.2 三层配置一致性检查清单当遇到任何 SSL/TLS 相关异常如exception in invoking authentication handler [ssl: certificate_verify_failed]、未能创建ssl/tls安全通道按此清单逐项检查确保三层一致层级检查项工具/命令合规标准不合规后果DNS 层域名解析是否指向正确源站dig short app.yourcompany.com CNAME返回your-app.ondigitalocean.app.DNS 劫持用户访问假站点SSL 层证书链是否完整且未过期openssl s_client -connect app.yourcompany.com:443 -servername app.yourcompany.com 2/dev/nullopenssl x509 -noout -dates -text | grep -E (Not BeforeNot AfterCDN 层CDN 是否启用 HTTPS 回源curl -I https://app.yourcompany.com查看Via头Via头包含 CDN 厂商标识如cloudflare且X-Forwarded-Proto: httpsCDN 用 HTTP 回源源站拒绝ssl handshake failed应用层应用是否信任 CDN 的转发头检查应用代码中X-Forwarded-Proto处理对X-Forwarded-Proto: https的请求返回Strict-Transport-Security头HSTS 失效HTTP 请求不自动跳转 HTTPS最后分享一个小技巧App Platform 的日志系统会记录所有 TLS 握手失败事件。在控制台进入 “Metrics Logs” → “Logs”筛选levelerror和message~tls能快速定位是 DNS 解析失败、证书吊销还是 CDN 回源超时。我处理过的最棘手案例就是日志里一条tls: first record does not look like a TLS handshake最终发现是客户在 CDN 配置了错误的端口转发把 HTTPS 流量转到了源站的 HTTP 端口80导致协议错乱。所以别猜看日志。