ARTICLE DETAIL

资讯详情

深耕编程入门与网站建设的一线实战洞察。

【项目部署上线|第9篇】服务器端口、防火墙和日志排查实战

【项目部署上线|第9篇】服务器端口、防火墙和日志排查实战 前言前面已经完成了 Docker Compose、Nginx 反向代理和前后端分离部署。到这一步项目已经可以运行但真正的线上环境还需要考虑三个问题哪些端口应该开放到公网外部访问失败时怎么排查项目报错后应该先看哪些日志很多部署问题并不是代码错误而是端口、防火墙、容器状态、日志路径或磁盘空间导致的。这一篇就把这些问题集中整理形成一套可复用的排查思路。本篇主要学习服务器端口暴露原则云服务器安全组和 Linux 防火墙Docker 端口映射Nginx、Spring Boot、Docker 日志排查常见状态码和故障定位磁盘、内存、CPU 资源排查建立基础部署检查清单一、部署后的推荐网络结构经过前面几篇部署后推荐结构如下公网用户 | | 80 / 443 v Nginx | | 127.0.0.1:8080 v Spring Boot 容器 | | Docker 内部网络 |-- mysql:3306 | |-- redis:6379公网通常只开放80 443不建议直接开放8080 3306 6379文字说明端口越少暴露面越小。在普通项目中服务推荐访问方式Nginx公网 80、443Spring Boot仅宿主机本地或 Docker 内部MySQLDocker 内部网络RedisDocker 内部网络数据库和 Redis 一旦暴露公网容易遭遇扫描、弱密码攻击和误操作风险。二、限制 Spring Boot 端口只允许本机访问Docker Compose 中后端端口可以写成backend:ports:-127.0.0.1:8080:8080不要直接写backend:ports:-8080:8080文字说明两种写法区别-8080:8080表示宿主机所有网卡都能访问 8080外部用户也可能直接访问。-127.0.0.1:8080:8080表示只有宿主机本地能访问 8080。这样 Nginx 可以访问http://127.0.0.1:8080但外部用户只能通过 Nginx 的 80 或 443 端口访问项目。修改 Compose 配置后重新创建后端容器dockercompose up-d--force-recreate backend三、MySQL 和 Redis 不映射公网端口如果 MySQL、Redis 只需要被后端容器访问那么 Compose 中不需要写ports:-3306:3306也不需要写ports:-6379:6379MySQL 配置示例mysql:image:mysql:8.0networks:-project-netRedis 配置示例redis:image:redis:7.2networks:-project-net后端通过mysql:3306 redis:6379访问它们即可。文字说明如果本地需要使用 Navicat、DataGrip 或 RedisInsight 连接服务器上的容器服务可以临时映射端口并且限制防火墙来源 IP。不要为了方便长期把 MySQL 和 Redis 对公网完全开放。四、云服务器安全组即使 Linux 防火墙开放了端口云服务器还可能被安全组拦截。一般需要在云平台控制台检查入站规则。推荐规则端口协议建议22TCP仅允许自己的固定 IP 登录 SSH80TCP允许公网 HTTP 访问443TCP允许公网 HTTPS 访问8080TCP不建议开放3306TCP不建议开放6379TCP不建议开放文字说明安全组相当于云服务器外层防火墙。如果浏览器访问超时但 Nginx、本机端口都正常就要检查云平台安全组。五、Ubuntu 使用 UFW 管理防火墙查看防火墙状态sudoufw status开放 SSHsudoufw allow22/tcp开放 HTTPsudoufw allow80/tcp开放 HTTPSsudoufw allow443/tcp启用 UFWsudoufwenable查看详细规则sudoufw status numbered删除规则sudoufw delete 编号文字说明启用 UFW 前必须先确保 SSH 端口已放行。否则可能出现防火墙开启后自己无法再远程连接服务器的问题。六、CentOS 使用 firewalld 管理防火墙查看 firewalld 状态sudosystemctl status firewalld查看已开放服务sudofirewall-cmd --list-services开放 HTTPsudofirewall-cmd--permanent--add-servicehttp开放 HTTPSsudofirewall-cmd--permanent--add-servicehttps重新加载规则sudofirewall-cmd--reload查看开放端口sudofirewall-cmd --list-ports文字说明如果需要临时开放某个端口例如测试 8080sudofirewall-cmd --add-port8080/tcp但测试结束后应该关闭或仅允许指定来源 IP。七、查看服务器端口占用查看所有监听端口ss-tunlp查看 Nginx 是否监听 80ss-tunlp|grep:80查看 HTTPS 是否监听 443ss-tunlp|grep:443查看 Spring Boot 是否监听 8080ss-tunlp|grep:8080文字说明常见结果如下LISTEN 0 511 0.0.0.0:80 LISTEN 0 511 0.0.0.0:443 LISTEN 0 4096 127.0.0.1:8080其中0.0.0.0:80表示监听所有网卡可以被外部访问。127.0.0.1:8080表示只监听本机外部不能直接访问。这正是我们希望的部署状态。八、Docker 容器状态排查查看 Compose 服务dockercomposeps查看所有容器dockerps-a查看后端容器dockercomposepsbackend查看容器重启次数dockerinspect-f{{.RestartCount}}project-backend查看容器资源使用dockerstats文字说明如果后端容器不断重启先看dockercompose logs--tail200backend常见原因MySQL 连接失败Redis 密码错误配置文件读取失败JVM 内存不足Spring Boot 启动异常端口冲突九、建立日志排查顺序项目访问异常时不建议随机看日志。可以按下面顺序排查浏览器或 curl 请求 | v Nginx access log | v Nginx error log | v Spring Boot 容器日志 | v Spring Boot 文件日志 | v MySQL / Redis 容器日志1. Nginx 访问日志sudotail-f/var/log/nginx/project-access.log2. Nginx 错误日志sudotail-f/var/log/nginx/project-error.log3. Spring Boot 容器日志dockercompose logs-fbackend4. Spring Boot 文件日志tail-f/opt/project/compose/backend/logs/app.log5. MySQL 日志dockercompose logs-fmysql6. Redis 日志dockercompose logs-fredis十、使用 traceId 串联一次请求前面项目扩展实战系列中已经使用过traceId。前端或客户端请求时可以带上X-Trace-Id: test-request-001例如curlhttp://www.example.com/api/product/1\-HX-Trace-Id: test-request-001后端日志中如果配置了[%X{traceId}]就可以通过greptest-request-001/opt/project/compose/backend/logs/app.log找到这一次请求的全部相关日志。文字说明当接口经过Nginx - Spring Boot - MySQL - Redis时traceId 能帮助我们定位同一次请求。它比只看时间更可靠尤其适合并发请求较多的场景。十一、常见状态码排查状态码常见含义优先检查404请求路径不存在前端路径、Nginx location、Controller 路径401未登录或 Token 失效Authorization 请求头、JWT 配置403没有权限权限校验、跨域预检、Nginx 规则413上传文件过大Nginx、Spring Boot 上传限制500后端业务或系统异常Spring Boot 日志、数据库状态502Nginx 无法连接后端后端容器、8080 端口、Nginx proxy_pass504后端响应超时慢 SQL、长任务、Nginx 超时配置文字说明状态码不是最终原因但可以快速缩小排查范围。例如502优先检查 Nginx 到 Spring Boot 的连接。500优先检查 Spring Boot 应用日志。413优先检查 Nginx 和 Spring Boot 的上传文件大小限制。十二、502 Bad Gateway 排查步骤出现502 Bad Gateway时按下面顺序检查。1. 查看后端容器是否运行dockercomposepsbackend2. 查看后端日志dockercompose logs--tail200backend3. 在宿主机测试后端curlhttp://127.0.0.1:80804. 检查 Nginx 代理地址proxy_pass http://127.0.0.1:8080;5. 检查端口监听ss-tunlp|grep:8080文字说明如果curlhttp://127.0.0.1:8080都失败说明问题大概率在后端容器。如果本机访问成功但域名访问 502则优先检查 Nginx 配置和日志。十三、504 Gateway Timeout 排查步骤出现504 Gateway Timeout表示 Nginx 等待后端响应超时。排查方向查看 Spring Boot 日志是否卡在某个请求查看 MySQL 慢查询查看 Redis 是否连接超时查看接口是否调用第三方服务查看服务器 CPU、内存是否不足检查 Nginxproxy_read_timeout查看系统负载top查看内存free-h查看磁盘df-h文字说明504 不是简单把超时时间调大就能解决。如果接口本身过慢需要回到业务和数据库层排查。例如是否缺少索引是否存在 N1 查询是否查询了过多数据是否应该使用分页是否应该使用缓存是否需要异步任务十四、磁盘空间排查查看磁盘使用情况df-h查看项目目录大小du-sh/opt/project查看 Docker 占用dockersystemdf查看日志目录大小du-sh/var/log/nginxdu-sh/opt/project/compose/backend/logs文字说明服务器磁盘满了以后可能出现MySQL 无法写数据Redis AOF 无法持久化日志无法写入Docker 无法创建容器项目运行异常日志滚动和定期清理非常重要。查看 Docker 中无用资源dockersystemdf清理前先确认资源是否还在使用。不建议在生产环境直接执行破坏性清理命令。十五、内存和 CPU 排查查看内存free-h查看 CPU、内存和进程top查看 Docker 容器资源dockerstats查看 Java 进程ps-ef|grepjava文字说明如果服务器内存较小Spring Boot、MySQL、Redis 同时运行可能导致内存不足。可以适当限制 JVMJAVA_OPTS-Xms256m -Xmx512m也可以在 Compose 中限制资源但具体参数应根据服务器配置和业务压力评估。不要在内存不足时只盲目提高 JVM 最大堆内存否则可能导致整个服务器更容易失去响应。十六、检查 Docker Compose 配置当环境变量或服务配置有问题时可以执行dockercompose config这个命令会输出 Compose 解析后的最终配置。可以检查环境变量是否被正确替换端口映射是否正确网络配置是否正确容器挂载路径是否正确服务名是否拼写错误文字说明如果.env文件没有生效docker compose config是很有价值的排查命令。但输出中可能包含敏感配置执行和截图时要注意脱敏。十七、服务启动检查清单项目部署或重启后可以按下面顺序检查1. docker compose ps 2. docker compose logs --tail 100 mysql 3. docker compose logs --tail 100 redis 4. docker compose logs --tail 200 backend 5. curl http://127.0.0.1:8080 6. sudo nginx -t 7. sudo systemctl status nginx 8. curl http://服务器IP 9. 浏览器访问域名如果步骤 5 成功、步骤 8 失败优先检查Nginx 防火墙 安全组如果步骤 4 失败优先检查Spring Boot 配置 MySQL Redis 环境变量十八、实际开发建议公网只开放 80、443SSH 端口尽量限制来源 IP。Spring Boot 使用ports:-127.0.0.1:8080:8080避免直接暴露 8080。MySQL、Redis 不要映射公网端口优先通过 Docker 内部网络访问。日志要分层查看Nginx 日志看入口Spring Boot 日志看业务MySQL 和 Redis 日志看依赖服务。修改 Nginx、Compose、环境变量后要先检查再重载或重建服务。遇到问题时先保存日志和配置现场不要上来就删除容器、清空数据目录或强制重启。十九、总结这一篇我们围绕部署后的运维排查完成了以下内容规划公网端口和内部端口使用 Docker 绑定后端本地端口使用云安全组和 Linux 防火墙控制访问查看服务器监听端口查看 Docker 容器状态和资源使用建立 Nginx、Spring Boot、MySQL、Redis 的日志排查顺序使用 traceId 定位一次请求排查 404、413、500、502、504 等常见问题检查磁盘、内存和 CPU 资源建立部署后的基础检查清单到这里项目不只是“能部署起来”也具备了基本的排查和维护能力。下一篇可以继续写 HTTPS 证书、域名配置和自动续期把项目从 HTTP 部署推进到正式可访问的 HTTPS 环境。
返回列表