专用终结点，同一服务器名：Azure SQL 连接字符串

Private Link 改变的是连接落到的位置，而不是连接的名字。对 Azure SQL Database 来说，这一区别就是全部设计：逻辑服务器保留自己的名字，专用终结点提供一个该名字可解析到的网络条目。用 IP 地址替换名字，是唯一会同时破坏 TLS、凭据和工具链的改动。两个连接字符串可能看起来等价，行为却完全不同。

保留 orders-db.database.windows.net，并为它向客户端提供专用应答。

名字和地址承担不同的职责

名字标识的是 SQL 服务，证书和登录所期望的正是这个。专用地址则在已连接的虚拟网络内提供一个网络条目。把两者混为一谈，得到的连接能到达某个目标，却无法通过任何身份验证。

Microsoft 对 Azure SQL 的指导要求客户端使用正常的服务器名。直接使用 IP，以及同样地使用带 privatelink 前缀的名字，都不是可互换的登录目标。接受 IP 的工具会收下它，然后在 TLS 或身份验证阶段失败，这反而掩盖了真正的错误。这类失败读起来像凭据问题，直到你去看报错里的主机名。

专用区域实际改变了什么

专用 DNS 区域在 privatelink 命名空间内为服务器记录一个地址，并且该区域关联到应当使用它的虚拟网络。解析位置发生了移动，连接字符串没有变。下面的形状只是示意，不是要粘贴到公共区域里的记录。

Application name:        orders-db.database.windows.net
Private DNS zone:        privatelink.database.windows.net
Resolved private entry:  the approved private endpoint address

把那条记录及其区域关联当作基础设施来维护，并指定负责人和复核日期。

同一来源却给出不同应答的两个区域，是正常的最终状态，而不是冲突。公共客户端保留公共应答，专用客户端得到终结点地址。需要留意的故障模式是专用视图的部分传播：一个子网按专用方式解析，另一个却悄悄没有。

Azure 之外的客户端需要一条通往该区域的路径

VPN 客户端位于 Azure 解析器之外，因此 专用区域必须能从混合路径访问到。Azure DNS 转发器或 Azure DNS Private Resolver 可以服务经由该网络到达的查询。Microsoft 的指导是：通过该安排转发相关的公共服务区域，而不是假设客户端直接查询 privatelink 这个名字。无法解析专用应答的客户端会悄悄回落到公共应答。

转发范围要有意控制，因为替换正在使用的公共区域，会破坏替代区域并不包含的名字。

按保持身份不变的顺序进行配置

各步骤有各自的负责人：创建并批准终结点，提供 VPN 路由，集成专用 DNS，然后用其正常服务器名配置客户端。在路由之前做 DNS，会产生看起来像 DNS 故障的超时。把客户端放在最后，可以让每次只有一个变量在变。每一步都有可观察的结果，因此哪一步都不必靠猜来验证。

已连接的 VPN 图标本身并不会选择专用目标。

专用终结点不会关闭什么

创建专用终结点并不会自动关闭对逻辑服务器的公共访问。那是一个独立的部署决策，应当在确认目标专用客户端可用之后再做出。保留一条恢复路径，并考虑仍在使用公共入口的应用。先关闭公共访问，正是让正常服务变成带整洁审计轨迹的故障的方式。

还要检查服务器使用的是哪种连接策略。

Redirect 会在初始网关连接之后把客户端送到节点上的某个端口，这改变了客户端网络必须放行的内容。Proxy 则让流量留在网关上。单个端口上 TCP 握手成功，并不等于整个登录流程。

这是 Azure SQL Database，而不是 SQL Managed Instance，后者有自己的连接模型，也没有对应的专用终结点说法。两种情况下都要把三样东西分开标注：名字、网络条目和凭据。改变连接走哪条路，永远不该改变客户端以为自己在跟哪个服务对话。