Selfhost

Mailcow 邮箱迁移与域名切换问题解析

在企业或个人使用 Mailcow 搭建自有邮件服务器的过程中，经常会遇到「域名切换」「邮箱账号迁移」等复杂情况。本文总结了一个实际案例中遇到的问题，并整理了详细的解析与解决思路，供有类似需求的用户参考。 💡 现象：服务器换了域名，旧邮箱账号还能登录？ 很多人会发现，即使将邮件服务器的主机名（FQDN）换了，比如从 mail.old-domain.com 换成 mail.new-domain.com，原先基于旧域名的邮箱账号（如 user@old-domain.com）依然可以正常登录使用。这是因为： 💡 邮箱账号域名与服务器域名的关系 在实际配置中，需要区分以下几个概念： ✅ 邮箱账号域名 ✅ 服务器域名（SMTP/IMAP Hostname） 💡 如果旧域名不再使用，会有影响吗？ 需要根据实际情况分两种情况讨论： 🟢 内部邮件收发 如果只在系统内部收发邮件（没有对外 MX 记录收件），即使域名没有公网解析记录，也不会影响登录和内部传递。 🟢 对外发邮件 如果继续向外部（例如 Gmail、Outlook 等）发送邮件，仍然使用旧域名作为发件人，则必须保留旧域名的 DNS 配置，包括： 否则，收件人服务器会因为无法验证域名而将邮件判定为垃圾邮件甚至直接拒收。 💡 推荐做法：新账号迁移 更安全、规范的方式是直接为新域名创建新账号，用新账号进行对外通信。旧账号可以保留，作为历史备份或纪念用途，不再用于发送外部邮件。 优点包括： 💡 Mailcow 域名配额（Quota）显示解释 Mailcow 后台在域管理界面中，Quota 列通常会显示 已分配配额 / 最大可用配额，这常被误认为是实际已使用容量。 实际上，Quota 指的是「为域内所有邮箱账号预先分配的总容量额度」，并非邮件实际存储量。如果域的总可用配额是 10 …

Selfhost

VPS 上使用 Duplicator 迁移 WordPress 并配置 Apache + MySQL + SSL 实践记录

近期在一台 VPS 上完成了 WordPress 的迁移及重建，使用 Duplicator 插件导出的完整包，结合 Apache、MySQL 和 Certbot 配置，整理了详细操作流程与遇到的错误解决方案，供参考。 ✅ 基础环境准备 服务器环境：Ubuntu 系统 sudo apt updatesudo apt upgrade -ysudo apt install apache2 mysql-server php php-mysql libapache2-mod-php php-zip unzip -ysudo systemctl enable apache2 mysql ✅ MySQL 配置 MySQL 在新版中默认通过 auth_socket 登录，无需密码。如果需要使用密码登录，可执行以下 SQL： ALTER USER ‘root’@’localhost’ IDENTIFIED WITH mysql_native_password BY …

Selfhost

在服务器上使用命令行启用 WordPress 插件的方法

在管理 WordPress 网站时，常常需要对插件进行批量操作，比如启用、禁用、更新等。除了通过后台管理页面操作外，也可以通过命令行工具进行管理，这种方式在服务器运维、自动化脚本中非常实用和高效。 为什么选择命令行启用插件？ WP-CLI 简介 WP-CLI 是官方推荐的 WordPress 命令行工具，能够执行包括插件管理、数据库更新、文章批量操作等在内的几乎所有常见任务。 安装 WP-CLI 以 Linux 系统为例，安装流程如下： curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.pharphp wp-cli.phar –info # 测试是否正常运行chmod +x wp-cli.pharsudo mv wp-cli.phar /usr/local/bin/wp 完成后，即可使用 wp 命令。 查看当前插件状态 进入 WordPress 根目录（wp-config.php 所在目录），执行以下命令查看插件状态： wp plugin list 命令会列出所有插件的名称、版本、状态（active, inactive）等信息，方便后续操作。 启用插件 启用单个插件的命令如下： wp plugin activate 插件目录名 例如，要启用 Akismet 插件： wp …

Selfhost

Nextcloud 系统日志常见问题解析与排查思路

在日常使用 Nextcloud 时，系统日志中会记录各类提示、警告以及错误信息。正确解读这些信息，有助于及时发现配置或性能问题，并保持系统的稳定性。以下总结了几条常见的日志案例，并给出对应的分析与解决建议。 📌 内存使用超标警告 示例日志： yamlCopyEditRequest used more than 300 MB of RAM: 587.8 MB 原因解析：Nextcloud 内部默认对请求内存使用进行监控，当单个请求超过 300MB 时，会记录警告日志。该值并不是 PHP 的 memory_limit 限制，而是内部的一个参考阈值。 解决思路： 📌 文件共享邮件通知失败 示例日志： nginxCopyEditShare notification mail could not be sent to: example@gmail.com 原因解析：该错误通常发生在文件共享操作中，系统尝试发送共享通知邮件但失败。文件分享本身依然成功，只是未能发送出邮件提醒。 解决思路： 📌 Memories 模块索引失败 示例日志： pgsqlCopyEditWrite hook failed to index file 原因解析：上传图片或视频文件后，Memories …

