Mac OSX下Filebeat不发起Logstash连接、无日志发送问题排查

核心矛盾是Mac OSX的系统网络、Docker实现逻辑和Windows存在本质差异，哪怕配置完全一致，也会出现Windows上正常、Mac上功能失效的问题。

1. 跳过Filebeat，先验证基础网络连通性 #

• 首先查看当前运行容器的端口映射状态，执行：
  docker ps --format "table {{.Names}}\t{{.Ports}}"
  必须确认sebp/elk容器的输出里存在0.0.0.0:5044->5044/tcp的映射条目，没有的话先核对容器启动时的端口参数是否生效。
• 用系统自带的nc工具直接测试回环地址连通性，不要靠Filebeat的返回值判断：
  nc -vz 127.0.0.1 5044
  如果这一步基础连通都不通，问题100%出在系统或Docker网络层，和Filebeat本身无关。

2. 定位“Filebeat完全不发连接、不触发backoff重连”的原因 #

这种表现不是连接超时，是Filebeat压根没走到发起连接的执行逻辑，Mac环境下常见的触发点包括：

• 配置文件权限校验被静默拦截：Filebeat 7.x版本之后会严格校验配置文件权限，如果Mac下的filebeat.yml权限是全局可写（比如常见的777权限），Filebeat会直接丢弃Logstash输出段的配置，根本不会初始化输出逻辑，自然不会发起连接、也不会触发重连。把配置文件权限调整为600（仅所有者可读写）再启动验证即可。
• localhost默认解析到IPv6地址：Mac OSX从10.11版本开始，默认优先把localhost解析为IPv6的::1地址，而Docker的端口映射默认只绑定IPv4的0.0.0.0，根本没有监听IPv6回环地址。Windows环境下localhost默认优先解析到IPv4的127.0.0.1，所以同样的配置在Windows上完全正常，到Mac上就会出现连接直接被内核拒绝，甚至因为地址族不匹配，Filebeat的重试逻辑直接中断。
  修复方式：Filebeat的Logstash hosts配置里不要写localhost，直接写127.0.0.1:5044，绕过IPv6解析问题。
• macOS防火墙的内核级拦截：如果是通过DMG安装包安装的Filebeat，第一次启动时系统会弹窗询问是否允许网络访问，如果点击了拒绝，防火墙会在底层拦截所有出站流量，Filebeat层面拿不到任何连接报错，表现就是完全不发起连接、没有任何重连日志。去系统设置的防火墙选项里确认Filebeat是否在允许访问的列表中。

3. 排查Mac系统专属的端口占用问题 #

这是Windows和Mac环境差异最大、也最容易被忽略的细节：

• macOS从Monterey（12.x）版本开始，系统自带的隔空播放（AirPlay）接收器会默认占用TCP 5000-5049整段端口，其中就包含Logstash默认使用的5044端口。哪怕通过Docker映射了5044端口，实际流量会被系统服务优先拦截，Docker的端口转发根本收不到请求。
  验证方式：执行lsof -i :5044，如果看到占用进程是系统的隔空播放服务（进程名通常为controlce），就是被这个服务占用了。可以在系统设置的“隔空投送与接力”选项中关掉隔空播放接收器，再重启Docker重新映射端口即可。
• Docker Desktop残留的无效端口转发规则：Mac版Docker的端口转发是通过内置轻量虚拟机的vmnet组件实现的，如果之前有旧容器异常退出，会残留无效的端口转发规则，把发到5044的流量转发到已经不存在的容器上，导致当前运行的Logstash收不到任何请求。这种情况直接重启Docker Desktop就能清空所有残留规则。

4. 确认Filebeat的配置加载状态 #

打开Filebeat的调试日志，直接看启动阶段的输出：
filebeat -e -d "*"

• 查找日志中是否存在“Logstash output configuration loaded”的相关条目，如果没有，说明Logstash的输出配置根本没被加载，大概率是配置文件的YAML语法错误被静默跳过了。
• 确认日志中记录的目标解析IP和预期一致，避免因为数据目录权限、路径问题导致的配置加载不全。

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