我们有一个功能，可以接收来自经过身份验证的最终用户的请求，然后使用 API 机密等与第三方服务建立另一个安全连接，包括用户所需的 IP 地址、IPv4 IP。
对于几乎每个用户来说，这都不是问题，因为我已经能够获得请求标头
X-Forwarded-For当我联系其中一位用户，询问他们访问 Whatismyip.com 后得到了什么时，他们得到了一个公共 IP
107.140.xxx.xxx26xx:17xx:2dx:a7xx:e8xx:36xx:xxxx:xxxx只有 6to4 表示法或 IPv4 映射表示法中的地址才能转换回 IPv4 地址
我还有什么选择吗？我知道这里真正的问题是我们现在都应该使用 IPv6，无论如何，但我们无法控制第三方，而且他们需要 IPv4 地址。
简短的回答是“你不”。两种寻址方案之间不存在一般交叉；您无法将地址从一个版本转换到另一个版本。
您可能见过的任何“地址转换”方法都特定于转换机制 – IPv6-over-IPv4 隧道，允许纯 v4 客户端通过第三方中继进行某些 IPv6 访问。这些方法仅在应用于特定地址类型时才有意义 - 例如"6to4" 2002:xxyy:zztt:: 地址是通过嵌入 IPv4 地址生成的，因此您可以从中提取原始地址，但当应用于“本地”ISP 提供的 IPv6 地址时，相同的方法没有任何意义。
如果用户通过 IPv6 联系您，但您绝对需要将 IPv4 地址转发到其他地方，则有几个选项，具体取决于用户类型以及 IPv4 地址的使用方式。
请记住，用户可能有也可能没有单个 IPv4 地址 – 一方面他们可能拥有静态 IPv4 的完整双栈连接，但另一方面他们可能位于 ISP 的 CGNAT 网关共享后面与许多其他客户的 IPv4 池，或者他们甚至可能没有任何 IPv4（ISP 的 NAT64 网关再次拥有 IPv4 地址的共享池）。
理论上，获取客户端 IPv4 地址的一种方法是设置客户端被迫连接到的纯 IPv4 端点（例如通过重定向或 iframe）。但你不知道通过这种方式获得的地址实际上是否会在一周甚至仅 5 分钟内保持有效。 （就此而言，即使不涉及 IPv6，您也可能有许多仅使用 IPv4 的用户通过 CGNAT 访问您，并且没有自己的 IPv4 地址！）
因此，如果客户端将直接使用的 API 需要该地址，那么您唯一的选择是明确询问客户端他们想要允许什么 IPv4 地址，以便他们可以做出明智的决定（并且可能与他们的 ISP 安排静态 IPv4 地址）。
如果 API 仅由您自己的应用程序使用，那么您的另一个选择是代表客户端代理请求：您将始终指定代理服务器的地址，而不是需要客户端的 IPv4 地址。 （优点是您不必将客户的个人信息也发送给第三方。）