Network

家庭网络自建邮件服务器：关于是否需要固定 IP 的一次完整评估

一、场景说明 在一个典型的家庭自托管环境中，网络结构通常具备以下特征： 邮件服务器并非面向公众提供邮箱服务，而是用于： 是否接收来自互联网的外部邮件，并非初始刚性需求。 二、最初遇到的现实限制 1. VPS 方案的端口问题 常见的做法是使用一台低成本 VPS 作为公网入口或中转节点。然而在实践中发现： 即便 VPS 成本低廉，只要 25 端口被封禁，在邮件接收场景下就会出现功能性不可用的问题。 2. 家庭宽带（MAP-E / IPv4 over IPv6）的天然约束 在未申请固定 IPv4 的家庭宽带环境中，常见网络形态包括： 在这种情况下： 因此，“直接在家庭网络中接收外部邮件”在默认条件下并不可行。 三、被认真评估的解决方案：家庭固定 IPv4 为了解决端口受限问题，评估了运营商提供的固定 IPv4 服务。该方案在技术层面具有明确优势： 成本结构（已脱敏） 与现有 VPS（月费约 500 日元）相比，固定 IP 带来了额外且长期的成本。 四、关键转折：重新界定真实需求 在进一步分析后，一个核心问题被重新提出： 邮件服务器当前是否真的需要接收来自外部的邮件？ 对邮件系统的实际用途进行梳理后，可以明确： 由此可以得出一个重要结论： “无法接收外部邮件”并不会影响当前系统的实际功能价值。 五、工程视角下的理性判断 1. 固定 IP 的技术价值是确定的 …

Network

公网端口转发与 VPS + FRP：谁能看到真实访客 IP？

在自建服务（如 Web、SSH、邮件、游戏服务器等）的过程中，是否能够识别真实访客 IP 是一个非常关键、但常被忽略的问题。本文对两种常见方案进行对比分析： 重点讨论：后端服务究竟能看到什么来源 IP。 一、问题背景 常见的家庭或个人服务器部署方式主要有两类： 两种方案在“能否访问服务”上都可行，但在访问者 IP 可见性上存在本质差异。 二、结论先行 使用公网 IPv4 + 路由器端口转发时，局域网服务通常可以直接看到访问者的真实公网 IP。 使用 VPS + FRP 时，局域网服务只能看到 VPS 的 IP，无法直接获得真实访客 IP。 这是由网络连接模型决定的，而非配置错误。 三、公网 IP + 端口转发的工作机制 端口转发的本质是 DNAT（Destination NAT，目标地址转换）： 关键点： 因此： 四、实际表现 在这种架构下： 这是网络层原生行为，无需额外配置。 五、VPS + FRP 的连接模型 FRP 属于反向隧道工具，其连接关系为： 在该模型中： 因此在内核层面： 这是设计决定的，无法通过简单配置绕过。 六、FRP 是否能“传递”真实 …

Network

OpenWrt 公网端口转发 + Nginx 子域名反向代理完整实践与故障排查记录

一、背景与目标 在家庭网络环境中，已获得 公网 IPv4，并希望实现以下目标： 这是一个典型、标准、可长期维护的公网自建服务架构。 二、目标架构设计 最终期望的网络拓扑如下： 设计原则： 三、初始异常现象 在配置完成后，出现以下问题： 四、问题一：OpenWrt 抢占 80 / 443 1. 关键证据 使用 curl -vk 访问子域名，发现： 这说明： 2. 根因定位 检查 OpenWrt 的 uhttpd 配置： 含义： 3. 修复方式（关键一步） 将 OpenWrt 的 Web 管理界面 限制为仅监听 LAN IP： 或直接将管理端口改为 8443。 重启服务： 验证监听状态： 确认 不再存在 0.0.0.0:80/443。 五、问题二：DNAT 规则缺失 在释放 …

Network

家庭网络架构选择：固定 IP 还是 VPS + FRP？

