Filebeat跨EC2实例向Logstash传输日志时遇连接拒绝错误

咱们一步步拆解你的问题，先从最容易混淆的配置点说起，再分析代理和连接的核心问题：

1. 先解决Prospectors vs Inputs的配置冲突 #

你当前的配置里同时写了filebeat.prospectors和filebeat.inputs，这是错误的——这两个配置是Filebeat不同版本的产物：

• prospectors是Filebeat 5.x到6.x版本的写法，在7.x及以后的版本里已经被废弃；
• inputs是7.x及以后版本的标准配置方式。

同时存在这两个配置会导致Filebeat的日志采集逻辑混乱，直接先删掉filebeat.prospectors整个区块，只保留filebeat.inputs部分。

2. SOCKS5代理配置的核心误解 #

你的错误日志显示dial tcp 10.0.0.10:5044: getsockopt: connection refused，这里大概率是你混淆了SOCKS5代理的地址和Logstash的地址：

• output.logstash.hosts应该是Logstash所在EC2实例的IP和端口（比如["10.0.0.20:5044"]）；
• proxy_url是SOCKS5代理服务器的地址和端口，而不是Logstash的地址！而且SOCKS5的默认端口是1080，你现在写的10.0.0.10:5044应该是Logstash的端口，这就导致Filebeat试图把Logstash当成SOCKS5代理去连接，对方自然不会响应SOCKS5的握手请求，直接拒绝连接。

另外补充一下：SOCKS5协议确实是基于TCP传输的，这个技术点你不用怀疑，问题出在配置对应关系上。

3. 修正后的配置示例 #

假设你的SOCKS5代理运行在10.0.0.10:1080，Logstash运行在10.0.0.20:5044，修正后的filebeat.yml应该是这样：

filebeat.inputs:
  - type: log
    paths:
      - /camel-logs/app.log

output.logstash:
  hosts: ["10.0.0.20:5044"]
  proxy_url: socks5://10.0.0.10:1080

4. 后续验证步骤 #

按照下面的步骤逐一验证，确保每一步都没问题：

• 验证SOCKS5代理可用性：在Filebeat所在的EC2实例上，用curl测试代理是否能连通Logstash：

  curl -x socks5://10.0.0.10:1080 http://10.0.0.20:5044
  

  只要不提示连接拒绝就说明代理通路正常（哪怕收到HTTP 400也没关系，因为Logstash用的是Beats协议而非HTTP）。
• 检查安全组/防火墙：
  • 确保Filebeat所在EC2能访问SOCKS5代理的端口（比如1080）；
  • 确保SOCKS5代理所在EC2能访问Logstash的5044端口；
• 重启Filebeat并查看日志：

  sudo systemctl restart filebeat
  journalctl -u filebeat -f
  

  实时查看日志，确认是否还有连接拒绝的错误。

内容的提问来源于stack exchange，提问作者Quinten Scheppermans