Selfhost

Nextcloud 内置应用为何无法删除？

在使用 Nextcloud 时，后台「应用管理」界面会列出许多可选功能模块（APP），有些模块可以启用、禁用，甚至完全删除；而部分模块则只能「启用」或「禁用」，却无法直接删除。 常见例子包括： 那么，这些无法删除的应用背后到底有什么原因呢？ 🌟 核心模块与官方推荐 这些应用通常被标记为「Featured」，意味着它们是官方推荐的核心功能或增强功能。 例如，默认加密模块用于保障文件安全；外部存储支持方便将文件挂载到外部存储系统（如 S3、FTP、局域网共享）；LDAP 用户后端支持企业或学校的集中账户管理；双因素认证则增强登录安全性。 这些功能并不是普通插件，它们在 Nextcloud 的架构中占据重要位置，因此被视为「核心」或「系统级」组件。 🛡️ 系统完整性与依赖关系 即使暂时未使用这些应用，系统依然会保留它们的文件。这是因为部分功能模块在运行时可能依赖于这些核心应用，例如文件访问控制、共享、用户认证、审计功能等。如果彻底删除，可能导致后续更新失败、系统出错，甚至无法正常启动。 为了保证系统的稳定性和可维护性，这些核心应用只能通过「启用」或「禁用」来控制，而不会提供直接删除按钮。 ⚙️ 是否可以强制删除？ 理论上可以通过直接删除服务器中 apps/ 目录下对应应用的文件夹来达到「删除」效果，例如： swiftCopyEdit/var/www/nextcloud/apps/encryption /var/www/nextcloud/apps/files_external 然而，这种做法并不被官方支持，且会带来严重后果，包括： 因此，更安全的做法是仅在后台「禁用」这些应用，必要时随时重新启用。 ✅ 总结 Nextcloud 将部分关键应用视为系统核心组件，为了保障功能完整性和未来更新，这些应用无法通过常规界面删除，只能选择启用或禁用。如果无实际使用需求，可选择禁用来简化功能面板；若有安全或管理需求，也可根据需要随时启用。 安全、可维护，始终是 Nextcloud 官方对核心模块的设计初衷。

Selfhost

Nextcloud 报错「Class ConversionApiController does not exist」的原因与解决思路

在 Nextcloud 管理后台（例如「系统概览」页面）或执行 occ setupchecks 时，可能会遇到如下错误提示： ReflectionException: Class “OCA\Files\Controller\ConversionApiController” does not exist 该错误通常出现在「安全与设置检查」环节，尤其是执行 HTTP 头部安全检查（Security Headers）时，导致提示「服务器配置错误」或「检查服务器设置时发生错误」。以下内容仅作为排查与修复思路参考，具体效果会因环境差异而不同。 🔎 报错背景 Nextcloud 在执行路由注册和安全检查时，会通过反射机制（Reflection）扫描控制器。如果控制器文件或对应路由声明缺失，就会触发 ReflectionException。 此错误中提到的 ConversionApiController 属于 Files app 的控制器之一，自 Nextcloud 30 起引入，用于文档转换 API（Conversion API）功能。如果升级过程中文件未正确更新或存在异常路由注册，便可能出现该报错。 💡 可能原因 1️⃣ Files app 文件不完整 升级 Nextcloud 或迁移文件时，Files app 内的文件（如 ConversionApiController.php）可能未正确复制或同步，导致系统无法找到相应控制器。 2️⃣ 路由或缓存异常 即使文件存在，如果系统中有旧缓存（如路由缓存、opcode 缓存）仍保留错误注册信息，依然会触发加载错误的路由，导致异常。 3️⃣ 第三方 …

Selfhost

Jellyfin 使用 443 标准端口解决 Trailer 与预览片段播放问题

在部署 Jellyfin 媒体服务器时，许多人会遇到 Trailer（预告片）或缩略图预览无法播放的问题。尤其当服务端口未使用标准的 443 端口，即使已经启用了 HTTPS，仍然会在浏览器中被阻止。通过切换到标准 443 端口，这些问题可以被彻底解决，以下总结了原因与解决思路。 现象 在 Jellyfin 界面中，电影详情页会提供一个 Trailer（预告片）按钮，该功能通常会调用外部平台（如 YouTube 或 TMDb）的视频链接，通过内嵌播放器在页面中播放。当端口不是 443 时，即使启用了 HTTPS，浏览器也会提示“不允许播放”或直接阻止 Trailer 视频的加载。 此外，视频预览片段（如快进时显示的缩略图）也可能无法加载，表现为黑屏、卡顿或直接无法生成预览。 根本原因 非标准端口引发的浏览器安全策略限制 切换到 443 端口的优势 配置建议 总结 Trailer 与视频预览无法播放的问题，根本原因在于非标准 HTTPS 端口导致的浏览器安全限制。切换到标准 443 端口后，浏览器会将其视为安全内容，从而允许外部嵌入视频的正常播放，Jellyfin 相关功能也将完全恢复正常体验。 参考

