2196 与 APNs 反馈服务
2196 对应 APNs（Apple Push Notification service）早期的反馈服务端口。推送服务端需要知道哪些设备令牌已经失效——App 被卸载后令牌不再有效——以便清理自己的推送列表，减少无效投递。早期的二进制提供方协议为此提供了独立的反馈通道：服务端定期连接 2196 取回失效令牌列表，发送通知则走 2195。现代 APNs 已改为在基于 HTTP/2 的提供方接口中用响应码（如 410 Unregistered）直接反馈失效，独立反馈端口随之停用，2196 只在老资料与老代码里出现。
基本信息
| 服务名 | APNs Feedback Service（历史） |
|---|---|
| 传输层 | TCP + TLS |
| 用途 | 取回失效设备令牌，清理推送列表 |
| 配对端口 | 历史发送通道使用 2195 |
| 现代方式 | HTTP/2 提供方接口，用响应码反馈失效 |
| 现状 | 旧二进制协议已弃用，该端口停用 |
典型使用场景
- 老推送服务排障：发送失败时区分是令牌失效还是连接问题
- 资产核对：盘点仍在使用旧推送协议的服务端程序
- 迁移评估：把推送链路迁到 HTTP/2 提供方接口，重建失效处理逻辑
- 合规检查：推送密钥与证书的存放、轮换是否符合要求
- 监控建设：统计无效令牌比例，评估清理策略是否有效
核查与迁移
核查与迁移
ss -lntup 'sport = :2196' # 是否还有监听
sudo lsof -i :2196 # 占用进程
# 老代码里常见的旧协议地址（应迁移到 HTTP/2 接口）：
grep -rn 'feedback.push.apple.com' . 2>/dev/null | head
# 迁移后检查点：响应码 410 是否被正确处理，失效令牌是否从库中清理推送链路组件对照
| 组件 | 承载 | 说明 |
|---|---|---|
| 提供方接口（现行） | HTTPS，HTTP/2 | 发送通知并返回状态码 |
| 反馈服务（历史） | TCP 2196 + TLS | 取回失效令牌列表 |
| 发送服务（历史） | TCP 2195 + TLS | 旧二进制协议发送通道 |
| 设备侧连接 | 5223 | 由系统维护，与提供方无关 |
老推送服务端若仍写死 feedback.push.apple.com:2196，在旧二进制协议被弃用后会直接报连接失败。处理方式不是找新端口，而是把推送链路整体迁到 HTTP/2 提供方接口，并把失效令牌处理改为按响应码驱动。
判断推送是否正常，要看服务端记录的响应码与送达统计，而不是端口是否可达。持续向失效令牌投递会浪费配额并污染统计口径，让真实送达率难以评估。