python应用本身不处理https终止和http→https跳转，这两件事必须交给nginx等反向代理完成；python代码只负责正确信任证书（如显式指定verify路径），禁用verify=false以免主动破坏安全。
直接说结论：Python应用本身不处理HTTPS终止和HTTP→HTTPS跳转，这两件事必须交给前端反向代理（如Nginx、Caddy或IIS）来做；Python代码里只负责信任证书（verify）、不硬编码verify=False，否则等于主动拆掉安全锁。
为什么不能在Flask/FastAPI里做HTTPS强制跳转
Flask的Werkzeug、FastAPI的Uvicorn、甚至Waitress都只是WSGI/ASGI服务器，它们默认只监听HTTP端口（如8000、7860），不原生支持TLS握手。你无法在代码里写“如果请求是HTTP，就301重定向到HTTPS”，因为——它根本收不到原始HTTP请求。一旦你把Python服务暴露在公网80/443端口上，就必须自己实现TLS终止，这涉及私钥管理、SNI、OCSP Stapling等复杂逻辑，极易出错且无必要。
常见错误现象：
- 在Flask中用
@app.before_request检查request.url.startswith("http://")然后redirect——这只能在已启用HTTPS的前提下“补救”，对直接访问http://的用户无效 - 用
gunicorn --bind 0.0.0.0:443 --certfile cert.pem --keyfile key.pem启动——看似启用了HTTPS，但Gunicorn的TLS支持极简，不处理SNI、不支持ALPN、无法配置OCSP，且私钥常驻进程内存，存在泄露风险
Nginx反向代理配置HTTPS与跳转的关键项
正确做法是让Nginx监听443（HTTPS）和80（HTTP），把443的解密后流量转发给Python服务的本地端口（如http://127.0.0.1:8000），同时让80端口返回301跳转。以下是必须核对的配置点：
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
-
ssl_certificate和ssl_certificate_key路径必须指向PEM格式的完整证书链（含中间CA），不是仅服务器证书；阿里云下载的fullchain.pem和privkey.pem可直接用 -
ssl_protocols TLSv1.2 TLSv1.3——禁用TLSv1.0/v1.1，避免POODLE等漏洞 -
ssl_prefer_server_ciphers off——现代浏览器更倾向使用客户端推荐的加密套件 - HTTP跳转必须用
return 301 https://$host$request_uri;，不能用rewrite，否则$request_uri中的查询参数可能丢失 - 务必在
server { listen 443 ssl; }块内添加add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;，开启HSTS
Python客户端调用时的证书验证陷阱
当你的Python应用要调用其他HTTPS服务（比如调用Let's Encrypt API、对接企业内网Spring Boot接口），requests或httpx默认会校验对方证书。若目标服务用的是自签名证书或私有CA签发的证书，就会报SSLCertVerificationError。这时不能全局设verify=False，而应：
- 把私有CA的根证书（PEM格式）保存为
/etc/ssl/certs/my-ca.crt，然后执行sudo update-ca-certificates（Ubuntu/Debian）或sudo trust anchor --store my-ca.crt（CentOS/RHEL） - 或者在代码中显式指定：
requests.get(url, verify="/path/to/my-ca.crt")或httpx.Client(verify="/path/to/my-ca.crt") - 避免把证书路径写死成相对路径（如
"./ca.pem"），生产环境工作目录不确定；用Path(__file__).parent / "ca.pem"更可靠 - 注意
certifi包会覆盖系统CA路径，若你升级了certifi，可能使之前通过update-ca-certificates添加的私有CA失效
Let’s Encrypt自动续期与Python服务零中断
Certbot的certonly --nginx会修改Nginx配置并重载，但如果你用的是--standalone或--webroot，需确保Python服务不占用80端口。更稳妥的做法是：
- 用
--webroot模式，把.well-known/acme-challenge/路径映射到Nginx的静态目录，Python服务完全不参与验证过程 - 续期命令后加
--deploy-hook "systemctl reload nginx"，确保新证书加载 - 不要依赖
systemd timer直接跑certbot renew，因权限问题可能导致证书文件属主错误；改用root用户的crontab，并明确指定--non-interactive --quiet - 检查
/etc/letsencrypt/live/example.com/下的fullchain.pem和privkey.pem是否始终是符号链接——这是Certbot自动更新的机制，硬链接或复制会导致续期失败
最易被忽略的一点：所有日志、监控、健康检查探针（如Kubernetes的livenessProbe）都必须用HTTPS地址发起请求。曾有团队在Nginx配好HTTPS后，忘记改Prometheus的抓取目标，结果监控一直显示服务“Down”，排查三天才发现是探针还在用HTTP连。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
