Ubuntu16.04（DigitalOcean）部署OpenFire4.2.1后好友授权请求无法接收

看起来你已经把OpenFire的基础功能跑通了——能连管理台、建用户、客户端上线加联系人，但卡在了订阅授权这一步，我之前部署OpenFire的时候也碰到过类似的情况，给你几个具体的排查方向：

1. 检查OpenFire用户隐私配置 #

登录OpenFire的Web管理控制台，进入Users/Groups页面找到对应的用户，点击进入Privacy Settings面板：

• 确认Subscription Requests的规则不是“拒绝所有”，如果是默认配置，可能需要手动添加允许接收订阅请求的规则（比如允许所有用户发送请求，或者指定特定范围）；
• 有些场景下，用户的隐私列表会默认阻止非联系人的请求，这时候哪怕客户端发了请求，服务器也会直接丢弃。

2. 细化tcpdump抓包，确认请求流向 #

你之前的tcpdump命令可以加上-A参数查看XMPP明文内容，这样能明确客户端是否真的发送了订阅请求，以及服务器有没有返回响应：

tcpdump -n -i eth0 -A 'tcp and (port 5222 or port 5269 or port 5280)'

• 如果抓包能看到客户端发送的<presence type='subscribe'> XML请求，但没有服务器的响应包，问题大概率在OpenFire的配置或路由上；
• 如果连请求包都抓不到，那要检查客户端的设置（比如是否选错了XMPP协议版本，或者客户端本地的隐私规则拦截了请求）。

3. 验证OpenFire的服务器域名与路由设置 #

• 进入Server Settings → Server Name，确认这里设置的域名/IP和客户端登录时使用的完全一致。如果服务器名是域名，但客户端用IP登录，可能会导致服务器无法正确路由订阅请求；
• 检查Server Settings下的Connection Managers和External Components，确保没有错误配置拦截了XMPP的订阅流量。

4. 查看OpenFire日志定位错误 #

OpenFire的日志默认存放在/var/log/openfire/或/opt/openfire/logs/目录下，重点查看info.log和debug.log：

• 搜索关键词subscribe或目标用户的JID，看看有没有类似Failed to route subscription request的错误提示，这类日志能直接指出问题根源。

5. 确认防火墙规则是否放行必要端口 #

虽然你能正常登录和上线，但还是要双重验证：

• 检查Ubuntu本地UFW防火墙：sudo ufw status，确保5222/tcp端口处于允许状态；
• 检查DigitalOcean的云防火墙规则，确认5222端口已加入入站允许列表——云层面的防火墙拦截是很容易忽略的点。

6. 客户端侧兼容性排查 #

• 试试在同一个客户端上登录两个用户互发订阅请求，排除跨客户端（Miranda vs Pidgin）的兼容性问题；
• 检查Miranda IM的XMPP插件设置，确认“显示订阅请求提示”选项已开启，有些客户端默认会自动隐藏或拒绝订阅请求。

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