FastAPI应用部署至Azure后路由访问返回404问题求助
FastAPI应用部署至Azure后路由访问返回404问题求助
我完全理解你现在的困扰——本地测试正常的FastAPI部署到Azure后,所有路由都返回404,这确实让人摸不着头脑。咱们结合你提供的代码、部署配置来一步步排查可能的问题:
一、先修复部署配置的明显语法错误
你提供的GitHub Actions部署YAML文件存在致命语法错误,这极可能直接导致部署失败,代码根本没上传到Azure:
- name: 'Deploy to Azure Web App' uses: azure/webapps-deploy@v3 id: deploy-to-webapp with: app-name: 'watkanikladenapi' slot-name: 'Productio
这里slot-name的值只写了'Productio,缺少结尾的n和闭合引号',YAML解析会直接失败。请立即修复为:
slot-name: 'Production'
修复后重新触发部署,先确认GitHub Actions的部署日志显示“成功”,再进行后续排查。
二、确保Azure Web App的启动配置生效
你尝试用startup.sh启动应用,但这个方式容易遇到权限、路径识别问题,更可靠的方式是直接在Azure Portal配置启动命令:
- 登录Azure Portal → 你的Web App → 配置 → 通用设置
- 在“启动命令”栏填写:
gunicorn -w 4 -k uvicorn.workers.UvicornWorker main:app - 保存配置,Azure会自动重启应用。
如果坚持用startup.sh,需要:
- 确保脚本在部署包根目录(即
site/wwwroot下) - 在GitHub Actions的打包步骤前添加权限赋予命令:
chmod +x startup.sh
三、验证应用是否真的启动成功
404最核心的原因通常是应用未启动或路由未注册,你可以通过以下方式确认:
- 访问FastAPI自动文档:
尝试访问https://watkanikladenapi.azurewebsites.net/docs或/redoc,如果这两个页面也返回404,说明FastAPI完全没启动。 - 查看Azure日志流:
进入Azure Portal → 你的Web App → 监控 → 日志流,查看是否有:- Gunicorn启动日志:比如
Listening at: http://0.0.0.0:8000 - FastAPI启动日志:比如
Application startup complete.
如果没有这些日志,说明启动命令执行失败,可能是依赖安装失败、Python版本不兼容。
- Gunicorn启动日志:比如
四、检查路由访问路径与环境配置
- 确认路由地址正确性:
你的/chargers路由的完整访问地址应为:https://watkanikladenapi.azurewebsites.net/chargers
不要添加多余前缀(比如/api/chargers),除非你在FastAPI中配置了根路径前缀。 - Python版本一致性:
你在GitHub Actions中用了Python 3.10,需确保Azure Web App的Python版本也设置为3.10:
在Azure Portal → 配置 → 通用设置 → Python版本中选择3.10。
五、依赖与数据库的补充排查
虽然这些不会直接导致404,但会影响路由功能:
- PyODBC驱动安装:
Azure Linux Web App默认没有ODBC Driver 18,你可以修改启动命令,先安装驱动再启动应用:sudo apt-get update && sudo apt-get install -y msodbcsql18 && gunicorn -w 4 -k uvicorn.workers.UvicornWorker main:app - 数据库连接参数:
确认get_db_connection中的server、database等占位符//已经替换为实际的Azure SQL信息,避免访问路由时触发500错误。
快速验证步骤
- 修复GitHub Actions YAML语法错误,重新部署;
- 在Azure Portal设置启动命令并重启应用;
- 查看日志流确认应用启动成功;
- 访问
/docs和/chargers测试路由。
按照这个顺序排查,应该能快速定位问题根源。
备注:内容来源于stack exchange,提问作者Adnane Bady Soussi
相关产品推荐
相关产品推荐

