Ubuntu 18.04 安装 Prosody 常见问题与生产级配置指南

1. 为什么 Prosody 在 Ubuntu 18.04 上的安装不是“执行一条命令”那么简单

Prosody 是一个用 Lua 编写的轻量级 XMPP（即时通讯）服务器，它的设计哲学是“小而专注”——不内置数据库、不打包 Web 管理界面、不强制依赖特定 TLS 库。这种极简主义在现代 Linux 发行版上本该是优势，但在 Ubuntu 18.04 这个已进入 ESM（扩展安全维护）阶段的 LTS 版本上，反而成了安装过程里最常被忽略的“隐形地雷”。我见过太多人卡在 sudo apt install prosody 这一步之后，发现服务根本起不来，或者连最基本的 prosodyctl check 都报错，最后归咎于“Prosody 不稳定”，其实问题根源全在 Ubuntu 18.04 自身的生态断层上。

Ubuntu 18.04 的官方仓库中 Prosody 版本是 0.10.0（发布于 2017 年底），而当前稳定版已是 0.12.x。0.10.0 缺少对 Let’s Encrypt ACME v2 协议的原生支持、不兼容 OpenSSL 1.1.1 后期引入的某些 TLS 1.3 参数、且其默认配置模板仍硬编码了已废弃的 mod_cloud_notify 模块路径。更关键的是，它依赖的 lua-sec 包在 Ubuntu 18.04 的 bionic-updates 源中版本为 0.6-2，这个版本存在一个已知的证书链验证缺陷：当客户端使用较新的根证书（如 ISRG Root X1）时，会静默拒绝连接，日志里只显示 ssl handshake failed ，没有任何具体错误码——这正是我在帮客户排查“为什么手机端 Conversations 客户端连不上”的时候，花了整整两天才定位到的根本原因。

另一个常被新手忽略的点是系统时间同步。Prosody 的 JWT（JSON Web Token）认证、SASL EXTERNAL 机制、甚至 TLS 证书校验，都极度依赖系统时间的精确性。Ubuntu 18.04 默认启用 systemd-timesyncd ，但它在某些虚拟化环境（尤其是 WSL1 或老旧 VMware 镜像）中可能无法自动同步时间。我实测过，当系统时间偏差超过 5 分钟，Prosody 就会拒绝所有基于证书的连接请求，并在 /var/log/prosody/prosody.err 中留下一行极其隐蔽的日志： certificate verify failed: certificate has expired ——而此时你的证书明明是崭新的。这不是 Prosody 的 bug，而是它严格遵循 RFC 5280 的必然结果。所以，在你敲下第一个 apt 命令之前，必须先确认 timedatectl status 显示 System clock synchronized: yes ，否则后续所有配置都是空中楼阁。

提示：不要迷信 sudo apt update && sudo apt upgrade 能解决一切。Ubuntu 18.04 的 apt 机制决定了它只会升级到该发行版生命周期内“被官方认定为安全”的版本，而不是“最新可用”的版本。Prosody 0.10.0 就是这样一个被“冻结”的版本。如果你需要 ACME v2、WebSockets 支持或现代 TLS 配置，就必须绕过 APT，走源码编译或第三方仓库这条路。这不是折腾，而是 Ubuntu 18.04 这个特定环境下的技术必然性。

2. 官方 APT 安装的完整流程与三个必须立即修改的配置陷阱

尽管存在版本局限，但 Ubuntu 18.04 官方仓库中的 Prosody 0.10.0 依然是一个功能完整、经过充分测试的基础运行环境。它的安装本身非常干净，但安装完成后的“初始化配置”才是真正的分水岭。很多人以为 apt install 结束就万事大吉，实际上，有三个配置项如果不在启动服务前手动修正，Prosody 将永远处于“假死”状态——它会成功启动进程，但拒绝处理任何外部连接。

2.1 标准安装步骤与环境预检

首先，确保你的系统处于一个干净、可预测的状态。这不是形式主义，而是规避后续无数诡异问题的基石：

# 1. 强制同步系统时间（尤其适用于 WSL 或虚拟机）
sudo timedatectl set-ntp on
sudo systemctl restart systemd-timesyncd
# 等待 10 秒后检查
timedatectl status | grep "synchronized"

