公有、私有、静态和专用是相互独立的地址属性。构建一张部署图，其中还涵盖路由、防火墙、正向 DNS、反向 DNS 和 TLS，并与控制每项设置的一方核实。
地址属性回答不同的问题
公有和私有描述地址预期在何处路由。静态和动态描述分配随时间的行为。专用和共享描述地址在服务中如何使用或分配。这些是相互独立的属性：一个稳定的公有地址可能服务许多站点，而私有地址可以在受控网络内动态分配。
在部署中写下每个地址的角色：公共入口点、内部数据库、管理路由或出站连接。然后确定谁分配它以及什么可能改变。这可以防止配置工作依赖于诸如“专用意味着永久固定”或“公有意味着服务可达”之类的假设。可达性还取决于路由、防火墙和应用的监听器。
私有寻址仍然需要路由和访问控制
RFC 1918 为专用网络保留了 IPv4 范围 10.0.0.0/8、172.16.0.0/12 和 192.168.0.0/16。它们的地址不是全局唯一的公共目的地。网络可以为出站连接转换私有地址，或通过显式路由连接专用网络。转换后的入站服务需要一种刻意的发布方法；仅更改 DNS 记录并不能创建该路由。
IPv6 有自己的地址类型和范围，包括链路本地寻址和全球可路由单播地址。请单独审查它，而不是假设 IPv4 防火墙或转换规则覆盖 IPv6。私有地址不是身份验证机制，公有 IPv6 地址也不是暴露每项服务的理由。从每个相关网络测试访问，并在适当的边界限制管理。
稳定名称和稳定地址是相关的
DHCP 通过协议分配地址配置，并可以使用租约。动态分配的地址可能在一段时间内保持不变；这并不使其永久性成为合同保证。当应用依赖稳定地址时，请核实提供商的分配和变更政策，而不是从昨天的连接推断。
动态 DNS 可以在地址更改后更新名称，但客户端仍可能缓存先前的答案。它也无法克服不可达的监听器、缺失的入站路由或运营商级地址转换。当网络允许连接且应用能容忍更新延迟时使用它。对于托管部署，在围绕它构建允许列表或外部集成之前，记录预期的地址生命周期。
| 属性 | 需要确认的内容 | 常见的错误假设 |
|---|---|---|
| 公有或私有 | 路由范围和访问路径 | 仅凭地址就能使服务可达 |
| 静态或动态 | 分配和变更政策 | 未变化的租约就是永久的 |
| 专用或共享 | 分配和允许的用途 | 专用地址提供匿名身份 |
| IPv4 或 IPv6 | 路由和防火墙配置两者 | 一个协议的设置覆盖另一个 |
正向 DNS 和反向 DNS 有不同的所有者
正向 DNS 将名称映射到 A 和 AAAA 地址记录等数据。反向 DNS 使用与地址相关的命名空间和 PTR 记录将地址与名称关联。控制正向 DNS 区域的组织不一定是控制该地址范围反向 DNS 的组织。在承诺反向名称之前，获取正确的配置路径。
通过适当的解析器检查记录并记录结果。对于旨在标识主机的 PTR，还要检查相应的正向记录是否指向预期的地址。反向 DNS 可以支持运维标识和某些邮件系统检查，但它不验证应用，也不保证邮件送达。发送邮件还需要自己的域、信誉和身份验证审查。
并非每个 HTTPS 站点都需要专用地址
HTTP 主机路由和 TLS 服务器名称指示扩展允许受支持的客户端和服务器按名称选择站点或证书。因此，多个 HTTPS 站点可以使用一个地址，而不需要每个域一个公有地址。实际托管配置和所需客户端决定该安排是否合适。
只有当有文档记录的需求要求时才选择额外地址，例如受支持的网络隔离或期望不同端点的外部系统。地址并不能提供免受信誉问题影响的豁免，也不能识别运营服务的人。将证书、主机名路由和地址分配作为单独的检查。通过用户实际访问的主机名验证所提供的证书。
在更改记录之前使用部署图
创建一张小地图，包含每个主机名、地址记录、监听器、防火墙路径和负责方。包括管理、备份和任何出站允许列表。检查 SwissOctet 配置是否列出你需要的地址选项，并在依赖反向 DNS 控制之前询问其控制权。不要将目录选项呈现为已经配置好的实时分配。
在迁移期间，在将用户引导至目标之前，先准备好目标应用和 TLS 设置。考虑 DNS 缓存并保持可行的恢复路径。分别验证正向解析、实际应用可达性和预期的反向名称。该地图使故障更容易定位，因为错误的记录、关闭的端口和不匹配的证书是不同的问题，有不同的负责方。
您的实用清单。
- 映射地址角色、分配和所有权。
- 分别检查 IPv4 和 IPv6。
- 在依赖 DNS 之前验证入站路由。
- 确定谁控制 PTR 记录。
- 一起测试主机名、证书和应用。
重要细节。
专用 IP 会使服务匿名吗？+
不会。它描述的是分配或使用安排，不是身份或隐私保证。账户、流量和应用数据有各自的影响。
我可以从我的域的 DNS 面板设置 PTR 记录吗？+
只有当它也控制相关反向区域时才可以。地址提供商通常控制该区域或提供单独的请求流程。
每个 HTTPS 域都需要自己的地址吗？+
不一定。受支持的客户端和服务器可以使用基于名称的路由和 TLS SNI。请核实实际的托管和客户端要求。
前往来源。
这些参考资料支持本指南中的技术概念。在更改生产系统之前，请遵循当前文档。
- RFC 1918：专用互联网的地址分配 www.rfc-editor.org
- RFC 2131：动态主机配置协议 www.rfc-editor.org
- RFC 1035：DNS 实现和规范 www.rfc-editor.org
- RFC 4291：IPv6 寻址架构 www.rfc-editor.org
- RFC 6066：TLS 扩展，包括服务器名称指示 www.rfc-editor.org
由 SwissOctet 提供编辑指导。示例仅作说明。服务规格、可用选项和合同条件必须单独核实。