端口与体系
999 同样是多重登记：TCP 侧为 garcon 与 puprouter，UDP 侧为 applix 与 puprouter，其中 puprouter 属于早期网络协议族的遗留项。同一个端口号上挂着多个名称，是这个端口最需要说明的地方。
排查时的结论
对排查者而言，处理方式很直接：先确定传输层协议，再看进程归属，最后核算放行规则。用登记名去反推服务身份，在这类历史端口上几乎没有成功率。
基本信息
| 服务名称 | garcon、applix、puprouter |
|---|---|
| 传输协议 | TCP 与 UDP，两侧登记名不同 |
| 所属体系 | 早期网络与办公系统注册 |
| 当前状态 | 无公开实现 |
典型使用场景
- 协议与名称核对：整理同一端口号上的多个登记名
- 端口台账完善：把协议与登记名分开记录
- 扫描报告解读：核对扫描器是否覆盖 TCP 与 UDP 两侧
- 放行规则回收：两侧规则分别处理
- 自研服务命名核对：避免与历史登记名混淆
- 未知服务处置：无对应组件时按未知服务流程取证
分别查看两侧
分别查看两侧
# Linux：TCP 与 UDP 侧分别查看监听
ss -lntup | grep ':999 '
ss -lunp | grep ':999 '
# 交叉验证可执行文件归属
sudo lsof -i :999
# Windows：netstat 输出会标注 TCP 或 UDP
netstat -ano | findstr :999999 的登记构成
| 传输层 | 登记名 | 说明 |
|---|---|---|
| TCP | garcon 与 puprouter | 两个名称共存于同一端口号 |
| UDP | applix 与 puprouter | 协议族遗留名称 |
| 判读方式 | 按协议分别核对 | 不要合并为一条服务记录 |
多重登记在早期端口分配中并不罕见：项目更名、机构变更、预留端口复用都会留下多个名称。处理这类端口时按“协议加进程”两个维度记录，比按名称记录可靠得多。
如果这一端口在现网确实有监听，几乎可以确定不是这些历史服务本身，而是某个程序自行选用了它。此时按未知服务流程处置：记录进程路径、启动方式与连接来源，再决定动作。
同一端口号对应多个名称，会直接影响自动化比对的准确率：工具若只按名称匹配，就可能把真实占用判为误报。台账中同时记录协议、名称与进程，比对结果才可靠。