在家庭宽带环境中，如果希望实现远程访问、自建服务或长期运行的后台系统，通常会面临一个关键选择： 使用家庭宽带固定公网 IP，还是使用 VPS + FRP 的反向穿透架构？ 这并不是一个“哪个更高级”的问题，而是一个工程取舍问题。本文从安全性、可控性、稳定性和长期维护角度，对两种方案进行系统对比。 一、家庭宽带使用固定 IP 的核心价值 固定公网 IP（静态 IP）最大的优势，在于地址稳定、访问路径直观。 固定 IP 的主要优势 从功能角度看，固定 IP 的确“简单直接”。 二、固定 IP 在家庭场景下的现实问题 在真实环境中，家庭固定 IP 往往伴随一些结构性问题： 1️⃣ 家庭网络被永久暴露 即便配置防火墙，暴露本身就是风险源。 2️⃣ ISP 合规与稳定性不确定 3️⃣ 故障与迁移成本高 三、VPS + FRP：反向穿透的工程逻辑 相比之下，VPS + FRP 并不是“权宜之计”，而是一种明确的工程设计选择。 FRP 的本质 FRP 并非传统意义上的“穿透工具”，而是： 由内向外建立的长期反向连接隧道 家庭网络主动连接 VPS，不接受任何外部入站请求。 四、VPS + …

Linux

从 SteamCMD 到 Docker：一次 Ubuntu 服务器的 i386 架构彻底清理实录

摘要 在长期运行的 Ubuntu 服务器上，历史遗留的 32 位（i386）架构往往来自早期软件需求，例如 SteamCMD。这类依赖在功能退役后若不清理，会增加系统复杂度、降低可预测性。本文记录了一次完整、可控的 i386 架构移除过程，并最终将异构需求交由 Docker 处理，使宿主系统回归纯 amd64 状态。 一、问题背景 在一台 Ubuntu 22.04 服务器上，通过以下命令确认系统启用了 i386 架构： 输出显示： 进一步检查已安装的 32 位软件包： 结果发现系统中存在大量 libc6:i386、libssl3:i386、zlib1g:i386 等基础库，但唯一的应用级包来源是 SteamCMD（32 位）。 随着使用策略调整，决定不再在宿主机直接运行 SteamCMD，而改用 Docker 容器 承担此类需求，于是启动了 i386 架构的彻底清理。 二、初步尝试与关键误区 在移除 SteamCMD 后，直接尝试移除架构： 结果失败： 原因很明确：只要系统中仍存在任何 :i386 包，dpkg 就不会允许移除该架构。 三、apt 通配符陷阱 尝试使用 apt 通配符清理： …

Games

使用 Docker 迁移《饥荒联机版（DST）》专用服务器的完整实战记录

本文记录一次将 原生安装的《饥荒联机版（DST）》专用服务器 平滑迁移至 Docker 容器环境 的全过程。重点不在“如何一键搭建”，而在 配置复用、端口一致性、MOD 自动管理、Shard 分片通信验证 等关键细节。 一、迁移背景与目标 原服务器为 原生 Linux 安装 的 DST Dedicated Server，运行多年，具有以下特点： 迁移目标不是“重装”，而是： 在 Docker 中完整接管运行环境，但不破坏任何已有数据结构与行为逻辑。 核心原则： 二、整体目录结构设计（脱敏示意） 宿主机统一使用一个工作目录： 关键说明： 三、Docker 镜像选择与原则 使用的镜像类型： 原则： Docker 只负责“跑”，不负责“改”。 因此明确禁止镜像行为： 四、Docker Compose 设计要点（概念说明） 1️⃣ 使用 host 网络模式 原因： 👉 所有端口直接由 ini 文件控制 2️⃣ Master / Caves …

Games

使用 Docker 运行 Palworld 专用服务器的一次完整、可控实践记录

一、写在最前面：为什么要“认真”跑一个游戏服务器 很多教程的目标只有一句话： “服务器能跑，能进就行。” 但在真实服务器环境中，这种目标是不够的。 本次实践的目标从一开始就明确为： 这不是“为了折腾”，而是为了避免后期不可控成本。 二、总体设计思想 1. 核心分离原则 在本方案中，Palworld 服务被拆成三层： 层级 角色 处理方式 世界数据 核心资产 永久保存在宿主机 配置文件 行为定义 由管理员手动维护 容器 执行外壳 可随时删除 一句话总结： 世界不属于容器，容器只是世界的“临时执行环境”。 三、目录结构设计（完全脱敏） 以下为逻辑结构示意，非真实路径： 关键点说明 四、Docker Compose 的设计原则（而不是参数堆砌） 1. 镜像使用原则 原因很简单： 运行环境应尽量无状态、无外部依赖 2. 环境变量的克制使用 在 compose 中： 这样做的好处是： 3. 禁止自动生成 / 覆盖配置 明确禁止镜像在启动时： 这是防止世界“被重置”的关键步骤之一。 五、端口策略（完全脱敏说明） 1. 对外端口原则 …

