一次网络服务配置测试的踩坑经历

前两天公司新上了一套内部系统，部署完之后怎么都访问不了。页面打不开，接口调不通，开发同事急得直拍桌子。作为负责这块的运维，我只好从头开始查问题——这其实就是一次典型的网络服务配置测试过程。

先从最基础的端口查起

服务跑在服务器上，第一步就是确认它有没有真正在监听端口。用 netstat 命令一查：

netstat -tulnp | grep :8080

结果啥也没出来。这就奇怪了，明明启动日志显示服务已运行。再翻应用配置文件，发现 bind 地址写的是 127.0.0.1，难怪外部连不上。改成 0.0.0.0 后重启，端口终于监听上了。

防火墙常是“隐形杀手”

本以为这下能通了，结果还是不行。这时候想到服务器自带的防火墙。CentOS 默认开了 firewalld，得手动放行端口：

firewall-cmd --zone=public --add-port=8080/tcp --permanent
firewall-cmd --reload

加完规则刷新一下，外网立马就能访问到欢迎页了。有时候就是这么简单，但卡住的时候真够折磨人。

别忘了反向代理这一环

后来把服务接入 Nginx 做反向代理，地址变成了域名访问。可改完配置 reload 的时候报错：

nginx: [emerg] unknown directive "proxy_paaath" in /etc/nginx/conf.d/app.conf:5

眼尖一点就能发现，proxy_pass 被手滑写成了 proxy_paaath。这种拼写错误在配置里太常见了，尤其是赶时间的时候。改完再 reload，一切正常。

自动化测试让流程更稳

吃过几次亏后，我们写了简单的 shell 脚本，每次部署完自动检查：端口是否监听、服务进程是否存在、HTTP 状态码是否为 200。比如这个小脚本：

#!/bin/bash
if curl -s http://localhost:8080 | grep -q "Welcome"; then
    echo "[OK] Service is running"
else
    echo "[ERROR] Service check failed"
fi

虽然简单，但能在上线前快速发现问题，省了不少事后排查的时间。

其实网络服务配置测试没那么玄乎，关键就是一步步来：看服务、查端口、过防火墙、测访问、验代理。每一步都可能藏着小坑，但只要流程固定下来，日常维护就轻松多了。