自建服务配置实战手册：自建邮局（25 端口 / Postfix / DNS）、Docker 防火墙加固与 PostgreSQL 调优

1. 自建有状态服务对底层 KVM 宿主机的权限要求

自建独立发信邮局（Mailcow / Stalwart / Postfix）、关系型数据库（PostgreSQL / MariaDB）与私有云盘（Nextcloud / Immich）依赖多项常被普通云厂商限制的底层网络与存储权限：

2. 自建域名邮局完整配置：解封 25 端口、DNS 记录表与 Postfix IPv6 绑定

要让自建邮局向 Gmail、Outlook / Microsoft 365 及企业邮箱稳定直投且通过全部合规校验（SPF: PASS、DKIM: PASS、DMARC: PASS、PTR: PASS），请按顺序完成以下四步：

第一步：在 SCP 移除 netcup Mail block 并用命令验证 25 端口出站

登录 https://www.servercontrolpanel.de → 选择服务器 → 进入 Firewall → 移除默认挂载的 netcup Mail block 规则集并点击 Save。随后在服务器终端执行以下诊断命令，验证到 Gmail MX 服务器的 TCP 25 端口出站是否已打通：

# 1. 验证 IPv4 与 IPv6 到 Gmail 邮件网关的 TCP 25 端口出站连通性（应返回 succeeded / 220 mx.google.com ESMTP）
nc -zv -4 -w5 gmail-smtp-in.l.google.com 25
nc -zv -6 -w5 gmail-smtp-in.l.google.com 25

# 2. 核验当前服务器 IPv4 与发信 IPv6 地址的反向解析（PTR）是否已指向你的邮局域名
dig +short -x $(curl -s4 icanhazip.com)
dig +short -x 2a03:4000:60:1234::1

第二步：配置域名 DNS 解析与 SCP 反向解析（FCrDNS 标准记录表）

假设你的主域名为 example.com，邮局主机名为 mail.example.com，服务器 IPv4 为 46.38.240.10，分配的 IPv6 地址为 2a03:4000:60:1234::1。先在 SCP > Network 将上述两个 IP 的 rDNS 设为 mail.example.com，再在你的 DNS 服务商处添加以下 6 条记录：

第三步：关键避坑 — 固定 Postfix 出站发信 IPv6 地址（防止 Gmail 拒信）

由于 netcup 分配的是整个 /64 IPv6 子网，若你在网卡上绑定了多个 IPv6 地址或开启了临时隐私地址，Postfix 出站时可能随机选取一个未配置 PTR 反向解析的 IPv6 地址连接 Gmail，导致直接报错 550-5.7.25 The IP address sending this message does not have a PTR record。请在 /etc/postfix/main.cf 中显式锁死发信源 IP：

# /etc/postfix/main.cf 关键发信绑定参数
myhostname = mail.example.com
smtp_helo_name = mail.example.com
inet_protocols = all

# 强制指定出站 SMTP 客户端使用的唯一 IPv4 与已配置 PTR 的 IPv6 地址
smtp_bind_address = 46.38.240.10
smtp_bind_address6 = 2a03:4000:60:1234::1
smtp_tls_security_level = may
smtpd_tls_security_level = may

3. 修复 Docker 绕过 UFW 防火墙漏洞：daemon.json 与 SCP 规则表

在 Linux 默认配置下，当你执行 docker run -p 5432:5432 postgres 时，Docker 守护进程会直接向内核 iptables 的 PREROUTING 与 FORWARD 链插入放行规则，完全绕过系统内的 ufw 或 firewalld 的 INPUT 链，导致数据库直接暴露在公网扫描之下。

双层防御配置方案（主机内部 + SCP 硬件外层）

第一层（容器侧）：在 compose.yaml 中将内部数据库、Redis 等端口严格绑定在 127.0.0.1，并配置 /etc/docker/daemon.json 限制容器日志体积（防止日志写满 NVMe 导致无法创建 SCP 快照）：

# /etc/docker/daemon.json（启用 IPv6 表管理 + 全局容器日志轮转限制为单容器最多 30MB）
{
  "ipv6": true,
  "fixed-cidr-v6": "fd00:dead:beef::/64",
  "ip6tables": true,
  "iptables": true,
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

第二层（SCP 宿主机硬件防火墙侧）：在 SCP > Firewall 中配置以下宿主机级入站白名单。由于 SCP 防火墙在宿主机虚拟网桥（tap 接口）外侧过滤数据包，哪怕容器在系统内错误绑定了 0.0.0.0:5432，公网流量也会在进入虚拟机前被 SCP 直接丢弃：

4. PostgreSQL 17 生产环境 NVMe 调优参数（以 RS 1000 G12.5 4C/8G 为例）

PostgreSQL 默认的 postgresql.conf 极其保守（shared_buffers 默认仅 128 MB，random_page_cost 默认按机械硬盘设为 4.0）。在配备 4 核独享 EPYC 9645 + 8 GB DDR5 + 高速 NVMe 的 RS 1000 G12.5 上，建议在 /etc/postgresql/17/main/conf.d/99-netcup-nvme.conf 中写入以下调优参数：

# 针对 4 核独享 EPYC + 8 GB DDR5 + NVMe RAID 的 PostgreSQL 17 生产调优参数
max_connections = 100
shared_buffers = 2GB                  # 物理内存的 25%
effective_cache_size = 5GB            # 物理内存的 60%–65%（供查询规划器评估 OS 缓存）
maintenance_work_mem = 512MB          # 加速 VACUUM 与 CREATE INDEX
work_mem = 16MB                       # 单次排序/哈希表内存上限
wal_buffers = 16MB
min_wal_size = 1GB
max_wal_size = 4GB
checkpoint_completion_target = 0.9

# 关键：告知查询规划器底层为低延迟 NVMe SSD（默认 4.0 会导致规划器拒绝使用索引扫描）
random_page_cost = 1.1
effective_io_concurrency = 200

# 并行查询线程数匹配 RS 1000 的 4 颗物理核心
max_worker_processes = 4
max_parallel_workers_per_gather = 2
max_parallel_workers = 4

5. Nextcloud / Immich 备份策略与推荐服务器型号

• 增量热备 + 离线整机冷备（3-2-1 架构）：日常通过 pg_dump + restic 每日凌晨加密备份至异地对象存储或另一台存储服务器；每逢跨大版本升级前，在 SCP 将机器关机 3 分钟创建 Offline Snapshot，导出 .raw.zst 全盘镜像下载到本地存档。
• 按自建规模匹配机型与当前实时优惠码：
  • 轻量套件（Stalwart 邮局 + 博客 + 反代，2–4 GB 内存）：选 RS 500 G12.5 或 VPS 500 G12.5（首单配合 新客户首单券（0% 税率立减 €4.20））。
  • 主力全栈（Mailcow 全功能邮局 + PostgreSQL + Nextcloud，8 GB 内存）：选 RS 1000 G12.5（4 核独享 + 8 GB DDR5 + 128 GB NVMe，优惠：免费 2 个月）。
  • 多租户与高算力栈（Immich 机器学习人脸特征索引 + GitLab CI/CD + 多库集群，16 GB 内存）：选 RS 2000 G12.5（8 核独享 + 16 GB DDR5 + 256 GB NVMe，优惠：免费 1 个月）。