Category: Selfhost

在使用 Nextcloud News 作为 RSS 同步后端时，桌面端客户端的选择会直接影响使用体验。表面上看，KDE 自带的 Akregator 与第三方的 RSS Guard 都属于传统 RSS 阅读器，但两者在“是否支持与 Nextcloud News 同步”这个关键点上差别很大。实际配置过程中，还可能遇到 RSS Guard 报错，提示禁止使用密码登录、必须改用令牌。本文对这一过程做一次简要整理。 一、客户端选择：本地阅读器与同步客户端不是一回事 如果需求只是“在桌面上看 RSS”，那么很多传统阅读器都可以胜任。但如果需求是“连接 Nextcloud News，同步订阅、分类和已读状态”，就必须优先考虑是否支持 Nextcloud News 接口。 1. RSS Guard RSS Guard 更适合作为 Nextcloud News 的桌面客户端，原因主要有两点： 对于偏向 Qt 界面、长期使用 KDE 的用户来说，它的整体风格也更协调，适合作为主力桌面端阅读器。 2. Akregator Akregator 本身并不是不能用，它依然是一个合格的本地 RSS 阅读器： 但问题在于，它并不适合承担 Nextcloud …

一、问题现象 在 Nextcloud 的地图应用中，地图图层出现异常： 该问题表现为间歇性缺图块（tile），而非完全不可用。 二、问题背景 该系统长期稳定运行（约 8 年），未做明显变更，但近期突然出现异常。 三、问题定位 通过抓包分析（浏览器 Network）可确认： 关键结论： OpenStreetMap（OSM）服务器要求请求必须携带 Referer，否则拒绝访问。 四、根本原因 问题并非系统损坏，而是外部策略变化： 1）OSM 策略加强（2025–2026） 核心要求： 2）Nextcloud 返回策略导致 Referer 丢失 Nextcloud 默认可能返回： 结果： 3）反向代理未干预该行为 当前 Nginx 配置： → 实际上完全依赖 Nextcloud 默认行为 五、解决方案 核心思路 强制浏览器发送 Referer Nginx 修复配置 在反向代理中加入： 修改后完整流程 六、使配置生效 执行： 七、验证方法 打开浏览器开发者工具： 1）检查请求头 2）检查响应头 3）观察结果 …

一、背景说明 在自托管环境中，界面视觉元素不仅影响使用体验，也会对长期工作状态产生潜移默化的影响。为 Unsplash 提供的图片资源接入 Nextcloud 作为背景，可以在不增加系统复杂度的前提下，提升整体视觉质感。 本文记录以下内容： 二、Unsplash API Key 的使用规范 在创建 Unsplash 应用后，会获得两个凭证： 1. 在 Nextcloud 中应填写哪个？ 只应填写： 原因： 在随机图片接口中，调用方式通常为： 其中 client_id 对应的即为 Access Key。 三、关键词设计原则 背景图片不应成为注意力干扰源。关键词设计需满足以下要求： 1. 避免高饱和和情绪化元素 不推荐： 原因： 2. 强调稳定自然结构 推荐围绕以下主题： 四、最终稳定关键词组合 经过优化后的自然环境关键词如下： 关键词结构解析 类别 关键词 作用 地形 mountains 稳定视觉锚点 水域 river, calm lake 平衡画面，降低张力 植被 …

一、问题现象 部署结构如下： 外网访问正常，局域网访问 http://内网IP/nextcloud/ 时出现异常： curl 复现： 二、问题根因分析 config.php 中存在如下配置： 该配置会： 在源站未启用 443 的情况下，任何 HTTP 请求都会被强制跳转至 HTTPS，从而导致局域网访问失败。 本质问题： 源站未提供 TLS，却强制协议为 HTTPS。 属于架构与配置不匹配。 三、解决方案 删除或注释： 保留： 更新重写规则并重载 Web 服务： 修复后验证： 应返回： 局域网访问恢复正常。 四、反向代理标准配置建议 1. trusted_domains 2. trusted_proxies 用于信任反代传递的 X-Forwarded-* 头部。 3. HSTS 策略 HSTS 应仅在 HTTPS 终端（反代机）启用，不应在纯 HTTP 源站配置。 五、架构原则 在反向代理结构中应遵循： …

