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”; …

Troubleshooting

WordPress 备份遇到 504 Gateway Timeout 与大文件问题的解决方案

在使用 WordPress 过程中，网站数据的安全备份至关重要。常见的备份插件（如 Duplicator）可以快速打包整个站点文件和数据库，但在实际操作中，若站点体积较大，经常会遇到 504 Gateway Time-out 错误，或者浏览器下载时中断。这些问题并非插件故障，而多由服务器配置、超时设置或下载方式不当引起。 备份流程与后台情况 Duplicator 的典型流程分为两步：先导出数据库 SQL 文件，再将站点文件夹与数据库一起压缩为一个 zip 包。在后台任务执行时，会显示「Building Backup xx%」等进度信息。 若在打包中途遇到 504 Gateway Timeout 错误，往往只是浏览器或代理超时，实际压缩进程在服务器上通常仍在继续。刷新页面或重新进入备份列表，常可看到完整备份文件已生成。 504 Gateway Time-out 的原因 当服务器或代理（如 Nginx、Cloudflare 等）在设定时间内未收到后端响应，会返回 504 错误。进行大文件打包时，后端需要长时间执行 PHP 代码，若超出配置的超时时间，就会触发该错误。 解决思路 1️⃣ 调整服务器超时设置 修改后需重启服务： bashCopyEditsudo systemctl restart nginx sudo systemctl restart apache2 sudo systemctl restart php8.1-fpm 2️⃣ …

TLS

使用 Certbot 更新并统一多子域名 SSL 证书实践总结

在服务器上使用 HTTPS 是保证安全访问的必备措施，而 Let’s Encrypt 提供了免费的 SSL 证书，结合 Certbot 工具可以非常方便地申请和更新证书。在实际场景中，往往不仅需要为主域名配置证书，还要同时支持多个子域名，比如： python-replCopyEditwww.domain.com mail.domain.com app1.domain.com app2.domain.com … 以下是一次完整实践记录，总结关键步骤与注意事项。 💡 证书现状查看 首先查看现有证书及已包含的域名： bashCopyEditcertbot certificates 输出示例： yamlCopyEditFound the following certs: Certificate Name: domain.com Domains: domain.com mail.domain.com www.domain.com Expiry Date: 2025-09-22 21:50:18+00:00 (VALID: 82 days) Certificate Path: /etc/letsencrypt/live/domain.com/fullchain.pem Private Key Path: /etc/letsencrypt/live/domain.com/privkey.pem 🔄 重新申请并添加更多子域名 为了将所有需要的子域名统一到一个证书中，执行以下命令（使用 …

Nginx

Nginx 多服务反向代理方案对比与最佳实践

在自建服务器或私有云环境中，常常需要将多个 Web 服务整合到同一个公网 IP 上对外提供访问。常见的服务如 Rocket.Chat、Nextcloud、Proxmox VE、Mailcow 等，如何设计访问方式成为系统架构中一项重要决策。本文详细总结三种典型方案，并进行全面对比，帮助选择最适合的部署方式。 💡 三种典型方案 方案一：不同端口访问 思路每个服务占用一个独立的端口，用户通过域名加端口号访问，如： 优点 缺点 方案二：同域名 + 路径前缀 思路多个服务共享同一个域名，通过路径前缀区分，如： 优点 缺点 方案三：子域名 思路为每个服务配置一个独立子域名，如： 优点 缺点 ⚖️ 总体对比总结 不同端口访问 同域名 + 路径前缀 子域名 域名数量 1 1 多个子域名 端口体验 差（需手动输入） 好 好 兼容性 中 差 最好 用户体验 差 一般 最佳 配置复杂度 最简单 复杂 …