端口身份
456 在 IANA 以 macon-tcp 与 macon-udp 两个名字分别注册，登记人 Yoshinobu Inoue。同一个端口号分开登记 TCP 与 UDP 名称，说明提交方当时希望明确两种传输层都要占用；但这只反映登记意图，注册表里没有协议、报文格式或产品说明，公开资料中也查不到使用该端口的实现。这类双名注册在排查时要注意一点：ss 与 lsof 的结果需要同时看 TCP 与 UDP 两类记录，只查一侧会漏掉真正的监听进程。
基本信息
| 服务名 | macon-tcp / macon-udp |
|---|---|
| 协议 | TCP/UDP |
| 端口号 | 456 |
| IANA 登记说明 | macon（TCP 与 UDP 各一笔） |
| 登记机构 / 注册人 | Yoshinobu Inoue |
| 背景 | 双名注册 |
| 现状 | 无公开实现 |
| 默认放行 | 无（没有任何产品默认使用） |
排查与治理场景
- 端口扫描与资产测绘：结果里出现该端口，说明确实有进程在监听，不能只看端口号下结论
- 防火墙与安全组核对：确认是否真的要放行，默认应保持拒绝
- 流量告警研判：内网主机向外部地址发起该端口连接，通常属于异常外联信号
- 合规与端口清单审计：等保、内控检查要求说明每个在监听端口的业务归属
- 系统迁移与下线：迁移前确认该端口上是否还挂着历史服务，避免带着旧端口一起上线
定位占用该端口的进程
定位占用该端口的进程
ss -lntup 'sport = :456' # 列出监听中的 TCP/UDP 套接字，sport 按本地端口过滤
sudo lsof -i :456 # 需要 root 才能看到别人的进程，且会一并列出已建立连接
sudo ss -lntp 'sport = :456' # 普通用户看不到进程列时，用 sudo 重跑一次
ss -ntp 'sport = :456' # 去掉 l 参数：只看已建立的连接，排查外联行为
ls -l /proc/<PID>/exe # 由进程号反查可执行文件路径，确认程序来源
cat /proc/<PID>/cmdline # 查看启动参数，判断是常驻服务还是临时脚本
netstat -ano | findstr :456 # Windows 侧等价命令，最后一列是 PID
tasklist /fi "pid eq <PID>" # Windows 侧由 PID 反查进程名与所属服务ss 输出逐列读法
| 列 | 含义 | 正常与异常 |
|---|---|---|
| State | 套接字状态；LISTEN 为监听中，ESTAB 为已建立的连接 | 服务端口上出现非 LISTEN 状态，要结合对端地址一起判断 |
| Recv-Q / Send-Q | 接收队列与发送队列中待处理的字节数 | 监听套接字上长期非 0，说明连接没有被及时 accept |
| Local Address:Port | 本端监听地址与端口；0.0.0.0 表示所有网卡，127.0.0.1 仅本机可用 | 只想本机使用却监听在 0.0.0.0，就是对外暴露 |
| Peer Address:Port | 对端地址与端口；仅监听时显示为 *:* | 出现具体外部对端地址，说明已经建立了连接 |
| Process | users:(("名称",pid=,fd=)) 形式的进程信息 | 非 root 运行时该列可能为空，不代表端口没有所属进程 |
对无法归属的监听端口，处置顺序是：由进程号确认可执行文件路径与启动参数，记录连接对端，再与业务方核对；归属未明前不要在策略里放行。确认无用的，停用进程后还要检查开机自启来源（systemd 单元、crontab、rc.local）。
macon 在 456 上同时占用了 TCP 与 UDP 两个名字，排查时必须在 ss -lntup 的结果里同时确认 tcp 与 udp 两类记录，只查 TCP 会漏掉另一侧的监听者。
Windows 侧 netstat -ano 的列依次是 Proto、Local Address、Foreign Address、State、PID：LISTENING 为监听、ESTABLISHED 为已建立连接；PID 要用 tasklist /fi "pid eq <PID>" 反查进程名，tasklist /svc 可显示该 PID 归属的服务。