Jellyfin

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

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

RocketChat

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 其余环境变量及数据库配置可保持不变。 🚀 升级步骤 …

WordPress

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 …

WordPress

解决长时间请求超时问题：一次 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 …

OnlyOffice

使用 Docker Compose 管理 ONLYOFFICE DocumentServer 的配置与优化实践

在日常部署和维护在线协作平台时，ONLYOFFICE DocumentServer 作为一款强大的在线 Office 解决方案，因其优秀的兼容性和开放性被广泛采用。结合 Docker Compose，可以更灵活地控制服务的生命周期、挂载、更新及安全策略。以下记录一次优化配置和维护的实践过程。 💡 配置背景 在最初的配置中，DocumentServer 容器同时暴露了 HTTP（80）和 HTTPS（443）端口，并在容器内部配置证书。这种方式在单机场景下可以快速实现，但长期来看，证书管理和更新不够灵活。 随着需求的发展，改为由外部反向代理（如 Nginx）统一处理 HTTPS，加密与证书管理集中在代理层面，容器只需使用 HTTP。这样不仅减少了内部配置复杂度，也方便后续维护。 ⚙️ 优化前配置示例 services: onlyoffice: image: onlyoffice/documentserver container_name: onlyoffice restart: always ports: – “8080:80” – “8443:443” volumes: – /path/to/logs:/var/log/onlyoffice – /path/to/data:/var/www/onlyoffice/Data – /path/to/cache:/var/lib/onlyoffice/documentserver/App_Data/cache/files – /path/to/public:/var/www/onlyoffice/documentserver-example/public/files – /path/to/fonts:/usr/share/fonts 在该配置中，容器内已经开启 HTTPS（8443），同时还挂载了示例文件和自定义字体目录，配置较为繁琐。 ✅ 优化后的配置 为了精简容器内部配置，只保留 HTTP（示例端口 8080），并将证书管理交由反向代理处理，配置文件进行了调整： …

Docker

Docker 容器架构优化与 Compose 切换实践总结

在容器化部署和运维过程中，许多用户最初会使用 docker run 命令快速启动服务。然而，随着服务数量增多、配置复杂化，这种方式逐渐显现出诸多局限，例如管理分散、配置难以集中备份、迁移麻烦等问题。 为了提升长期可维护性与安全性，近期完成了一次全面架构优化：将所有容器从 docker run 切换到 docker-compose 管理，以下为思路与实践总结。 🟢 原有容器情况 原系统中共运行约 28 个容器，覆盖 7 个主要业务应用（stack），例如以下示例服务： 部分服务最初通过 docker run 手动启动，虽然方便，但长期来看容易导致配置不一致、维护难度增大。 💡 切换至 Compose 管理的思路 ✅ 推荐方案 对于这些服务，最终选择了「重新整理 Compose 文件」的方式（官方推荐），核心步骤如下： 1️⃣ 为每个服务重新编写或整理对应的 docker-compose.yml 文件，清晰记录端口、卷挂载、环境变量、网络配置等所有细节。 2️⃣ 将 Compose 文件集中保存（如放入版本控制仓库或私有同步盘），方便后期维护、审计及灾备。 3️⃣ 使用 docker-compose up -d 管理服务生命周期，实现一键部署和统一启动。 ⚠️ 注意事项 🛡️ Portainer 的角色 此次优化中，Portainer …

TLS

Certbot 移除证书中多余域名的完整操作总结