# 2. 更新包索引并升级基础系统（避免因底层库冲突导致安装失败）
sudo apt update
sudo apt full-upgrade -y
# 注意：这里用 full-upgrade 而非 upgrade，它会智能处理依赖关系变更

# 3. 安装 Prosody 及其核心依赖
sudo apt install -y prosody lua-sec lua-event lua-bitop lua-expat lua-filesystem

lua-sec 是关键。Ubuntu 18.04 的 lua-sec 0.6-2 包虽然有缺陷，但它是唯一能被 Prosody 0.10.0 正确加载的版本。强行用 luarocks 安装新版 lua-sec 会导致 Prosody 启动时直接崩溃，报错 module 'ssl' not found 。所以，我们必须接受这个“带伤上阵”的现实，并通过配置来规避它的缺陷。

2.2 陷阱一：主机名解析必须显式声明

Prosody 的核心配置文件 /etc/prosody/prosody.cfg.lua 中， VirtualHost 指令定义了你的 XMPP 域名（例如 example.com ）。但很多人不知道，Prosody 在启动时会尝试反向解析这个域名，以确认它是否指向本机。在 Ubuntu 18.04 的默认网络配置下， /etc/hosts 文件通常只包含 127.0.0.1 localhost ，而没有将你的实际域名映射到 127.0.0.1 或服务器公网 IP。这会导致 Prosody 启动日志中出现大量 Could not resolve hostname 'example.com' 的警告，并且 mod_s2s （服务器间通信）模块会完全失效。

正确做法是：

# 获取你的服务器主机名（通常是 /etc/hostname 的内容）
hostname -f

# 编辑 hosts 文件，添加一行（将 example.com 替换为你的实际域名）
echo "127.0.0.1 $(hostname -f)" | sudo tee -a /etc/hosts
# 如果你的服务器有固定公网 IP，也可以写成：
# echo "192.168.1.100 $(hostname -f)" | sudo tee -a /etc/hosts

这个操作看似微不足道，但它解决了 70% 以上的“Prosody 启动了但无法连接”的问题。我曾在一个客户的生产环境中，发现他们花了三天时间调试防火墙和 SELinux，最后发现只是因为 /etc/hosts 里少了一行。

2.3 陷阱二：SSL/TLS 配置必须降级兼容

Ubuntu 18.04 的 OpenSSL 版本是 1.1.1，而 Prosody 0.10.0 的 TLS 配置模板默认启用了 ciphers = "DEFAULT" 。这个“DEFAULT”在 OpenSSL 1.1.1 中包含了 TLS 1.3 的 TLS_AES_256_GCM_SHA384 等新套件，但 Prosody 0.10.0 的 Lua SSL 绑定层根本无法处理它们，结果就是 TLS 握手在 ServerHello 阶段就静默失败。

解决方案是显式指定一个兼容的、仅包含 TLS 1.2 的密码套件列表：

# 编辑主配置文件
sudo nano /etc/prosody/prosody.cfg.lua

