ECS已运行但网页打不开：用curl区分服务故障与浏览器拦截

今天把一个单文件2048小游戏部署到ECS时，遇到一个容易误判的现象：云服务器显示“运行中”，Chrome打开公网地址却报ERR_BLOCKED_BY_CLIENT。继续改安全组前，先补了一次独立HTTP验证，结果服务本身已经正常响应。下面记录这次排查方法。

1. 把“实例运行”和“网站可用”分开确认

本次环境为EulerOS 3.0、Nginx，静态文件放在/usr/share/nginx/html/hc-activity/index.html，访问路径为/hc-activity/index.html。初始化脚本负责安装Nginx、写入文件并启动服务。

控制台的“运行中”反映实例状态，不能据此断定安装脚本已经完成。尤其首次启动还要下载软件包时，应给初始化留出时间，再验证具体HTTP路径。

2. 从独立环境请求完整URL

我在另一个沙箱终端里请求ECS公网地址。下面用占位地址展示命令，请替换成自己的实例公网IP：

curl --connect-timeout 5 --max-time 10 -s \
  -o /tmp/ecs-page.html -w 'HTTP %{http_code}\n' \
  http://YOUR_ECS_PUBLIC_IP/hc-activity/index.html

grep -Eo '<title>[^<]+</title>' /tmp/ecs-page.html

本次实际输出是：

HTTP 200
<title>2048</title>

-o保存响应正文，-w单独输出状态码，两个超时参数限制等待时间。再检查标题，是为了减少把Nginx欢迎页等其他页面误当成目标页面的可能。标题仍只是轻量验证；它不能替代实际试玩和交互检查。本次游戏的方向键、合并计分等交互此前已在沙箱中单独验证。

3. 按证据决定下一步

如果请求超时，优先核对公网IP、端口、访问路径以及服务监听情况，不要一次改动多个配置。

如果返回404，说明已经拿到HTTP响应，应先核对文件是否位于当前站点的文档根目录、URL是否多写或少写了路径。若返回200但内容不对，应检查站点配置与实际响应正文。

本次独立请求已返回200及目标标题，而Chrome仍显示ERR_BLOCKED_BY_CLIENT。这两条证据提示应继续排查浏览器或客户端侧的拦截；仅凭错误名，不能确定是哪一个扩展、代理或策略造成的。没有必要为了这个现象额外开放SSH、其他端口或把安全组全部放开。

4. 保存证据，再清理临时资源

我记录了完整路径、HTTP状态和页面标题，提交部署结果后，再释放此次临时ECS、系统盘及公网IP，并分别检查三个资源列表。这样既能确认部署确实完成，也能避免只删除计算实例却留下其他按需资源。

这次排查最有用的一步，是换一个独立请求入口验证同一个URL。先定位故障发生在哪一层，再做最小改动，通常比反复重建服务器更省时间。

本文根据本次实际部署过程整理，文字由AI辅助组织并按实测结果核对。