1. 为什么在DigitalOcean上构建认证API不是“配个Nginx就完事”的事“Creating an Authenticated API on DigitalOcean”——这个标题乍看平平无奇像一句技术文档里的常规操作提示。但如果你真在DigitalOcean Droplet上部署过API尤其是面向生产环境、需要对接前端应用、第三方服务或内部系统调用的API你很快就会发现认证Authentication从来不是加一行Authorization: Bearer xxx就能闭环的事而是一整套基础设施级的决策链。我2019年第一次在DO上跑一个用户管理微服务时就栽在这句话上。当时以为只要用Flask-JWT生成token、Nginx反向代理到Gunicorn再加个auth_required装饰器就算“完成认证API”。结果上线第三天日志里开始出现大量401 Unauthorized但奇怪的是——这些请求的token全都是合法签发、未过期、签名验证通过的。排查了两天最后发现是前端在跨域场景下没带credentials: include导致浏览器压根没把Authorization头发过来而我们的错误响应体只写了{error: Unauthorized}连具体失败原因都没返回运维同事只能靠抓包猜。更糟的是我们把JWT密钥硬编码在Python文件里Git提交记录里还留着secret_key dev-secret-123——这已经不是“不安全”而是把门钥匙焊死在门框上还贴了张纸条“请进”。这就是DigitalOcean环境下的真实水位线它给你干净的Linux实例、可控的网络层、透明的资源监控但它不替你做任何安全决策。你不会像在Vercel或Cloudflare Workers里那样被强制要求用Edge Config做Token校验也不会像AWS API Gateway那样默认集成Cognito身份池。你在DO上拥有的是自由代价是必须亲手定义每一道防线的材质、厚度和安装位置。所以“Creating an Authenticated API on DigitalOcean”的本质是在IaaS层构建一套可审计、可扩展、可防御的访问控制体系。它涉及四个不可割裂的层面传输层加固HTTPS是否真正端到端Let’s Encrypt证书是否自动续期TLS版本与密码套件是否规避已知弱点认证机制选型是用无状态JWT承载用户身份还是用有状态SessionRedis做会话管理OAuth 2.0的Client Credentials Flow是否比Bearer Token更适合后端服务间调用授权策略落地API网关层如Nginx能否做基础路由级权限拦截业务逻辑层如何实现RBAC基于角色的访问控制或ABAC基于属性的访问控制凭证生命周期治理API Token如何生成、分发、轮换、吊销2FA双因素认证是否仅用于管理员登录还是也延伸至高危API操作如删除数据库这些决策没有标准答案。一个为IoT设备提供固件更新的API可能只需要简单的API Key Header校验而一个处理金融交易的支付回调接口则必须强制使用mTLS双向认证短时效JWT操作级审计日志。DigitalOcean不预设你的业务敏感度它只提供让你能精准匹配业务风险的工具箱。这也是为什么那些热搜词里反复出现remote: invalid username or token、authentication fails (governor)、exception in invoking authentication handler [ssl: certificate_verify_failed]——它们不是孤立的报错而是上述四个层面中某一处配置失准的外在症状。比如certificate_verify_failed表面是SSL证书问题深层可能是Let’s Encrypt ACME客户端如certbot配置了错误的DNS验证方式导致证书链不完整Nginx配置中ssl_trusted_certificate指向了过期的根证书包后端服务如Python requests库未正确加载系统CA证书而依赖自建证书路径。你无法靠搜索报错信息直接定位根因因为同一错误码背后可能是Droplet系统层、Nginx配置层、应用代码层、甚至上游CDN如Cloudflare证书设置层的任意一环出了问题。在DigitalOcean上做认证API本质上是在训练一种“全栈归因能力”——从TCP三次握手开始一层层向上推演直到找到那个被忽略的ssl_verifyFalse硬编码开关。所以这篇文章不会教你“三步配置JWT”而是带你重走一遍我在DO上交付7个认证API项目后沉淀下来的决策树当面对一个新需求时如何快速判断该用哪种认证模式Nginx到底该承担多少鉴权逻辑哪些安全措施必须写死在代码里哪些可以交给基础设施以及——最重要的是当Postman里弹出401时你该先查哪5个日志文件2. 认证模式选型JWT、API Key、Session、OAuth 2.0哪个才是你的Droplet“原生适配器”在DigitalOcean Droplet上选择认证方案核心原则只有一条让安全机制的复杂度严格匹配你的实际攻击面与运维能力。没有“最安全”的方案只有“最不易被你自己搞崩”的方案。我见过太多团队为追求“企业级安全”在单台Droplet上硬上KeycloakLDAPOIDC结果因为内存不足导致认证服务频繁OOM最终用户登录成功率还不如用JWT。下面这张表是我根据过去三年在DO环境中的实测数据整理的四种主流认证模式对比所有参数均基于Ubuntu 22.04 Nginx 1.18 Python 3.10Flask/FastAPI环境认证模式典型适用场景部署复杂度1-5内存开销MB/1k并发JWT密钥轮换难度最易踩坑点实测首年故障率API Key Header内部服务调用、IoT设备上报、CI/CD流水线触发25极低纯字符串替换Key明文写入配置文件、无失效机制、无调用频控12%多为Key泄露Stateless JWT前端SPA应用、移动App、需无状态横向扩展315-25中需同步密钥到所有节点签名算法误用HS256 vs RS256、过期时间设为0、未校验iss/aud28%多为token盗用重放Redis Session传统Web应用、需强会话控制如踢出在线用户480-120含Redis进程高需滚动更新Redis Key前缀Session ID未绑定User-Agent/IP、Redis未启用密码认证、过期策略混乱19%多为Redis宕机导致全站登出OAuth 2.0 Client Credentials后端服务间通信、微服务网格、需精细Scope控制540-60含Auth Server极高需维护独立Auth ServerScope粒度失控如read:*、Token刷新逻辑缺陷、PKCE缺失35%多为配置错乱导致循环重定向提示这里的“故障率”指因认证模块自身缺陷非业务逻辑错误导致的P0/P1级线上事故比例统计周期为API上线后首12个月。数据来源我参与的7个DO项目运维日志匿名化处理。2.1 API Key Header被严重低估的“轻量级王者”很多人觉得API Key太原始不如JWT“高级”。但在DO这种IaaS环境里它恰恰是最稳健的选择。原理极其简单客户端在HTTP Header中发送X-API-Key: abc123服务端从数据库或配置文件中查该Key对应的权限集匹配则放行。为什么它在Droplet上表现优异零依赖不需要额外进程如Redis、不依赖外部服务如Auth Server整个认证逻辑可内嵌在应用代码里启动即生效。调试直观Nginx access log里直接能看到X-API-Key值需配置log_format出问题时一眼定位是Key无效还是Header未发送。轮换成本极低生成新Key、停用旧Key、更新客户端配置三步完成无需重启服务。但它的致命陷阱在于密钥管理。我曾接手一个项目其API Key存储方式如下# config.py —— 错误示范 API_KEYS { prod-service: sk_live_abc123def456, staging-bot: sk_test_xyz789uvw012 }这个文件被提交到Git并被Docker镜像打包。结果某次安全扫描发现该仓库在GitHub上是公开的——所有Key瞬间失效。正确做法是将Key存于Droplet的/etc/secrets/api_keys.json权限设为600属主为运行应用的非root用户如www-data应用启动时读取该文件而非硬编码使用systemd服务文件注入环境变量# /etc/systemd/system/myapi.service [Service] EnvironmentFile/etc/secrets/api_env.conf # 内容API_KEY_PATH/etc/secrets/api_keys.json注意EnvironmentFile路径必须绝对路径且api_env.conf文件权限同样需为600。这是很多教程忽略的关键细节——如果环境变量文件可被普通用户读取等同于密钥裸奔。2.2 Stateless JWT当“无状态”成为双刃剑JWT在DO上流行是因为它完美契合Droplet的弹性——你可以水平扩展N台Droplet只要共享同一个密钥认证逻辑就天然一致。但它的“无状态”特性在运维层面埋下了深坑。最常见的错误是混淆HS256与RS256。HS256用对称密钥签名服务端用同一密钥验签RS256用非对称密钥服务端用公钥验签私钥只存在于Auth Server。很多团队为图省事全站用HS256结果密钥一旦泄露如Droplet被入侵攻击者不仅能伪造token还能解密payload里的敏感字段如user_id。而RS256虽安全却要求你必须在Droplet上安全地分发和更新公钥——如果公钥文件放在/var/www/public/.well-known/jwks.json就得确保Nginx禁止对该路径的写入权限否则攻击者可上传恶意公钥。另一个隐形杀手是时间漂移。JWT的exp过期时间是Unix时间戳依赖服务器时钟。Droplet默认使用systemd-timesyncd同步时间但若网络波动导致NTP同步失败服务器时间慢了5分钟那么所有刚签发的token都会被判定为“已过期”。解决方案不是禁用NTP而是在应用启动时用ntpq -p检查NTP同步状态在JWT解析逻辑中添加leeway参数如5秒容忍短暂时间偏差关键业务如支付的token有效期设为15分钟而非24小时缩短漂移影响窗口。2.3 Redis Session当“有状态”成为刚需如果你的应用需要实时踢出用户如管理员封禁账号、限制单用户并发登录数、或记录详细登录设备信息那么Session是唯一选择。但在DO上这意味着你必须额外部署并维护Redis。这里有个关键经验永远不要用默认配置启动Redis。Droplet的RAM有限而Redis默认配置会尝试使用所有可用内存。必须修改/etc/redis/redis.conf# 必须设置防止OOM Killer干掉Redis maxmemory 256mb maxmemory-policy allkeys-lru # 内存满时LRU淘汰 # 安全红线 requirepass your_strong_redis_password # 密码至少16位随机字符 bind 127.0.0.1 ::1 # 仅监听本地禁止公网暴露 protected-mode yes然后在应用中用密码连接Redis# FastAPI示例 from redis import Redis redis_client Redis( hostlocalhost, port6379, passwordyour_strong_redis_password, # 明文密码不应从环境变量读取 decode_responsesTrue )注意password参数必须显式传入不能依赖redis.conf里的requirepass——因为某些Redis客户端库如旧版redis-py会忽略配置文件密码导致连接失败却报错模糊。2.4 OAuth 2.0 Client Credentials别为“标准”牺牲可维护性OAuth 2.0是标准但在单Droplet场景下自己搭Auth Server如Authlib Flask往往是灾难。我曾帮一个客户迁移他们用Django OAuth Toolkit实现了完整的Authorization Code Flow结果因为Droplet内存只有1GB每次OAuth重定向都触发Swap响应延迟飙到8秒。后来我们砍掉所有OAuth组件改用JWTScope白名单性能提升4倍。Client Credentials Flow机器对机器是唯一值得在DO上考虑的OAuth子集。它不需要用户交互适合服务间调用。但实施要点是Scope必须精确到API端点而非宽泛的read:data。例如GET:/v1/users/me和DELETE:/v1/users/{id}应是两个独立ScopeToken必须短期有效建议15-30分钟且应用层强制实现自动刷新逻辑绝不复用同一Client ID于不同环境dev/staging/prod每个环境分配独立Client Secret。3. Nginx不只是反向代理而是你的第一道认证防火墙在DigitalOcean Droplet上Nginx绝非可有可无的“流量入口”。它是离攻击者最近的组件也是你能在基础设施层施加最多控制的环节。很多团队把所有认证逻辑堆在应用层结果Nginx只干两件事转发请求、返回502。这等于把城门大开指望城内的士兵应用代码去拦截每一个可疑路人——效率低且容易漏防。Nginx能做的认证工作远超你的想象。以下是我在线上环境稳定运行两年的Nginx认证配置模板已去除所有注释仅保留生产必需项# /etc/nginx/sites-available/myapi upstream api_backend { server 127.0.0.1:8000; # Gunicorn/FastAPI keepalive 32; } server { listen 443 ssl http2; server_name api.example.com; # SSL证书由certbot自动管理 ssl_certificate /etc/letsencrypt/live/api.example.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/api.example.com/privkey.pem; ssl_trusted_certificate /etc/letsencrypt/live/api.example.com/chain.pem; # TLS安全加固 ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384; ssl_prefer_server_ciphers off; ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m; # 关键API Key基础校验白名单模式 map $http_x_api_key $valid_api_key { default 0; sk_live_abc123def456 1; sk_live_ghi789jkl012 1; } # 关键JWT Bearer Token校验需nginx-plus或第三方模块 # 此处使用开源的nginx-jwt模块需编译安装 jwt_key_file /etc/nginx/jwt_public_key.pem; jwt_header_name Authorization; jwt_key_name kid; jwt_require_exp on; jwt_require_iat on; jwt_require_iss https://api.example.com; # 路由级权限控制 location /v1/admin/ { if ($valid_api_key 0) { return 403; } proxy_pass http://api_backend; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } location /v1/users/ { # 所有/user/路径必须携带有效JWT auth_jwt API Realm; auth_jwt_key_request /_jwks; proxy_pass http://api_backend; } # JWKS端点供Nginx动态获取公钥 location /_jwks { internal; proxy_pass https://www.googleapis.com/oauth2/v3/certs; # 示例Google公钥 proxy_cache jwks_cache; proxy_cache_valid 200 302 1h; proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504; } # 拒绝所有未匹配location的请求 location / { return 404; } }这段配置揭示了Nginx作为认证网关的三大核心能力3.1 静态API Key白名单最快最糙的防线map指令将X-API-KeyHeader映射为$valid_api_key变量值为0或1。if ($valid_api_key 0)直接返回403。这招的优势在于毫秒级拦截在请求进入应用前就被拒绝不消耗任何Python进程资源日志可追溯Nginx access log中$http_x_api_key字段清晰记录每次尝试的Key值零应用侵入应用代码完全不用处理Key校验专注业务逻辑。但它的局限也很明显无法做细粒度权限如某个Key只能读不能写、无法吊销单个Key需重启Nginx。因此它最适合用于可信的内部服务调用比如CI/CD流水线触发部署的Webhook。3.2 JWT动态验签把公钥管理交给Nginx原生Nginx不支持JWT验签需编译nginx-jwt模块推荐或使用OpenResty。其精髓在于将JWT验签这一CPU密集型操作从应用层卸载到Nginx层。当Nginx收到Authorization: Bearer ey...时它会解析JWT header提取kidKey ID向/_jwks端点发起请求获取对应kid的公钥用该公钥验证JWT signature与claims如exp,iss验证通过后将JWT payload中的字段如user_id,scope注入$jwt_claim_user_id等变量供后续proxy_set_header传递给后端。这带来的好处是颠覆性的应用层彻底解脱后端收到的请求X-User-IDHeader已是可信值无需再解析JWT公钥自动轮换JWKS端点返回的公钥集可包含多个kidNginx会缓存并自动选择匹配的公钥无需重启性能飙升Nginx用C语言验签比Python的PyJWT快5-8倍尤其在高并发场景。注意/_jwks必须设为internal禁止外部直接访问。且proxy_cache配置至关重要——若每次验签都请求远程JWKS将引入网络延迟和单点故障。3.3 路由级权限隔离用location切分信任域Nginx的location块是天然的权限边界。上面配置中/v1/admin/路径只认白名单API Key且不校验JWT/v1/users/路径强制JWT认证且JWT必须包含iss为https://api.example.com其他所有路径如/v1/debug/直接404。这种设计实现了纵深防御即使攻击者绕过了JWT校验如利用应用层漏洞他也无法访问/admin/路径因为那道门由Nginx单独把守。更重要的是它让权限策略变得可审计、可配置化——运维人员只需修改Nginx配置就能调整路由权限无需动一行应用代码。4. 实战排错当Postman显示“401 Unauthorized”你该查的5个日志文件在DigitalOcean Droplet上调试认证问题最忌讳“凭感觉改代码”。我见过太多开发者在401报错后第一反应是修改Python里的auth_required装饰器结果折腾半天发现根本原因是Nginx没把AuthorizationHeader透传给后端。真正的排错是从网络栈底层开始一层层向上验证。以下是我在DO环境中建立的标准排错清单按执行顺序排列覆盖95%的认证失败场景4.1 第一站Nginx access log —— 确认请求是否抵达路径/var/log/nginx/access.log关键命令# 查找最近10分钟内所有401响应 sudo tail -n 1000 /var/log/nginx/access.log | awk $9 401 {print} | tail -n 20 # 查看特定请求的完整Header需Nginx配置log_format包含$http_authorization sudo tail -f /var/log/nginx/access.log | grep POST /v1/login你要找的核心证据请求是否真的到达Nginx如果log里完全没有该请求记录说明问题在DNS、防火墙DO Cloud Firewall或负载均衡器如DO Load BalancerAuthorizationHeader是否出现在log中如果log显示-空值说明客户端根本没发送该Header或被中间代理如公司Proxy剥离$status字段是否为401如果是403说明Nginx的map或if规则拦截了如果是502说明后端服务没起来。提示确保Nginxlog_format包含$http_authorization。默认格式不记录Header需在/etc/nginx/nginx.conf中修改log_format main $remote_addr - $remote_user [$time_local] $request $status $body_bytes_sent $http_referer $http_user_agent $http_x_forwarded_for $http_authorization;4.2 第二站Nginx error log —— 捕捉Nginx层的“内心独白”路径/var/log/nginx/error.log关键命令# 查看最近的错误特别是JWT相关 sudo tail -n 100 /var/log/nginx/error.log | grep -i jwt\|auth\|ssl # 实时监控在Postman发请求时执行 sudo tail -f /var/log/nginx/error.log典型错误及根因JWT: failed to parse token: invalid character→ 客户端发送的token格式错误如多了空格、用了中文引号JWT: key not found for kid xxx→ JWKS端点返回的公钥集中没有kidxxx的条目需检查Auth Server的密钥轮换逻辑SSL_do_handshake() failed (SSL: error:14094418:SSL routines:ssl3_read_bytes:tlsv1 alert unknown ca)→ Nginx配置的ssl_trusted_certificate路径错误或证书链不完整。4.3 第三站应用服务日志 —— 确认请求是否送达后端路径取决于你的服务管理方式Systemd服务sudo journalctl -u myapi.service -n 50 -fDocker容器sudo docker logs --tail 50 -f myapi_container直接运行tail -f /var/log/myapi/app.log你要验证的关键点日志中是否有该请求的记录如果没有说明Nginx的proxy_pass配置错误如端口不对、upstream名称不匹配如果有记录但显示Missing Authorization header说明Nginx未透传Header。检查proxy_set_header配置proxy_set_header Authorization $http_authorization; # 必须显式设置 proxy_pass_request_headers on; # 确保开启如果应用日志显示Invalid token signature但Nginx error log无报错说明JWT验签在应用层进行且密钥不匹配——此时需核对应用代码中的密钥与Nginx配置的密钥是否一致。4.4 第四站SSL/TLS诊断 —— 当certificate_verify_failed出现时当Python/Node.js应用报ssl: certificate_verify_failed根源往往不在应用代码而在Droplet的证书信任库。执行以下命令诊断# 1. 检查系统CA证书是否最新 sudo apt update sudo apt install -y ca-certificates sudo update-ca-certificates --fresh # 2. 测试对目标域名的SSL握手如调用第三方API openssl s_client -connect api.thirdparty.com:443 -servername api.thirdparty.com # 3. 检查应用使用的CA路径以Python为例 python3 -c import ssl; print(ssl.get_default_verify_paths())常见修复方案如果update-ca-certificates后问题依旧手动将第三方API的根证书.pem文件追加到/usr/local/share/ca-certificates/再执行sudo update-ca-certificates在Python requests中显式指定CA路径import requests response requests.get(https://api.thirdparty.com, verify/etc/ssl/certs/thirdparty-root.pem)绝对禁止在代码中写verifyFalse——这是自毁长城。4.5 第五站网络连通性验证 —— 排除基础设施层干扰有时401只是表象真实问题是网络不通。用以下命令逐层验证# 1. 检查Droplet是否能访问外部API如Lets Encrypt curl -I https://acme-v02.api.letsencrypt.org/directory # 2. 检查Droplet防火墙ufw是否阻止出站 sudo ufw status verbose # 3. 检查DO Cloud Firewall是否限制了源IP如你的Postman IP # 登录DO控制台 - Networking - Firewalls - 查看Inbound规则 # 4. 检查DNS解析是否正常避免因DNS污染导致请求发错地方 dig api.example.com short nslookup api.example.com 8.8.8.8 # 强制用Google DNS一个真实案例某客户API一直返回401查遍所有日志都无异常。最后发现他们的DO Cloud Firewall规则中Inbound规则允许0.0.0.0/0但Outbound规则却限制为仅允许访问10.0.0.0/8——导致Nginx在请求JWKS时被防火墙静默丢弃返回空响应Nginx JWT模块自然验签失败。这种问题只看应用日志永远找不到。5. 生产就绪 checklist上线前必须完成的12项安全加固在DigitalOcean Droplet上发布认证API不是git push然后systemctl restart nginx就完事。我总结了一套经过7个项目验证的上线前Checklist每一项都对应一个真实踩过的坑。少做任何一项都可能在凌晨3点收到告警电话。5.1 基础设施层Droplet OS安全更新运行sudo apt update sudo apt full-upgrade -y重启Droplet禁用root密码登录sudo passwd -l root仅允许SSH密钥登录创建专用非root用户如apiuser应用服务以该用户身份运行。DO Cloud Firewall最小化开放Inbound仅开放443/tcpHTTPS、22/tcpSSH限制源IPOutbound默认允许但为JWKS等关键依赖添加显式规则如443/tcptogoogleapis.com绝对禁止开放80/tcpHTTP——所有HTTP请求应301重定向到HTTPS。Nginx SSL证书自动续期使用certbot的--deploy-hook在证书更新后自动重载Nginxsudo certbot renew --deploy-hook systemctl reload nginx验证续期sudo certbot renew --dry-run。5.2 认证机制层API Key/Token轮换策略所有生产Key必须设置到期时间如6个月并在到期前15天邮件通知负责人实现Key吊销接口如POST /v1/admin/revoke-key并记录吊销日志禁止在Git中提交任何Key使用DO的Spaces或Managed Databases加密存储。JWT安全加固exp过期时间≤ 15分钟iat签发时间必须校验iss签发者和aud受众必须严格匹配且aud应为具体API域名签名算法强制使用RS256私钥存于Droplet的/etc/ssl/private/jwt.key权限600。Session安全如使用Redis密码必须16位以上随机字符且定期轮换Session Cookie设置Secure、HttpOnly、SameSiteStrict实现/v1/auth/logout接口主动删除Redis中的Session Key。5.3 应用与日志层应用进程保护使用systemd管理服务配置Restarton-failure、MemoryLimit512M禁止应用以root身份运行Userapiuser、Groupapiuser在/etc/systemd/system/myapi.service中添加ProtectSystemstrict、PrivateTmpyes。日志审计与保留Nginx access log必须记录$http_authorization、$request_time、$upstream_response_time应用日志级别设为INFO记录所有认证成功/失败事件含IP、User-Agent、Key/Token ID日志文件按天轮转保留≥90天sudo logrotate -f /etc/logrotate.d/myapi。速率限制Rate LimitingNginx层对/v1/auth/login路径限流limit_req zoneauth burst5 nodelay应用层对API Key做调用频控如1000次/小时超限返回429 Too Many Requests限流规则需持久化如存Redis避免重启丢失。5.4 监控与应急层关键指标监控Nginx401、403响应率阈值5%告警应用认证失败次数/分钟突增200%告警Redisused_memory80%告警、rejected_connections0立即告警。应急响应预案准备一键脚本快速吊销所有API Key# revoke_all_keys.sh mysql -u root -p myapi_db -e UPDATE api_keys SET revoked1, updated_atNOW(); systemctl reload nginx # 清空Nginx map缓存预置emergency-maintenance.html当认证服务崩溃时Nginx可快速返回该页面。渗透测试基线使用nuclei扫描常见认证漏洞nuclei -u https://api.example.com -t cves/ -t technologies/ -severity high,critical手动验证尝试Authorization: Bearer空token、Authorization: Basic空Basic、X-API-Key:空Key确认返回一致的401而非堆栈信息。最后分享一个血泪教训某次上线我漏掉了第2项Cloud Firewall Outbound限制导致JWKS请求失败。但监控只告警了401率升高没人想到是防火墙问题。结果花了3小时排查才发现Outbound规则里少了一行443/tcp to googleapis.com。从此我的上线Checklist第一条就是“打开DO控制台