如何查看AWS RDS Postgres t2 micro实例连接来源及排查连接数过高问题

我之前维护t2.micro实例时也碰到过一模一样的连接数暴增、实例挂掉的情况，给你分享一套我实际用过的排查和解决流程，亲测有效：

既然现在实例已经无响应，先优先把服务拉起来：

• 如果连SSH都登不上，直接通过AWS控制台重启实例（提醒下：如果是有状态服务，重启会丢失内存里的临时数据，要是能通过AWS Systems Manager的Run Command执行命令，优先选这个方式）
• 要是能远程执行命令，先临时清理异常连接：比如执行sudo ss -K dst :<你的服务端口>（把<你的服务端口>换成实际的80、443或者22）强制关闭目标端口的所有连接，或者直接重启服务sudo systemctl restart <服务名>（比如nginx、apache）

这一步是找到“谁在疯狂连你的实例”的关键：

• 查看所有活跃连接：登录实例后，用ss -tulpn命令比netstat更高效，它会列出所有TCP/UDP的监听、已建立连接，包括来源IP、端口，还有对应的进程PID和名称。参数解释下：-t是TCP，-u是UDP，-l显示监听状态，-p关联进程，-n直接显示IP/端口数字（不解析域名，更快）
• 统计来源IP的连接数：执行这条命令能直接按连接数排序，找出最“活跃”的IP：

  netstat -anp | grep ESTABLISHED | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -nr
  

  它会输出类似120 192.168.1.100这样的结果，前面的数字是连接数，后面是来源IP，一眼就能定位到异常来源。
• 检查异常进程：拿到上面命令里的PID后，用ps aux | grep <PID>查看对应的进程，确认是不是你自己部署的合法服务，有没有陌生的恶意进程（比如挖矿木马、恶意脚本）在偷偷创建连接。
• AWS层面查流量：如果你的实例在VPC里，开启了VPC Flow Logs的话，去CloudWatch里搜对应的日志，能过滤出所有进入实例的流量，包括来源IP、端口、数据包大小，甚至能看到连接的建立/断开记录。要是没开的话，现在赶紧开一个，后续排查问题会很有用。

找到来源后，针对性分析原因：

• 如果是合法业务流量：那大概率是你的服务突然被大量访问（比如被爬虫盯上、或者业务推广带来的突发流量），t2.micro本身资源有限（1核CPU+1G内存），连接数过高直接耗尽资源导致无响应。这种情况要么升级实例规格（比如换成t3.medium），要么加个负载均衡+Auto Scaling，分摊流量压力。
• 如果是恶意流量（DDoS、暴力破解）：
  • 先在安全组里临时拉黑异常IP，或者限制端口的访问范围（比如SSH只允许你的办公IP访问，业务端口只放通CDN/负载均衡的IP）
  • 开启AWS Shield Basic（免费）缓解基础DDoS攻击，要是攻击强度大，直接升级到Shield Advanced
  • 去系统日志里找线索：比如/var/log/auth.log看有没有SSH暴力破解尝试，/var/log/nginx/access.log（或Apache的日志）看Web服务的访问记录，确认是不是爬虫或者恶意扫描。
• 如果是内部进程异常：比如你的应用程序有内存泄漏、死循环，导致不断创建新连接（比如数据库连接池没释放、程序逻辑错误发起大量请求）。这种情况要查应用日志，用top/htop看CPU、内存占用，用lsof -p <PID>看进程打开的所有文件和连接数，定位代码层面的问题。

避免以后再踩坑：

• 设置CloudWatch告警：监控实例的TCP_Connections指标，当连接数超过阈值（比如70，留够缓冲空间）就触发邮件/短信告警，提前发现问题
• 限制连接数：给服务设置连接数上限，比如nginx里配置worker_connections，应用层调整连接池大小，防止资源被耗尽
• 安全加固：关闭不必要的端口，用密钥对代替密码登录SSH，安全组遵循最小权限原则，定期更新系统和应用补丁
• 日志集中管理：把实例的系统日志、应用日志都同步到CloudWatch Logs，方便后续快速排查问题

内容的提问来源于stack exchange，提问作者kishore kumar vadde