Server

将 Anki Sync Server 数据迁移至应用目录的实践

在非系统包管理（非 APT/YUM 等）环境下运行 Anki Sync Server 时，默认的数据存储位置与传统 Linux 目录结构往往不利于长期维护、迁移和备份。本文记录了一次将 Anki Sync Server 的数据目录从默认位置迁移并集中到应用目录下的实践过程，并总结了其中涉及的关键机制与注意事项，为需要“手动管理应用”的使用场景提供一种可复制的方案。 一、问题背景 Anki Sync Server 官方支持通过 Python 模块 anki.syncserver 运行同步服务。在默认配置下： 在以下场景中，上述默认行为会带来不便： 因此，有必要将 Anki Sync Server 的数据目录显式迁移到应用自身目录中。 二、官方机制说明（关键前提） 根据 Anki 官方文档说明： 这意味着，任何迁移方案都必须围绕 SYNC_BASE 这一官方支持的接口展开。 三、目标设计：应用自包含目录结构 迁移的目标并非简单“换路径”，而是形成一种清晰、稳定、可迁移的目录布局： 该结构具有以下特点： 四、迁移步骤概述 1. 停止同步服务 在任何数据操作之前，应先停止正在运行的同步服务，避免并发写入。 2. 准备目标数据目录 在应用目录下创建专用的数据子目录（例如 data/），并确保权限正确。 3. 迁移已有服务端数据 将默认数据目录中的内容整体迁移到新的数据目录中，保持原有目录层级（每个用户一个子目录）。 迁移完成后，新的结构应直接呈现为： …

Code

从 10GB 到 512MB：一次数据库内存回收带来的整机重生

——PVE + Docker + Web 应用场景下的真实优化案例 一、问题背景 在一台运行于 Proxmox VE（PVE）上的 Linux 虚拟机中，同时部署了多种服务，包括： 该虚拟机分配了约 23GB 内存，长期观察到： 初步怀疑数据库内存配置不合理。 二、关键发现：InnoDB Buffer Pool 被设置为 10GB 通过查询数据库内部参数发现： 结果显示： 这是一套典型的数据库专用服务器配置，而当前系统实际上是一个多服务混合运行的 Web 主机。 在这种环境下： 其直接后果是： 三、目标：尽可能小，但不影响实际性能 该系统的目标是： 在不影响 Web 应用体验的前提下，将数据库内存压缩到合理的下限。 最终采用如下配置： 设计原则： 四、效果：数据库从“内存黑洞”变为“可控组件” 重启后验证： 数据库进程内存占用： 与 512MB 的 buffer pool 高度一致，说明配置准确生效。 五、整机内存结构发生根本变化 优化后系统状态： 含义： 本质变化是： 从“数据库私有缓存主导”→ “操作系统统一缓存主导” …

Games

在 Forge MC 上将内存从 4GB 精准压缩到 1GB：一次可复现的实战调优

Minecraft Forge 服务端在模组较多时，常被配置为 4GB 甚至更高的堆内存（-Xmx）。然而在单人或轻负载场景中，这种“宽松配置”并不一定更快，反而可能带来启动慢、GC 扫描范围大、系统缓存被挤占等问题。本文记录一次从 4G 压缩到 1G 的实际调优过程，并解释为何更小的堆在该场景下更高效、更稳定。 一、启动方式与 Forge 的参数体系 Forge 1.x.x 使用“参数文件”来管理复杂的启动参数。典型的启动命令形如： 其中： unix_args.txt 的作用是拼装 Forge 的启动链路（BootstrapLauncher、SecureJarHandler、ASM、ModLauncher 等）与类路径，不会设置 4GB 内存。 二、为什么“看起来像 4GB”？客户端与服务端的混淆 调试时常会看到 F3（调试界面）里显示 …/…/4096MB，这并不一定来自服务端。当使用第三方启动器（如 HMCL）启动客户端时，客户端 JVM往往被配置为 4GB，因此 F3 显示的是客户端进程的上限。服务端是否 1GB 或 4GB，应以 systemd 或 jcmd 的 JVM 参数为准。 三、systemd 中的 Memory 为何高于 Xmx systemd 的 …