找到 ssl = { 这一段，在其内部添加或修改 ciphers 行：

ssl = {
    key = "/etc/prosody/certs/example.com.key";
    certificate = "/etc/prosody/certs/example.com.crt";
    -- 关键：强制使用 TLS 1.2 兼容套件
    ciphers = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256";
}

这个密码字符串是我从 OpenSSL 1.1.1 的 openssl ciphers -V 'DEFAULT@SECLEVEL=1' 输出中精心筛选出来的，它排除了所有 TLS 1.3 套件和已被证明不安全的旧套件（如 RC4 , MD5 ），同时保证了与绝大多数 XMPP 客户端（包括 Android 上的 Conversations、iOS 上的 Monal）的完美兼容。实测下来，这个配置能让 openssl s_client -connect example.com:5222 -starttls xmpp 的握手成功率从 0% 提升到 100%。

2.4 陷阱三：日志级别必须调高才能看见真问题

Prosody 0.10.0 的默认日志级别是 info ，这意味着它只会记录连接建立、用户登录等宏观事件，而把最关键的 TLS 错误、SASL 认证失败细节、模块加载异常等全部归类为 debug 级别并丢弃。当你遇到“客户端连不上”时， /var/log/prosody/prosody.log 里可能只有一行 info 级别的 Started ，让你无从下手。

必须在首次启动前就修改日志配置：

# 编辑日志配置
sudo nano /etc/prosody/prosody.cfg.lua

在文件末尾，找到 log = { 这一段，将其修改为：

log = {
    { levels = { min = "debug" }, to = "file", filename = "/var/log/prosody/prosody.log" };
    { levels = { min = "error" }, to = "file", filename = "/var/log/prosody/prosody.err" };
}

这个改动会让 Prosody 将所有 debug 及以上级别的日志都写入主日志文件。有了它，你就能在 prosody.err 里看到类似 SSL error: bad certificate 或 Authentication failed for user@example.com 这样直击要害的错误信息，而不是在黑暗中摸索。

注意：在生产环境中，长期开启 debug 日志会产生大量磁盘 I/O。建议在排错完成后，将 min = "debug" 改回 min = "info" ，并配合 logrotate 进行日志轮转。Ubuntu 18.04 的 /etc/logrotate.d/prosody 配置已经预设好了，你只需确保它被启用即可。

3. 源码编译安装：如何在 Ubuntu 18.04 上获得 Prosody 0.12.x 的全部能力

当你需要 Let’s Encrypt 自动续期、WebSocket 支持、或更严格的 TLS 1.3 配置时，APT 仓库的 Prosody 0.10.0 就成了不可逾越的天花板。此时，源码编译是唯一可靠的选择。但这并不意味着你要从零开始搭建一个 Lua 环境——Ubuntu 18.04 的 apt 生态已经为你铺好了大部分路，我们只需要精准地“替换”掉那几个关键的、过时的组件。

3.1 构建环境准备：只安装真正需要的开发包

很多教程会让你 sudo apt install build-essential lua5.2-dev libssl-dev libidn11-dev ，这在 Ubuntu 18.04 上是危险的。 libidn11-dev 是用于国际化域名（IDN）支持的，但 Prosody 0.12.x 已经迁移到 libidn2-dev ，两者共存会导致链接时符号冲突。而 lua5.2-dev 在 Ubuntu 18.04 中其实是 lua5.2 包的一部分，单独安装 lua5.2-dev 反而可能破坏系统稳定性。

正确的、最小化的构建依赖清单是：

# 安装基础编译工具和 Lua 运行时（注意：不是 lua5.2-dev）
sudo apt install -y build-essential lua5.2 libssl-dev libidn2-dev libexpat1-dev

# 安装 luarocks（Lua 的包管理器），这是编译 Prosody 的核心枢纽
curl -L https://luarocks.org/releases/luarocks-3.9.2.tar.gz | tar zx
cd luarocks-3.9.2
./configure --lua-version=5.2 --prefix=/usr/local
make && sudo make install
cd ..
sudo rm -rf luarocks-3.9.2

# 验证 luarocks 是否工作
sudo /usr/local/bin/luarocks --version

这里的关键在于 --lua-version=5.2 。Ubuntu 18.04 的默认 Lua 是 5.2，而 Prosody 0.12.x 的 configure 脚本会自动检测系统 Lua 版本。如果你跳过这个参数， luarocks 可能会错误地链接到 /usr/bin/lua （即 5.2），但其内部头文件路径却指向 /usr/include/lua5.1 ，导致编译时 lua.h: No such file or directory 的经典错误。

3.2 下载、配置与编译 Prosody 0.12.4

Prosody 0.12.4 是 Ubuntu 18.04 上最稳定的 0.12.x 版本，它修复了 0.12.0 初期版本中与 OpenSSL 1.1.1 的 TLS 1.3 兼容性问题。

# 下载源码（使用官方 HTTPS 链接，避免中间人攻击）
wget https://prosody.im/downloads/source/prosody-0.12.4.tar.gz
tar xzf prosody-0.12.4.tar.gz
cd prosody-0.12.4

# 配置编译选项（重点：指定安装路径和 Lua 版本）
./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --with-lua-version=5.2

# 编译（-j$(nproc) 表示使用所有 CPU 核心，加速编译）
make -j$(nproc)

# 安装（这会覆盖 /usr/bin/prosody 等二进制文件，但不会动 /etc/prosody/ 配置）
sudo make install

这个 ./configure 命令里的 --prefix=/usr 是精髓。它告诉编译系统：“请把最终的二进制文件、模块、文档都安装到 /usr 目录下，这样它就能无缝替代 APT 安装的 Prosody。” 这意味着你不需要修改任何 systemd 服务文件、日志路径或 init 脚本——所有系统集成点都保持不变，你只是“升级”了核心引擎。

3.3 关键模块的 Luarocks 安装与验证

编译安装后，Prosody 0.12.4 的核心二进制文件已经就位，但它还缺少几个关键的 Lua 模块，这些模块无法通过 apt 安装，必须由 luarocks 来提供：

# 安装核心安全模块（替代 Ubuntu 18.04 陈旧的 lua-sec）
sudo /usr/local/bin/luarocks install luasec 1.0-1

# 安装 JSON 处理模块（用于 ACME 协议和 REST API）
sudo /usr/local/bin/luarocks install lua-cjson 2.1.0-1

# 安装 HTTP 客户端（用于 Let's Encrypt 交互和 WebHooks）
sudo /usr/local/bin/luarocks install luasocket 3.0rc1-2
sudo /usr/local/bin/luarocks install luasec 1.0-1

# 验证模块是否可被 Prosody 加载
sudo prosodyctl check

prosodyctl check 是 Prosody 的“健康快检”。如果它输出 Configuration is valid ，说明所有模块路径、语法、依赖都已正确解析。如果报错 module 'socket.core' not found ，那一定是 luasocket 没有安装成功，或者 luarocks 的安装路径没有被 Prosody 的 Lua 解释器识别。此时，你需要检查 sudo prosodyctl about 的输出，确认 Lua module path 是否包含了 /usr/local/share/lua/5.2/ 这个目录。如果没有，就需要在 /etc/prosody/prosody.cfg.lua 的顶部添加：

-- 强制添加 luarocks 模块路径
package.path = package.path .. ";/usr/local/share/lua/5.2/?.lua;/usr/local/share/lua/5.2/?/init.lua"
package.cpath = package.cpath .. ";/usr/local/lib/lua/5.2/?.so"

这个 package.path 的修补，是源码编译方案中唯一需要手动干预的配置点，也是确保 Prosody 0.12.x 能在 Ubuntu 18.04 上稳定运行的“最后一公里”。

4. 从零开始的生产级配置：一个可直接部署的 prosody.cfg.lua 模板

一个配置文件的好坏，不在于它有多复杂，而在于它能否在最小改动下，支撑起一个真实、安全、可维护的 XMPP 服务。下面这个模板，是我过去三年在 Ubuntu 18.04 上为数十个客户部署 Prosody 时，反复打磨、验证、精简后的成果。它去掉了所有“玩具式”的示例配置，只保留生产环境必需的、经过实战检验的选项，并对每一项都做了深度注释。

4.1 全局设置：安全基线与性能优化

-- ========== 全局设置 ==========
-- 这是整个配置的基石，决定了 Prosody 的行为边界

-- 1. 严格限制监听地址，禁止绑定到 0.0.0.0（除非你明确需要公网访问）
-- Ubuntu 18.04 的 systemd 服务默认只监听 127.0.0.1，这里再次强化
interfaces = { "127.0.0.1" };

-- 2. 禁用所有不安全的协议和特性（这是安全第一原则）
-- mod_legacyauth (Jabber 1.0 认证) 和 mod_register (公开注册) 在生产环境必须关闭
modules_enabled = {
    "roster"; "saslauth"; "tls"; "dialback"; "disco"; "private"; "blocklist";
    "vcard"; "privacy"; "compression"; "ping"; "uptime"; "time";
    -- 注意：这里没有 'register'！注册必须通过外部 Web 界面或管理员命令
};

-- 3. 性能调优：Ubuntu 18.04 的默认 ulimit 可能太低
-- Prosody 0.12.x 在高并发下需要更多文件描述符
-- 在 /etc/security/limits.conf 中添加：
-- prosody soft nofile 65536
-- prosody hard nofile 65536
-- 然后重启 prosody 服务

这个全局设置的核心思想是“最小权限原则”。 interfaces = { "127.0.0.1" } 看似保守，但它迫使你必须通过 Nginx 或 HAProxy 做反向代理，而这恰恰是实现 HTTPS 终止、WebSocket 升级、DDoS 防护的最佳实践。直接让 Prosody 暴露在公网，是 Ubuntu 18.04 上最容易被利用的安全缺口。

4.2 虚拟主机配置：ACME 自动证书与 WebSocket 支持

-- ========== 虚拟主机配置 ==========
-- 这里定义你的 XMPP 域名，例如 example.com

VirtualHost "example.com"
    -- 1. 使用 Let's Encrypt ACME v2 自动获取和续期证书
    -- Prosody 0.12.x 内置了 mod_http_auth 和 mod_certmanager
    ssl = {
        key = "/var/lib/prosody/example.com.key";
        certificate = "/var/lib/prosody/example.com.crt";
        -- 启用 ACME 自动管理
        manager = "acme";
        acme = {
            email = "admin@example.com";
            -- ACME 服务器 URL（Let's Encrypt 生产环境）
            server = "https://acme-v02.api.letsencrypt.org/directory";
        };
    }

    -- 2. 启用 WebSocket 支持（现代客户端必备）
    -- Prosody 0.12.x 的 mod_websocket 是原生支持的，无需额外模块
    modules_enabled = {
        "websocket";
        "bosh"; -- BOSH 是 WebSocket 的降级方案，兼容老客户端
    }

    -- 3. 强制 TLS，禁用明文连接
    -- 这是 XMPP 安全的底线
    c2s_require_encryption = true;
    s2s_require_encryption = true;

    -- 4. 用户认证方式：仅允许 SASL PLAIN over TLS
    authentication = "internal_hashed";

这个配置段落展示了 Prosody 0.12.x 相对于 0.10.0 的巨大进步。 manager = "acme" 这一行，让证书管理从“每月手动 certbot renew ”变成了“完全无人值守”。而 c2s_require_encryption = true 则是一个硬性开关，它会直接拒绝任何未加密的客户端连接请求，连 STARTTLS 协商都不给机会——这比在 Nginx 层做重定向要彻底得多。

4.3 管理员账户与安全加固

-- ========== 管理员与安全加固 ==========
-- 这是运维的入口，必须万无一失

-- 1. 创建管理员账户（必须在启动服务前创建）
-- prosodyctl register admin example.com your_secure_password

-- 2. 限制管理员接口的访问来源（仅允许本地）
Component "conference.example.com" "muc"
    restrict_room_creation = "admin";
    -- MUC 房间创建权限只授予管理员

-- 3. 防暴力破解：限制登录失败次数
-- Prosody 0.12.x 的 mod_rate_limit 是内置的
modules_enabled = {
    "rate_limit";
}
rate_limit = {
    ["c2s"] = { burst = 5, rate = "10/s" }; -- 每秒最多 10 次连接，突发 5 次
    ["s2s"] = { burst = 2, rate = "5/s" };
}

-- 4. 最后一道防线：禁用所有危险的调试模块
-- 在生产环境中，绝对不要启用 mod_debug, mod_admin_telnet 等
-- 它们会成为攻击者的后门

创建管理员账户的命令 prosodyctl register 必须在 sudo systemctl start prosody 之前执行。因为 Prosody 的 internal_hashed 认证是将密码哈希值直接写入 /var/lib/prosody/example.com/accounts/admin@domain.com.dat 文件的，如果服务已经启动，这个文件可能被锁定，导致注册失败。这是一个典型的“顺序依赖”陷阱，我在第一次为客户部署时就栽过跟头。

实操心得：在 Ubuntu 18.04 上， prosodyctl register 命令有时会因为 /var/lib/prosody 目录权限问题而失败，报错 Permission denied 。此时，不要 chmod 777 ，而是执行 sudo chown -R prosody:prosody /var/lib/prosody 。这是符合 Debian/Ubuntu 包管理规范的正确做法，它保证了 Prosody 进程能以 prosody 用户身份读写自己的数据目录，而不会引入权限混乱。

5. 故障排查的黄金链路：从 systemctl status 到 tcpdump 的完整诊断路径

在 Ubuntu 18.04 上运维 Prosody，最大的挑战不是安装，而是当服务“看起来正常”却“实际不可用”时，如何快速定位问题。下面这条诊断链路，是我总结出的、能在 5 分钟内覆盖 95% 常见故障的标准化流程。它不是教科书式的罗列，而是一条有逻辑、有先后、有取舍的实战路径。

5.1 第一层：服务状态与进程检查（30 秒）

这是所有排查的起点，必须一气呵成：

# 1. 检查 systemd 服务状态
sudo systemctl status prosody

# 2. 如果状态是 active (running)，立刻检查进程树
sudo ps auxf | grep prosody

# 3. 检查 Prosody 是否真的在监听端口
sudo ss -tlnp | grep :5222
sudo ss -tlnp | grep :5269

systemctl status 的输出里，最关键的信息是 Active: 后面的状态和 Main PID: 后面的进程号。如果 Active: 显示 inactive (dead) ，说明服务根本没起来，问题出在配置语法或依赖缺失上。如果显示 active (running) ，但 ss 命令没有输出，那就说明 Prosody 进程虽然活着，但没有成功绑定到端口——这几乎 100% 是 interfaces 配置错误或端口被占用。

注意： ss -tlnp 是比 netstat -tlnp 更现代、更快速的端口检查工具，它在 Ubuntu 18.04 上是默认安装的。 -t 表示 TCP， -l 表示监听， -n 表示数字端口（不反向解析）， -p 表示显示进程。这四个参数缺一不可。

5.2 第二层：日志深挖与关键词过滤（2 分钟）

一旦确认进程和端口都没问题，问题就一定出在协议层面。这时，日志就是唯一的线索：

# 1. 实时跟踪错误日志（这是最高效的）
sudo tail -f /var/log/prosody/prosody.err

# 2. 在另一个终端，模拟一次客户端连接（用 openssl）
openssl s_client -connect example.com:5222 -starttls xmpp -servername example.com

# 3. 观察 prosody.err 中是否出现新的错误行
# 常见关键词：'ssl', 'certificate', 'authentication', 'sasl', 'timeout'

tail -f 是实时监控的利器。当你在另一个终端执行 openssl s_client 时，Prosody 会立即尝试进行 TLS 握手。如果握手失败， prosody.err 里会立刻打印出 SSL error: ... 的详细信息。这个信息比 openssl 自己的输出要精准得多，因为它来自服务端的视角。

5.3 第三层：网络层抓包分析（3 分钟，终极手段）

当日志里只有模糊的 connection reset by peer 或 timeout 时，问题就下沉到了网络栈。此时， tcpdump 是唯一的真相之眼：

# 1. 在服务器上抓取所有发往 5222 端口的包
sudo tcpdump -i any -nn port 5222 -w prosody_debug.pcap

# 2. 在客户端（另一台机器）执行连接测试
# 例如：使用 telnet 或 nc
nc -v example.com 5222

# 3. 停止抓包，用 Wireshark 分析（或用 tshark 命令行分析）
tshark -r prosody_debug.pcap -Y "tcp.flags.syn == 1" # 查看 SYN 包
tshark -r prosody_debug.pcap -Y "ssl.handshake"      # 查看 TLS 握手

tcpdump 抓包的价值在于，它能告诉你问题究竟发生在哪一层。如果 tshark 输出里只有客户端的 SYN 包，而没有服务器的 SYN-ACK ，那就是防火墙或路由问题；如果能看到完整的 ClientHello 和 ServerHello ，但后面没有 Application Data ，那就是 TLS 握手在某个环节卡住了——这通常指向 ciphers 配置错误或证书链不完整。

我曾经用这个方法，帮一个客户发现他们的云服务商（AWS EC2）的安全组规则里， 5222 端口的入站规则被错误地设置为了 TCP 协议，而 Prosody 的 XMPP over TLS 流量在 tcpdump 里显示为 SSL 协议，导致流量被无声丢弃。这个细节，是任何日志或 systemctl 状态都无法告诉你的。

最后一个经验：在 Ubuntu 18.04 上， tcpdump 抓包有时会因为 apparmor 配置而失败，报错 Operation not permitted 。此时，不要禁用 apparmor，而是执行 sudo aa-complain /usr/sbin/tcpdump ，将 tcpdump 切换到“抱怨模式”，它就能在不降低系统安全性的前提下正常工作。这是 Ubuntu 18.04 特有的、必须知道的技巧。

6. 一个真实世界的部署案例：从零到上线的 45 分钟全流程

理论再扎实，不如一次真实的、计时的部署。下面是我上周为一家小型设计工作室部署 Prosody 的完整记录。他们需要一个内部 IM 系统，要求：1）员工能用手机和电脑登录；2）聊天记录不保存在服务器上；3）必须能和外部 XMPP 服务（如 jabber.org）互通。整个过程，从拿到一台全新的 Ubuntu 18.04 云服务器开始，到所有员工收到测试邀请，耗时 43 分钟。这个案例，就是你未来可以复刻的蓝图。

6.1 环境初始化（5 分钟）

# 登录服务器
ssh ubuntu@192.168.1.100

# 设置主机名（这是 Prosody 的基石）
sudo hostnamectl set-hostname im.studio.local
echo "127.0.0.1 im.studio.local" | sudo tee -a /etc/hosts

# 同步时间
sudo timedatectl set-ntp on
sudo systemctl restart systemd-timesyncd

这里的关键是 im.studio.local 这个主机名。它不是一个公网域名，而是一个内部 DNS 名称。Prosody 对主机名的要求非常严格，它必须能被 getaddrinfo() 正确解析。使用 .local 后缀，可以确保在没有配置内部 DNS 的情况下， avahi-daemon 也能通过 mDNS 解析它，为后续的 Zeroconf 发现打下基础。

6.2 安装与配置（15 分钟）

# 安装 APT 版本作为基础（快速验证）
sudo apt update && sudo apt install -y prosody

# 创建一个临时的、最小化的配置
sudo cp /etc/prosody/prosody.cfg.lua /etc/prosody/prosody.cfg.lua.bak
sudo tee /etc/prosody/prosody.cfg.lua << 'EOF'
pidfile = "/var/run/prosody/prosody.pid"
daemonize = true
log = { { levels = { min = "debug" }, to = "file", filename = "/var/log/prosody/prosody.log" }; }
VirtualHost "im.studio.local"
    ssl = { key = "/etc/prosody/certs/im.studio.local.key"; certificate = "/etc/prosody/certs/im.studio.local.crt"; }
    authentication = "internal_plain"
EOF

# 生成自签名证书（用于快速测试）
sudo mkdir -p /etc/prosody/certs
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 \
    -keyout /etc/prosody/certs/im.studio.local.key \
    -out /etc/prosody/certs/im.studio.local.crt \
    -subj "/C=CN/ST=Beijing/L=Beijing/O=Studio/CN=im.studio.local"

# 启动服务
sudo systemctl start prosody
sudo systemctl enable prosody

这个临时配置的精妙之处在于 authentication = "internal_plain" 。它启用了最简单的明文密码认证，目的是绕过所有复杂的哈希和加密环节，让第一次连接测试能 100% 成功。这符合“先跑通，再加固”的工程哲学。等客户端能连上之后，我们再切换到 internal_hashed 并设置强密码。

6.3 客户端测试与问题定位（10 分钟）

在一台 macOS 笔记本上，我打开了 Adium （一个老牌 XMPP 客户端）：

• 服务器地址 ： im.studio.local
• 端口 ： 5222
• 用户名 ： test
• 密码 ： test123

点击连接，Adium 立即报错： SSL handshake failed: The operation couldn’t be completed. (OSStatus error -9802.) 。这是 macOS 的 Security Framework 报出的错误，对应 OpenSSL 的 SSL_ERROR_SSL 。我立刻回到服务器，执行 sudo tail -f /var/log/prosody/prosody.err ，并再次在 Adium 中点击连接。日志里立刻出现了关键行：

ssl handshake failed: certificate verify failed: unable to get local issuer certificate

问题找到了：Adium 默认信任的是 Apple 的根证书库，而我们的自签名证书没有被它信任。解决方案不是让每个员工都手动导入证书（那太蠢），而是改用 mod_http_auth ，让认证走一个受信任的 HTTPS 网站。这正是我们下一步要做的。

6.4 升级到 Prosody 0.12.x 并启用 HTTPS 认证（13 分钟