Category: Network

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

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

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

摘要 某台运行 Postfix 的 Linux 服务器在连续多天内无法向自建 Mailcow 邮件服务器发送系统告警邮件，邮件队列持续增长。表面错误为 DNS 解析失败（4.4.3 Host not found），在 DNS 修复后仍存在投递异常。最终发现是 SMTPUTF8 协议能力不匹配导致部分邮件被永久拒绝（5.6.7）。 本文完整记录该事故的诊断路径与修复策略。 1. 事故现象 Postfix 日志中持续出现： 邮件队列中积压多封系统邮件（root → admin），时间跨度超过 5 天。 2. 第一层问题：DNS 故障导致长期队列堆积 检查发现系统的 /etc/resolv.conf 曾指向错误的网关地址（例如 192.168.0.1 而不是实际使用的 192.168.1.1），导致 Postfix 在那段时间无法解析 mail.example.net。 DNS 修复后： 均返回正确 IPv4 地址，说明系统 DNS 已恢复。 但邮件仍不断失败，是因为 Postfix 会对 4.x.x …