GitHub Actions部署Flask到Azure App Service后无法访问求助

核心问题分析 #

你的场景中，启动脚本手动SSH执行正常，但通过App Service配置的启动命令执行时，虽Gunicorn日志显示启动成功，却无法对外提供服务。这大概率是启动脚本的执行环境与手动执行环境不一致，或是启动脚本的权限/路径配置存在隐性问题。

可行修复方案 #

方案1：修正startup.sh的Python环境路径 #

App Service默认会使用内置的虚拟环境，直接用pip install可能将依赖安装到全局环境，导致Gunicorn启动时无法加载正确依赖。修改startup.sh，指定激活App Service的默认虚拟环境：

#!/bin/bash

# 激活App Service内置Python虚拟环境
source /opt/venv/bin/activate

python -m pip install --upgrade pip
pip install -r requirements.txt

# 启动Gunicorn服务
gunicorn -b 0.0.0.0:80 -w 4 --timeout 600 app:app

方案2：确保startup.sh拥有可执行权限 #

GitHub Actions部署过程中可能未保留文件的执行权限，导致App Service无法正常运行脚本。在部署步骤中添加赋予权限的操作：
在GitHub Actions的deploy任务里，下载artifact后新增一步：

- name: Grant execute permission to startup script
  run: chmod +x startup.sh

方案3：直接在App Service配置中指定完整启动命令 #

若脚本环境问题难以排查，可跳过startup.sh，直接在Azure Portal的App Service配置中设置启动命令：
进入App Service → 配置 → 常规设置 → 启动命令，输入：

/opt/venv/bin/python -m pip install --upgrade pip && /opt/venv/bin/pip install -r requirements.txt && /opt/venv/bin/gunicorn -b 0.0.0.0:80 -w 4 --timeout 600 app:app

通过直接指定虚拟环境的Python路径，彻底避免环境不一致问题。

验证排查步骤 #

1. 查看App Service的stderr日志流，可能存在启动脚本执行时的隐性错误（日志流中需切换到错误输出视图）
2. 在startup.sh开头添加echo $PATH >> /home/site/logs/path.log，对比手动执行时的$PATH环境变量，确认路径差异
3. SSH登录后执行netstat -tulpn | grep 80，验证Gunicorn进程是否真的绑定了0.0.0.0:80端口

内容的提问来源于stack exchange，提问作者SKY-BIRD Web Media