在服务器维护中，常因架构或服务变更，需要删除证书中某些域名（子域名），避免不必要的安全风险与维护成本。本文总结了使用 Certbot 安全移除域名的标准流程，适用于所有使用多域名（SAN）证书的场景。 🔎 背景 某服务器最初申请了包含十多个子域名的多域名证书（例如主域名、文件服务、聊天系统、监控面板等），后来由于业务调整，有三个子域名不再需要，计划将其从证书中移除。 🛠️ Certbot 的逻辑 Certbot 并不支持「直接编辑」证书来删除域名，而是通过重新申请证书并覆盖原证书来实现域名的更新。 核心原则： 在重新申请时，只需要在新的域名列表中省略要移除的域名，Certbot 会自动生成新的证书并移除不需要的域名。 ✅ 操作流程 1️⃣ 查看当前证书 执行以下命令查看当前证书和域名列表： certbot certificates 记录证书名称（比如 example.com），并核对所有包含的域名。 2️⃣ 准备新的域名列表 只保留当前仍在使用的域名。例如，原证书包含： example.comwww.example.comfile.example.comchat.example.comdb.example.comapp.example.com… 如果计划移除 file.example.com、db.example.com、www.example.com，则新的域名列表只包含需要继续使用的域名。 3️⃣ 重新申请证书 根据实际环境选择使用 –nginx、–apache 或 –standalone 等插件，例如 Nginx： certbot certonly –nginx \ -d example.com \ -d chat.example.com \ -d app.example.com \ …

RocketChat

Rocket.Chat 域名迁移与 Jitsi 配置调整实战总结

在一次 Rocket.Chat 生产环境的维护中，需要将服务域名从旧地址迁移到新的子域名，同时更新文件上传链接和 Jitsi 视频会议配置。这篇文章总结了整个过程中遇到的问题、解决方案以及关键操作步骤，供有类似需求的用户参考。 💡 背景 🟢 域名迁移 修改 docker-compose.yml 首先需要在 docker-compose.yml 中更新 Rocket.Chat 服务的 ROOT_URL 环境变量，例如： environment: ROOT_URL: https://chat.example.com 修改后执行以下命令重新启动容器，使修改生效： docker-compose downdocker-compose up -d 更新数据库中的 Site URL Rocket.Chat 会在数据库中保存一个 Site_Url 配置，优先级高于自动推断。当域名变更时，需要同步更新此值。 进入 MongoDB 容器： docker exec -it <mongodb-container-name> mongosh 切换数据库： use rocketchat 更新 Site_Url： db.rocketchat_settings.updateOne( { _id: “Site_Url” …

WordPress

用子路径访问 WordPress：更稳定、更简单的最佳实践

在实际运维和多站点管理中，很多人常常会遇到这样的问题： 想通过子域名（例如 blog.example.com）来访问某个子目录中的 WordPress，但最终发现跳转逻辑复杂、配置繁琐，甚至会引发各种不必要的麻烦。 💡 WordPress 的设计逻辑 WordPress 是一个需要严格识别「主站 URL」的应用，站点地址（siteurl 和 home）会被写入数据库。它的架构假设访问地址是唯一且固定的，这与 Nextcloud 等可以完全依赖相对路径的应用不同。 ⚡ 子域名访问的复杂性 如果希望通过子域名根路径访问 WordPress，比如 blog.example.com： 对于已有多文件的根目录环境，或同一台服务器上有其他重要应用，这种方案会带来较高的风险和维护成本。 ✅ 子路径访问：最简单、最稳妥 相比之下，保留原有子路径（例如 https://example.com/wordpress/）具有明显优势： 在 Nginx 配置中，可以继续保留： location / { proxy_pass http://后端服务器/wordpress/; proxy_http_version 1.1; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto https;} 🔥 子路径方案的适用场景 ⭐ 总结 …

Nginx

多服务 Nginx 反向代理配置与细节总结

在复杂的多服务服务器环境中，通过子域名和 Nginx 反向代理将不同内网服务安全、高效地发布到公网，是一种常见且实用的架构方案。以下是一份详细的配置总结，涵盖了常用服务（如 Nextcloud、Rocket.Chat、WordPress、PVE、PBS、Webmin、Stirling PDF、phpMyAdmin、Portainer、Plex 等）在 Nginx 上的实践配置与要点。 ✅ 核心思路 ✅ 通用配置结构 server { listen 80; server_name example.com; return 301 https://$host$request_uri;}server { listen 443 ssl http2; server_name example.com; client_max_body_size 200M; ssl_certificate /path/to/fullchain.pem; ssl_certificate_key /path/to/privkey.pem; ssl_protocols TLSv1.2 TLSv1.3; location / { proxy_pass http://192.168.x.x:port/; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection “upgrade”; …