Selfhost

Rocket.Chat 从 7.2.0 升级到 7.6.0：完整操作流程与注意事项

近期，很多运维和自建聊天服务的爱好者计划将 Rocket.Chat 从 7.2.0 升级到 7.6.0，以获取最新的功能和安全修复。本次升级涉及到 Compose 文件的调整、容器镜像的更新以及一些安全性细节优化。以下为升级全过程及要点总结。 💡 Compose 文件的文件名标准 Docker Compose 文件不仅支持传统的 docker-compose.yml，还支持以下几种命名方式： 新版 Docker 推荐使用更简洁的 compose.yml 或 compose.yaml，与其他 YAML 配置文件区分更清晰，也符合最新 Compose 规范。无论选择哪种命名，Docker Compose 都能自动识别并加载，无需手动指定。 ⚙️ 升级前的准备 在进行版本升级之前，强烈建议对 MongoDB 数据库进行一次备份。尽管 Rocket.Chat 在启动时会自动处理数据库迁移，但保留快照可以在出现异常时快速恢复。 🔧 Compose 文件修改 升级的核心在于更新 Compose 文件中 Rocket.Chat 镜像的版本号。例如，将以下配置： image: registry.rocket.chat/rocketchat/rocket.chat:7.2.0 修改为： image: registry.rocket.chat/rocketchat/rocket.chat:7.6.0 其余环境变量及数据库配置可保持不变。 🚀 升级步骤 …

Selfhost

WordPress 优化总结：插件冲突排查、缓存加速、Jetpack 理解、备份迁移对比与服务器配置

在日常维护 WordPress 独立站点的过程中，常见问题包括性能瓶颈、插件冲突、迁移后异常、以及 Jetpack 和 WordPress.com 的关联困惑。以下为一次系统性排查和优化的总结，供参考。 🔥 插件冲突排查与优化 通过逐一检查与整理，最终保留了 26 个插件，核心思路如下： 此后，整体插件体系更为简洁，功能明确，减少了维护复杂度。 ⚡️ Jetpack 的定位与处理 Jetpack 由 WordPress.com 背后公司 Automattic 开发，定位是为自托管 WordPress 站点提供「云增强功能」，如站点统计、CDN 加速、安全扫描、自动分享、评论订阅等。 在优化过程中，仅保留必要功能（如统计或图像加速），关闭其他模块，以减少对 WordPress.com 云端依赖，同时保持站点显示完整和稳定。 🚀 缓存与性能配置 站点性能主要通过以下两层缓存进行优化： 经过配置和验证，首字节时间（TTFB）大幅降低，前端体验更快，缓存文件占用空间极小（一般仅几十 KB ~ 几百 KB），不会对磁盘造成压力。 🔒 安全与登录管理 在安全方案中，结合使用以下功能： 整体安全策略集中、简洁，并无明显冲突，提升管理清晰度。 💡 All-in-One WP Migration 与 Duplicator 对比 备份和迁移常见插件对比如下： 功能 All-in-One …

Selfhost

解决长时间请求超时问题：一次 Nextcloud & WordPress 优化记录

在维护服务器（比如 Nextcloud 或 WordPress 等基于 PHP 的应用）时，我们经常会遇到「长时间操作」超时的问题，比如备份、安装大插件、文件上传等。在我的场景里，操作大约执行 1 分钟后就会被中断，提示 504 Gateway Timeout 或直接报错，后台虽然继续运行，但浏览器前端请求会被强制断开。 这篇文章记录我完整的排查和解决流程，希望对同样遇到问题的朋友有所帮助。 🟢 ❓ 现象 应用环境： 🔎 🧩 排查思路 最初怀疑是 Nginx 反向代理 超时限制，于是开始逐层排查： ✅ 1️⃣ Nginx 配置 在 server 或 location 段落中查看是否有超时设置，默认情况下： proxy_read_timeout 60s;proxy_connect_timeout 60s;proxy_send_timeout 60s; 此处 60 秒就是导致中断的原因。 解决方案：把超时时间放宽，比如 3600 秒（1 小时）： proxy_connect_timeout 3600s;proxy_send_timeout 3600s;proxy_read_timeout 3600s; 注意：fastcgi_read_timeout …