我们运行多个 Web 应用程序，一些仅供内部使用，一些供内部/外部使用。我正在制定一个提案，即使用反向代理服务器隔离原始服务器、提供 SSL 终止并（如果可能）提供负载平衡。对于我们的大部分设置，我相信它会运行良好，但我们确实有一些鲜为人知的专有应用程序，在我们继续使用反向代理时可能需要特殊处理。
将原始服务器从前线移到代理后面时，哪些类型的陷阱容易导致问题？（例如，如果应用程序需要知道传入请求的 IP 地址，我可以想象会出现问题。）
答案1
最常见的陷阱是应用程序中生成的重定向，您必须在反向代理中重写这些重定向，您已经说过客户端 IP 地址问题，如果使用 SSL 终止，服务器可能想要检查客户端证书或从中获取用户信息。为了正确进行边缘端反向代理缓存，可能需要修改应用程序（适当的过期标头、取消设置不需要的 cookie 等）。如果您使用的是 Windows 集成身份验证，这可能是无法实现的，或者是一场真正的噩梦
然后你可能会遇到调整问题，但我认为这些问题会更容易解决。我为这项任务首选的工具集是：
- 外层的Nginx用于虚拟主机管理和位置映射、压缩、ssl、访问日志记录
- 用于缓存的清漆
- haproxy 用于请求排队、负载平衡和后端检查。
- 如果你需要高可用性，那么反向代理盒 keepalived 可以满足你的要求
答案2
使用反向代理后的应用程序可能会遇到的问题：
- 如果语言或应用程序使用 IP 地址来保持会话，则到达应用程序的唯一 IP 地址将是代理 IP 地址。使用
nginx，varnish您可以添加X-Forwarded-for带有原始 IP 地址的标头，并使应用程序识别它。 - 在负载平衡环境中处理会话非常棘手。您必须使用共享资源来保存服务器的会话信息，以便登录的用户可以访问负载平衡应用程序的任何后端并保存其会话。数据库和 Memcached 是会话共享的热门选择。
- 如果反向代理应用程序在其响应中使用绝对 URL，则它们可能会破坏代理上的重写。即执行 302 重定向的应用程序会重定向到与代理不同的 URL。
我目前使用nginx在前端和漆在其后面执行代理和负载平衡/后端检查。由于存在单点故障，在反向代理/负载平衡器上使用集群解决方案非常重要。
我用corosync/pacemaker（Linux HA，最新版本）用于对负载均衡器进行负载平衡：三个负载均衡器，每个都有一个外部 IP 地址，使用 DNS 进行 RR 平衡（一个名称指向三个 IP 地址）。如果其中一台机器停机，则 corosync 将为其指定的 IP 地址移动到其他两台剩余机器之一。此外，如果我添加更多机器/IP 地址，它们会自动平衡，如果除一台机器外所有机器都停机，则所有 IP 都将位于正常运行的机器上。您可以使用 corosync 进行主动-主动、主动-被动和许多其他集群配置。
答案3
一种常见（且便宜）的方法是使用 squid 作为反向代理...您应该看看他们的常见问题解答，其中讨论了常见问题..Squid 反向代理常见问题解答
答案4
在 Linux/BSD 和其他一些操作系统上，代理完全有可能伪装成客户端 ip - 这样您就不会失去可见性（这使用操作系统的网络功能 - iptables/ipfw - 而不是代理的）。
如果您在某个应用程序上使用客户端证书认证，那么您将很难取代 SSL 终止点并维护安全性。
负载平衡可能很棘手 - 对于 http 应用程序，您必须在整个集群中实时复制状态 - 或者使用“粘性会话”，这会破坏容错原则（使用有限复制/定义会话故障转移的混合方法通常是最实用的解决方案）。