出向 IP 最佳实践

当你为账户开启专用出向 IP 时，Cloudflare 将根据几个因素（包括用户的物理位置和他们当前请求的资源位置）自动在你的 IP 之间平衡所有用户流量。例如，如果你在阿姆斯特丹、伦敦和华盛顿特区拥有出向 IP 位置，且未配置任何策略，Cloudflare 将为你的用户分配以下出向 IP：

• 荷兰附近用户的阿姆斯特丹出向 IP
• 英格兰附近用户的伦敦出向 IP
• 北美用户的华盛顿特区出向 IP

由于 Cloudflare 的网络设计，你的用户仍将在 Cloudflare 网络上采用尽可能最快的路由来到达其目的地。在大多数场景中，添加出向 IP 将带来微不足道的延迟。

Cloudflare 建议在最准确地匹配用户物理位置的区域预留分布的 IP。例如，如果你所有的用户都在北美，你应该考虑在北美各个数据中心提供一系列 IP，以确保所有用户的冗余和性能。

如果你有需要显式出向的位置，你还应当预留多个出向 IP。例如，如果你有需要从伦敦出向且不能回退到都柏林的用户，你需要在伦敦各个位置部署多个 IP 以确保冗余。单独地，你需要构建一条与具备此需求的所有用户相关的策略，以确保其所有流量都使用你的伦敦出向 IP 之一出向。

出向策略最常见的用例之一是为访问可能不支持 SAML 的 SaaS 应用程序（或只能使用 IP 级别控制的供应商服务）的用户确保一致的出向 IP。如果有选项——或者如果你的企业控制着该应用程序——Cloudflare 强烈建议使用 Cloudflare Access 从基于 IP 的身份验证转变为使用持续评估的基于身份特征的身份验证。

我们建议构建可以覆盖绝大多数用例的基线出向策略，而不会使策略管理过于复杂。如果你所有的用户都需要访问一系例都需要特定出向 IP 的应用程序，你应该构建一条针对这些用户（或所有用户）的显式策略，以确保其所有流量都使用这些出向 IP 出向。例如，你可以为具备财务数据访问权限的用户定义特定的出向 IP：

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/gateway/rules" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"action": "egress",
		"description": "Define static egress for finance team",
		"enabled": true,
		"filters": [
				"egress"
		],
		"name": "Finance team static egress",
		"precedence": 0,
		"identity": "any(identity.groups.name[*] in {\"finance\"})",
		"rule_settings": {
				"egress": {
						"ipv4": "<DEDICATED_IPV4_ADDRESS>",
						"ipv4_fallback": "<SECONDARY_DEDICATED_IPV6_ADDRESS>",
						"ipv6": "<DEDICATED_IPV6_ADDRESS>"
				}
		}
	}'

你可能有一些用例，其中特定的用户组可能需要更改其出向的位置。Cloudflare 经常就需要测试资源（就好像他们从不同的预定区域进行访问一样）的应用程序或站点的质量保证 (QA) 团队观察到这一点。你可以在需要时通过出向策略管理这一点，但大多数 Cloudflare 用户更喜欢在不对管理面板和现有策略进行持续更改的情况下进行管理。为了适应这一点，你可以构建虚拟网络作为出向策略中的选择器。这将允许你的用户更改其附加的虚拟网络，并随后按照其选择更改其出向 IP。

有关更多信息，请参阅我们的用户可选出向 IP 教程。