应用日志已经写进本机文件，中心平台却一直没有新记录，很多人先检查HTTP_PROXY。rsyslog的传统远程输出并不是网页上传：它可能使用UDP、TCP、RELP或带TLS的专用连接，是否支持HTTP代理取决于具体输出模块。
先识别实际输出方式
| 方式 | 可靠性特点 | 常见用途 |
|---|---|---|
| Syslog UDP | 开销低，无传输确认 | 可容忍少量丢失的局域网日志 |
| Syslog TCP | 有连接与字节重传 | 需要更稳定传输的集中日志 |
| RELP | 提供更明确的事务确认 | 重视交付确认的rsyslog链路 |
| HTTP输出 | 取决于模块与接口 | 发送到HTTP采集端点 |
普通HTTP代理只可能参与最后一类或厂商明确支持的HTTP链路，不能自动把TCP Syslog转换成HTTP。
“本地有日志”仍要确认输入规则
rsyslog可能没有读取目标文件、journald字段不匹配，或过滤规则在输出前丢弃了消息。先用带唯一标记的测试日志确认消息进入rsyslog，再观察规则命中和队列变化。不要使用真实用户数据或密钥作为测试内容。
UDP为什么难以证明交付
UDP发送端没有连接握手，内核接受报文不代表交换机、防火墙或接收端最终处理。突发流量超过缓冲区也可能无声丢包。对于审计、安全或计费日志，应根据风险选择TCP、RELP、持久队列和端到端对账，而不是只看进程无报错。
TCP连接正常也可能没有入库
接收端可能接受连接，却因消息过长、格式不符、租户标识错误、磁盘满或解析规则拒绝消息。发送端、负载均衡、接收服务和存储层要使用统一时间与请求标记对应起来，避免只截取网络连接状态。
TLS需要验证对端身份
Syslog over TLS不仅是打开一个加密端口。发送端要信任正确CA，并验证接收端证书名称或许可身份；接收端若要求客户端证书，还要正确管理私钥、用途和轮换。证书错误不应通过永久关闭校验解决。
队列决定故障时发生什么
内存队列速度快，但进程或主机重启时可能丢失未发送数据；磁盘辅助或磁盘队列可提高恢复能力，却需要容量、权限和告警。配置时要明确队列满后的动作，是阻塞、丢弃低优先级，还是保存到备用位置。
重试风暴与重复消息
接收端恢复后，大量积压日志同时重发会占满带宽和处理能力。设置合理退避与工作线程，并为平台准备容量。TCP重连或应用级重试也可能产生重复记录，下游分析不能假设每条消息天然唯一。
消息格式和分帧
RFC 3164风格、RFC 5424结构化消息以及TCP分帧方式可能不同。代理或负载均衡若按换行切分，而发送端使用八位组计数，接收端就会粘包或拆错。问题表现为连接正常、日志内容混乱或解析失败。
与日志采集代理的区别
Fluent Bit等工具可能把日志发往HTTP、OpenSearch或Forward协议，每种输出单独配置代理。相关分层方法可参考Fluent Bit输出协议与缓冲排查，但不要把它的HTTP配置原样套到rsyslog TCP输出。
故障处置清单
- 确认输入、过滤、模板和输出模块真实生效；
- 生成无敏感信息的唯一测试消息，记录UTC时间；
- 观察本地队列大小、丢弃计数和模块错误；
- 验证实际协议、端口、TLS证书和接收端身份；
- 检查接收端解析、磁盘、限流与存储状态；
- 模拟短时断网并验证积压恢复、重复与告警。
结论
rsyslog转发失败不能只问“代理通不通”。先证明日志进入规则和队列，再验证实际Syslog传输、TLS身份与接收端解析，才能判断消息是没有发送、路上丢失，还是到达后被拒绝。
