当 Nginx、MySQL 和 Redis 挤在同一台服务器：我的端口规划翻车实录

大家好，我是 33blog 的运维老司机。今天想和大家分享一个我最近遇到的真实案例——关于多服务共用服务器时的端口规划问题。这个坑我踩得实实在在，希望能帮到正在做类似架构设计的同行们。

1. 那个看似完美的省钱方案

上个月公司有个新项目要上线，为了节省成本（老板的原话），我决定把 Nginx、MySQL 和 Redis 都部署在同一台 4核8G 的云服务器上。”反正流量不大”，我当时这么想着，结果…

# 初始的端口分配：
Nginx  - 80/443
MySQL  - 3306
Redis  - 6379

看起来一切都很合理对吧？但问题很快就来了。

2. 第一个坑：SSH 连接被挤爆

项目上线第三天，我突然发现 SSH 连接变得异常缓慢。查看 netstat 才发现问题：

$ netstat -tulnp | grep 22
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1234/sshd
tcp6       0      0 :::22000                :::*                    LISTEN      5678/redis-server

原来 Redis 配置了从库同步，默认用了 22000 端口，而我们的 SSH 端口正好也是 22000！这个冲突导致运维人员经常连不上服务器。

3. 第二个坑：监控系统的误报

我们用的监控系统通过端口检测服务状态。某天凌晨突然收到 MySQL 宕机告警，爬起来检查却发现服务好好的。后来发现是 Redis 的持久化操作导致瞬时资源紧张，监控系统误以为 3306 端口不可用。

4. 我的血泪教训

经过这次折腾，我总结了几条经验：

• 预留端口段：我现在会给每类服务分配连续的端口段，比如 10000-10999 给数据库，20000-20999 给缓存
• 禁用高危端口：像 SSH 这种关键服务，一定要用非常用端口（建议 10000 以上）
• 使用端口别名：在 /etc/services 中添加自定义端口说明，避免后期混淆

# /etc/services 示例
myapp-mysql     15306/tcp   # 项目专用MySQL
myapp-redis     16379/tcp   # 项目专用Redis

5. 现在的标准做法

现在我部署多服务服务器时会这样做：

1. 先用 nmap localhost 扫描已用端口
2. 制作端口分配表格，标注用途和负责人
3. 关键服务配置端口监控+进程监控双重检测
4. 在 iptables 中添加端口使用注释

最后说句掏心窝的话：如果条件允许，还是尽量把服务分开部署。那些为了省小钱而混部服务带来的运维成本，往往比机器费用高得多。你们有没有类似的经历？欢迎在评论区分享你的故事~