问题描述 在 Nextcloud 管理后台的 Security & setup warnings 中出现如下提示： The PHP module “imagick” in this instance has no SVG support. 具体表现为： 环境背景（概述） 初步判断 系统层 ImageMagick 验证 通过系统命令确认： 结论： 系统层 ImageMagick 支持 SVG PHP imagick 状态验证 查询 PHP imagick 模块信息，发现： 进一步使用 PHP 接口查询 SVG 支持情况，返回结果为空。 结论： PHP imagick 实际并不支持 SVG 关键分歧点：动态库不一致 …

摘要 在自建 RustDesk 服务器的过程中，一个常见且重要的问题是：如果他人不知道服务器的公钥（Key），是否仍然可以连接或使用该服务器？ 本文从 RustDesk 的信任模型出发，澄清公钥在系统中的真实作用，并明确区分以下几个常被混淆的概念： 一、RustDesk 中「公钥（Key）」的真实作用 在 RustDesk 的自托管架构中，服务器会生成一组非对称密钥： 该公钥的核心作用是： 让客户端确认：当前连接的 RustDesk 服务器，是否为“被信任的那一台”。 换言之，公钥是 服务器身份的信任锚点，而不是传统意义上的“访问密码”。 二、如果他人不知道公钥，会发生什么？ 情况一：既不知道服务器地址，也不知道公钥 这是最常见的情况。 结果：完全不可达。 情况二：知道服务器地址，但不知道公钥 这种情况可能来自于： 在此情况下： 结果是： 服务器可能“被看见”，但无法“被用”。 情况三：尝试强行连接或绕过公钥校验 RustDesk 的客户端在缺失或不匹配公钥时，信任链无法建立，表现为： 这并非“弱密码可猜”的问题，而是 设计层面的信任校验失败。 三、需要特别澄清的一个误区 一个常见误解是： “只要公钥不公开，服务器就是完全安全的。” 这是不准确的。 公钥解决的问题是： 公钥并不解决的问题是： 换句话说： 公钥 ≠ 防火墙公钥 ≠ 访问控制列表公钥 ≠ 攻击面消失 四、真正的安全边界在哪里？ 在 RustDesk 的自建场景中，真实的安全边界通常包括： …

一、背景说明 在一套基于 Docker Compose 运行的 mailcow 邮件系统中，随着服务组件逐渐增多，内存占用开始成为需要关注的资源项。系统主要用于低频、自用场景，不存在大规模外部用户或高并发邮件流量。 在对整体容器资源使用情况进行评估后，发现部分组件在当前使用场景下性价比偏低，有进一步精简的空间。 二、资源使用情况初步分析 通过 docker stats 对运行中的容器进行统计，可以观察到以下特点： 基于上述观察，决定对这两个组件进行停用验证。 三、停用 OnlyOffice 的处理结果 OnlyOffice 作为独立服务容器，在停止后： 该结果符合预期，表明 OnlyOffice 与核心邮件链路无强依赖关系，适合在不需要在线文档协作的场景下停用。 四、ClamAV 的停用方式与验证 4.1 配置层面的停用方式 mailcow 并不推荐直接修改 docker-compose.yml 或手动删除 service，而是通过配置变量控制组件启停。 在配置文件中设置： 该变量用于告知 mailcow 在启动阶段跳过 ClamAV 相关逻辑。 4.2 实际运行行为观察 停用后仍可在容器列表中看到 clamd 容器，但其行为发生了明显变化： 这表明： 从功能和资源角度看，ClamAV 已处于“逻辑完全禁用”状态。 五、停用后的整体状态评估 在 ClamAV 与 OnlyOffice …