一个简单的NGiNX配置就足够了：

http {
    upstream proxy_pool {
        # Define your existing proxy servers here
        server proxy1.example.com;
        server proxy2.example.com;
        # Add more proxy servers as needed
    }
    server {
        location / {
            proxy_pass http://proxy_pool;
            # Other proxy settings, like headers, timeouts, etc.
        }
    }
}

这将把Nginx收到的请求转发到定义的池中的一个代理，这取决于负载平衡算法。
VPS示例上的后端服务应配置为使用Nginx服务器作为其传出请求的代理。
这种方法确保来自VPS示例的所有请求都通过集中式Nginx服务器，然后通过现有的代理池转发到后端网站，保持连接到同一代理服务器的约束来自同一IP地址（Nginx服务器的IP）。
然而：粘性会话，通常通过Nginx中的ip_hash指令实现，如图所示，将来自同一客户端IP的请求一致地路由到同一后端服务器。这是一种以客户端为中心的方法，确保客户端的请求始终由同一台服务器处理。
在您的场景中，连接到Nginx代理的“客户端”不是单个最终用户，而是在各种VPS上运行的后端服务的示例。这些示例通过代理池向后端网站发出请求。
您已经指定，如果同一代理服务器打开了多个连接，则它们应该来自同一IP地址。这里的挑战是确保到池中特定代理服务器的所有连接都来自同一个VPS示例，而不仅仅是同一个客户端IP。
在Nginx中实现粘性会话将确保来自特定VPS示例的所有请求始终到达同一代理服务器。但是，它不会阻止其他VPS示例也被路由到同一代理服务器，这可能违反您的约束，即所有连接到同一代理服务器都来自同一VPS示例。
在这种特定情况下，您可能需要一个更定制的解决方案来协调VPS示例，并根据连接要求确定每个示例应该使用哪个代理服务器。可以考虑使用共享数据库或专用协调服务等协调机制，以确保所有VPS示例都符合您对代理使用的特定要求。

我尽了最大的努力来应用@VonC的答案中的解决方案，玩了很多头配置，但不幸的是，它从来没有为我工作过，代理服务器总是返回一个带有400状态代码的错误：Bad Request。
实际上对我有效的解决方案就像这样简单：

stream {
    upstream proxy_pool {
        server <proxy1_ip>:<port>;
        server <proxy2_ip>:<port>;
        random;
    }
    server {
        listen 3333;
        proxy_pass proxy_pool;
    }
}

所以我没有使用http模块，而是使用了stream模块，它实际上默认安装在Nginx服务器上（不需要单独构建）。这样我也不需要添加任何额外的头配置。
使用这种方法，我也不需要在我的Nginx服务器上存储代理的凭据。当服务使用Nginx服务器作为代理时，它会传递凭据，就好像它们是为我的Nginx代理而设的，Nginx会将具有给定凭据的请求重定向到实际代理。
通过这种设置，整个流程看起来像这样：
My Service-登录名/密码-> Nginx Proxy-相同（重定向）登录名/密码-> Random proxy from proxy_pool-> Website
因此，代理服务器“认为”所有请求都来自我的Nginx服务器的IP，即使它们最初是从我的VPS的不同示例发送的。这样我就可以绕过代理限制。