将NGINX和NGINX Plus用作透明代理，实现IP透明传递和直接服务器返回

Owen Garrett产品管理高级总监

本博文介绍如何将NGINX Open Source和NGINX Plus配置为上游服务器流量的透明代理，并说明如何使用透明代理伪造数据包的源IP地址以实现IP透明，以及如何为UDP流量实现一种名为直接服务器返回（Direct Server Return）的负载均衡模式。

本文信息同时适用于NGINX Open Source和NGINX Plus。为简洁起见，下文仅称NGINX Plus。

编者按：这是深入介绍NGINX Plus R10新功能的系列博客文章中的第5篇。

• 使用JWT和NGINX Plus对API客户端进行身份验证
• NGINX Plus R10充分利用IBM POWER
• 使用OpenID Connect和NGINX Plus对现有应用的用户进行身份验证
• 使用NGINX JavaScript模块将客户端逐步迁移到新服务器
• 使用NGINX和NGINX Plus作为透明代理实现IP透明和直接服务器返回（本文）

还可观看点播网络研讨会：NGINX Plus R10 有哪些新功能？

总结

NGINX Plus 作为第 7 层反向代理运行，因此可对其管理的网络请求应用多项优化和增强功能。

因此，上游（负载均衡）服务器会发现，所有流量都来自NGINX Plus代理上的某个IP地址。如果上游服务器需要确定真实的源IP地址（即远程客户端的IP地址），例如用于身份验证或日志记录，这就会带来挑战。

对于HTTP和HTTPS流量，可以使用以下有效的解决方法：采用X-Forwarded-For HTTP标头或PROXY 协议。本文还介绍了另外两种适用于TCP和UDP流量的方法：

• IP 透明性可确保上游服务器识别出每个连接均来自发起该连接的远程客户端。它适用于基于TCP和UDP的协议。
• 直接服务器返回（DSR）还可使上游服务器的响应绕过中间负载均衡器，直接发送到远程客户端。它适用于基于UDP的协议，可通过在源服务器或中间路由器上执行NAT（网络地址转换）来实现。

方法1：IP透明传输　方法2a：DSR（路由器NAT）　方法2b：DSR（源服务器NAT）支持的协议　基于TCP和UDP　仅基于UDP　仅基于UDP上游服务器的流量路由　所有出站流量均路由到NGINX Plus代理并在此终止　所有出站流量均通过中间NGINX Plus服务器路由　所有流量均按常规方式路由性能　标准：出站流量在NGINX Plus代理上终止　较好：出站流量由中间NGINX Plus服务器转发　更优：出站流量绕过NGINX Plus，直接路由到远程客户端健康检查　默认使用被动健康检查；支持主动健康检查　必须使用主动健康检查；无法使用被动健康检查　必须使用主动健康检查；无法使用被动健康检查所需配置NGINX Plus代理上的TCP和UDP　TCP：默认可用
UDP：proxy_responses 1　TCP：不支持
UDP：proxy_responses 0　TCP：不支持
UDP：proxy_responses 0数据包在何处以及如何处理？　iptables在NGINX Plus代理上终止数据包　tc nat在中间NGINX Plus服务器上重写数据包　tc nat在上游服务器上重写数据包NGINX Plus代理上的网络配置　使用iptables捕获出站数据包　IP转发和无状态NAT　无上游服务器上的网络配置　将NGINX Plus指定为默认路由　将NGINX Plus指定为默认路由　无状态NAT

IP Transparency和DSR的部署与故障排除较为复杂。仅当标准反向代理运行模式无法满足应用或服务需求时，才应实施这些配置。

简介：标准第 7 层反向代理中的数据包流

与仅转发数据包的交换机或路由器不同，NGINX Plus作为第7层反向代理运行。在此模式下，NGINX Plus分别管理客户端侧和上游侧的TCP连接（用于HTTP和TCP流量）或UDP会话，从而控制远程客户端与所选上游服务器之间的通信。

1. 远程客户端通过已发布的 IP 地址和端口直接与 NGINX Plus 反向代理建立 TCP 连接或向其发送 UDP 数据报。NGINX Plus 随后终止 TCP 连接或 UDP 会话，并读取其中的请求数据。
2. 然后，NGINX Plus与选定的（负载均衡）上游服务器建立新连接（或复用现有的空闲连接）。
3. 当NGINX Plus将请求写入上游服务器时，连接源自NGINX Plus的内部IP地址。
4. 当上游服务器响应请求时，会将数据写入NGINX Plus的内部IP地址。
5. NGINX Plus通过上游侧连接接收响应数据。它可能会处理或修改响应（例如，对HTTP响应应用压缩）。
6. 随后，NGINX Plus通过客户端侧连接写入响应数据。

这种标准反向代理运行模式会导致上游服务器观察到TCP和UDP流量来自本地NGINX Plus代理。

第 7 层反向代理模式的优势与局限性

第 7 层反向代理模式可显著提升 HTTP 和 TCP 流量的性能与处理效率（包括 TCP 优化、缓冲和 HTTP 保持连接复用）。但如果上游服务器需要确定连接或会话的真实源 IP 地址，以用于身份验证和访问控制、速率限制及日志记录等场景，这种模式会带来挑战。

For some protocols, NGINX Plus can use the X-Forwarded-For HTTP header or the PROXY protocol to provide the origin IP address to upstream servers. This post describes two additional methods, made possible by the transparent parameter to the proxy_bind directive, which was introduced in NGINX Plus Release 10 (R10)<.htmla>.

方法1：IP透明传输

IP Transparency旨在隐藏反向代理，使源服务器看到IP数据包来自客户端的IP地址。IP Transparency可用于基于TCP和UDP的协议。

在NGINX Plus负载均衡器上创建HTTP反向代理服务

为演示IP透明性，我们首先创建一个由4台Web服务器组成的负载均衡集群，这些服务器会返回一些简单的连接信息。

1. 配置一个简单的HTTP虚拟服务器，在一组上游服务器之间对流量进行负载均衡：

# in the 'http' context
server {
    listen 80;

    location / {
        proxy_pass http://http_upstreams;
    }
}

upstream http_upstreams {
    server 172.16.0.11;
    server 172.16.0.12;
    server 172.16.0.13;
    server 172.16.0.14;
}

1. 要确认上游服务器观察到连接源自NGINX Plus负载均衡器，请在这4台服务器（172.16.0.11至172.16.01.14）上分别配置一台NGINX Plus Web服务器，并设置一个简单的虚拟服务器以返回连接信息，例如：

# in the 'http' context
server {
    listen 80;

    location / {
        return 200 "Hello from $hostname. You connected from $remote_addr:$remote_port to $server_addr:$server_portn";
    }
}

测试此配置时，上游服务器报告连接源自本地NGINX Plus IP地址（172.16.0.1）：

$ for i in {1..4}; do curl http://192.168.99.10 ; done
Hello from dev1. You connected from 172.16.0.1:42723 to 172.16.0.11:80
Hello from dev2. You connected from 172.16.0.1:39117 to 172.16.0.12:80
Hello from dev3. You connected from 172.16.0.1:54545 to 172.16.0.13:80
Hello from dev4. You connected from 172.16.0.1:57020 to 172.16.0.14:80

配置NGINX Plus和上游服务器以实现IP透明传输

NGINX Plus R10及更高版本（以及NGINX Open Source 1.11.0及更高版本）可以伪装上游流量的源地址。请在proxy_bind指令中添加transparent参数。通常，将源地址设置为远程客户端的地址：

proxy_bind $remote_addr transparent;

不过，这个简单的步骤会带来一项重大挑战，因为必须确保正确处理发往远程客户端的响应（出站）流量。响应流量必须路由到NGINX Plus，并由NGINX Plus终止上游TCP连接。随后，NGINX Plus通过客户端TCP连接将响应流量发送到远程客户端。

需要对NGINX Plus负载均衡器和每台上游服务器进行多项配置更改：

1. 在NGINX Plus负载均衡器上，将工作进程配置为以root身份运行，使其能够将上游套接字绑定到任意地址。在/etc/nginx/nginx.conf的主（顶层）上下文中，添加user指令，将NGINX Plus工作进程的ID设置为root：

# in the 'main' context
# 'user daemon' is the default; change to 'user root' with transparent proxy_bind
user root;

1. 在NGINX Plus负载均衡器上，确保每个连接均源自远程客户端地址。将带有proxy_bind指令及其transparent参数添加到虚拟服务器配置中：

# in the 'http' context
server {
    listen 80;

    location / {
        proxy_bind $remote_addr transparent;
        proxy_pass http://http_upstreams;
    }
}

1. 在NGINX Plus负载均衡器上，配置iptables，以捕获上游服务器返回的数据包并将其传送到NGINX Plus。在本例中，我们运行iptables和ip rule命令，以捕获IP地址范围172.16.0.0/28所代表的服务器在端口80上的所有TCP流量：

# ip rule add fwmark 1 lookup 100
# ip route add local 0.0.0.0/0 dev lo table 100
# iptables -t mangle -A PREROUTING -p tcp -s 172.16.0.0/28 --sport 80 -j MARK --set-xmark 0x1/0xffffffff

1. 运行以下命令，列出（-L）iptables mangle表中的当前配置：

# iptables -t mangle -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination
MARK       tcp  --  172.16.0.0/28        anywhere             tcp spt:http MARK set 0x1

Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination

1. 在上游服务器上配置路由，将所有返回流量转发到NGINX Plus。在每台上游服务器上，删除任何现有的默认路由，并将默认路由配置为NGINX Plus负载均衡器/反向代理的IP 地址。请注意，此IP 地址必须与上游服务器的其中一个接口位于同一子网。

# route del default gw 10.0.2.2
# route add default gw 172.16.0.1

1. 检查路由表是否合理：

# route -n
Kernel IP routing table
Destination   Gateway     Genmask        Flags Metric Ref Use Iface
0.0.0.0       172.16.0.1  0.0.0.0        UG    0      0     0 eth2
10.0.2.0      0.0.0.0     255.255.255.0  U     0      0     0 eth0
172.16.0.0    0.0.0.0     255.255.255.0  U     0      0     0 eth2
192.168.56.0  0.0.0.0     255.255.255.0  U     0      0     0 eth1

1. 如果上游服务器需要连接外部服务器，还需要配置新的NGINX Plus网关以转发流量并进行地址伪装。请参阅下文的“允许上游服务器访问外部服务器”。

测试IP透明配置

现在，可以通过向NGINX Plus发送请求来测试该配置。请确保从上游服务器无法直接路由到的远程IP地址发送请求：

$ for i in {1..4}; do curl http://192.168.99.10 ; done
Hello from dev1. You connected from 192.168.99.1:60729 to 172.16.0.11:80
Hello from dev2. You connected from 192.168.99.1:43070 to 172.16.0.12:80
Hello from dev3. You connected from 192.168.99.1:45749 to 172.16.0.13:80
Hello from dev4. You connected from 192.168.99.1:46609 to 172.16.0.14:80

请注意，这些连接现在看起来源自远程客户端的IP地址（192.168.99.1），而不是NGINX Plus负载均衡器的本地地址。

如果配置不起作用，请参阅下方的“故障排除”。

总结：IP透明度配置如何工作？

• NGINX Plus接收来自远程客户端（192.168.99.1）的HTTP请求。
• NGINX Plus做出负载均衡决策，选择要连接的上游服务器（例如172.16.0.11）。建立连接前，NGINX Plus会将其上游套接字绑定到远程客户端的地址。
• 上游服务器接收到该连接，该连接看起来直接来自远程客户端。
• 上游服务器作出响应，将数据包发送到远程客户端的地址，并通过NGINX Plus（默认路由器）进行路由。
• NGINX Plus负载均衡器上的iptables规则会标记这些数据包，并通过路由将其传送到本地。
• NGINX Plus读取响应。
• 随后，NGINX Plus将响应发送给远程客户端。

最终结果是，从上游服务器的角度来看，连接似乎直接来自远程客户端。

方法 2：服务器直接返回

直接服务器返回（DSR）是IP透明概念的扩展。在IP透明模式下，上游服务器接收看似源自远程客户端的数据包。使用DSR时，上游服务器还会直接响应远程客户端，返回数据包完全绕过负载均衡器。

DSR可通过降低负载均衡器的负载来略微提升性能，但也存在一些限制：

• 负载均衡器始终无法看到返回数据包，因此无法检测上游服务器是在响应还是已发生故障。
• 负载均衡器在选择上游服务器之前，只能检查请求的第一个数据包，因此其做出负载均衡决策（基于内容的路由）的能力非常有限。
• 负载均衡器无法参与任何形式的协商或有状态处理，例如SSL/TLS。
• DSR无法支持大多数其他应用交付控制器（ADC）功能，例如缓存、HTTP多路复用和日志记录。

DSR对TCP协议的适用范围有限，而且无论如何，NGINX Plus的反向代理架构都无法应用于DSR/TCP。

UDP协议要简单得多，不具备TCP的任何连接语义。可以配置NGINX Plus，使其支持DNS等UDP协议的DSR，从而提升性能。具体而言，采用DSR后，NGINX Plus无需为等待响应数据包而保持UDP套接字打开（可提高可扩展性），并且响应数据包可以完全绕过NGINX Plus的第7层处理（可降低延迟）。

DSR配置与IP透明有何不同？

对于UDP流量，IP透明配置与DSR配置有三点不同：

• NGINX Plus向上游服务器发送数据报时，必须同时伪装远程客户端的IP地址和端口（proxy_bind端口配置）。
• 不得将NGINX Plus配置为等待来自上游服务器的响应数据报（使用proxy_responses 0指令）。
• 还需要执行一个额外步骤，重写返回数据报的源地址，使其与负载均衡器的公共地址匹配。

此外，必须将NGINX Plus配置为对上游服务器执行主动健康检查。NGINX Plus无法依靠常规的被动检查来验证服务器是否健康，因为NGINX Plus无法观察到服务器发送的响应数据包。

创建标准UDP反向代理服务

为演示DSR，首先创建一个由4台DNS服务器组成的负载均衡集群。当查询名称www.example.com时，这些服务器会返回不同的IP地址。

配置一个在各DNS服务器之间进行负载均衡的简单反向代理配置：

# in the 'stream' context
server {
    listen 53 udp;

    proxy_responses 1;
    proxy_timeout 1s;
    proxy_pass dns_upstreams;
}

upstream dns_upstreams {
    server 172.16.0.11:53;
    server 172.16.0.12:53;
    server 172.16.0.13:53;
    server 172.16.0.14:53;
}

The proxy_responses和proxy_timeout指令可实现基本的运行状况检查。如果上游服务器未在1秒内发送1个响应，NGINX Plus会认为该服务器已发生故障，并重试DNS请求。

配置每台DNS服务器，使其在收到对www.example.com的查询时返回自身的IP地址：

$TTL   	604800
@           IN          SOA         ns1.example.com. admin.example.com. (
                              2           ; Serial
                         604800           ; Refresh
                          86400           ; Retry
                        2419200           ; Expire
                         604800 )         ; Negative Cache TTL

example.com.    IN      NS      ns1.example.com.

ns1             IN      A       172.16.0.11
www             IN      A       172.16.0.11

测试结果清楚地表明，NGINX Plus正在将请求负载均衡到各DNS服务器：

$ for i in {1..4} ; do dig +short @192.168.99.10 www.example.com ; done
172.16.0.11
172.16.0.12
172.16.0.13
172.16.0.14

为DSR配置NGINX Plus和UDP上游

NGINX Plus R10及更高版本（以及NGINX Open Source 1.11.2及更高版本）可以同时伪装上游流量的源地址和源端口。请在transparent参数中添加到proxy_bind指令：

proxy_bind $remote_addr:$remote_port transparent;

这样，上游服务器便可获取完整的源IP地址，从而构造直接发送到远程客户端的响应数据报。

上游服务器生成的响应（“出站”）数据包具有正确的目标IP地址，但使用其本地IP地址作为源地址。需要将源地址重写为客户端最初连接的NGINX Plus负载均衡器的IP地址和端口。

可采用以下两种方法：

1. 路由器NAT：在中间路由器（例如NGINX Plus代理）上重写出站数据包
2. 源 NAT：在出站数据包离开各上游 DNS 服务器时对其进行重写

这两种方法都使用通过tc 命令配置的无状态NAT功能。如果上游服务器直接连接到互联网（即在此拓扑中，返回数据包不会经过您可以控制的中间路由器），则必须选择源NAT方法。

为DSR配置NGINX Plus

响应数据包不会传送到NGINX Plus，因此需要禁用在创建标准UDP反向代理服务中配置的健康检查：修改proxy_responses指令并禁用proxy_timeout指令。这样，NGINX Plus便不会等待响应，也不会因未收到响应而判定上游服务器出现故障。禁用此检查还可让NGINX Plus立即重用套接字资源。

此外，在$remote_addr指令的第一个参数中同时包含$remote_port和proxy_bind变量，以便NGINX Plus在发送到上游服务器的数据报中保留原始源地址和源端口：

# in the 'stream' context
server {
    listen 53 udp;

    proxy_bind $remote_addr:$remote_port transparent;
    proxy_responses 0;
    #proxy_timeout 1s;
}

路由器NAT：在中间路由器上重写出站数据包

可以在单个中间路由器上重写出站数据包。例如，如果上游服务器位于NGINX Plus负载均衡器后面的专用网络中，可以将该负载均衡器用作默认路由，并在转发数据包时对其进行重写。

1. 将每台上游服务器配置为通过NGINX Plus服务器路由所有出站流量：

# route add default gw nginx-ip-address

1. 配置NGINX Plus服务器以转发IP流量：

# sysctl -w net.ipv4.ip_forward=1

1. 配置NGINX Plus服务器以执行无状态NAT重写：

# tc qdisc add dev eth0 root handle 10: htb
# tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.11 match ip sport 53 action nat egress 172.16.0.11 192.168.99.10
# tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.12 match ip sport 53 action nat egress 172.16.0.12 192.168.99.10
# tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.13 match ip sport 53 action nat egress 172.16.0.13 192.168.99.10
# tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.14 match ip sport 53 action nat egress 172.16.0.14 192.168.99.10

1. 请确保为每台上游服务器选择适当的出口接口和IP地址。

有关无状态NAT的更多信息，请参阅tc nat手册页。根据具体配置，可以通过对tc filter命令的src和egress old参数使用CIDR掩码，将多条命令合并为一条。

要显示当前的tc filter配置，请运行以下命令：

# tc filter show dev eth0

源NAT：在每台上游服务器上重写出站数据包

如果可以配置上游服务器的网络，尤其是这些服务器直接连接到互联网时，可以使用以下配置。必须在每台上游服务器上应用此配置。

将每台上游服务器配置为执行无状态NAT重写：

# tc qdisc add dev eth0 root handle 10: htb
# tc filter add dev eth0 parent 10: protocol ip prio 10 u32 match ip src 172.16.0.11 match ip sport 53 action nat egress 172.16.0.11 192.168.99.10

请确保在每个上游设备上选择适当的接口和IP地址。

测试DSR配置

要测试该配置，请向NGINX Plus负载均衡器发送DNS请求，并验证这些请求是否在各上游服务器之间实现负载均衡。

DSR没有直接可见的效果。如果已使用proxy_responses 0指令将NGINX Plus配置为不等待响应数据包，而DNS客户端仍能收到负载均衡后的响应，则可以确认DSR正在正常工作。还可以使用tcpdump进一步观察数据包流，具体方法请参阅下文的“故障排除”。

总结：DSR配置如何工作？

• NGINX Plus从远程客户端（192.168.99.1:端口）接收UDP数据报。
• NGINX Plus执行负载均衡决策，选择一台上游服务器（例如172.16.0.11）写入数据报内容。在NGINX Plus建立连接之前，会将上游套接字的本地端绑定到远程客户端的IP地址和端口。
• 上游服务器接收NGINX Plus发送的数据报。该数据报看起来直接来自远程客户端的地址和端口。
• 上游服务器作出响应，将数据报发回远程客户端。上游服务器将响应数据报的源IP地址和端口设置为自身的本地IP地址和端口。
• 源IP地址（必要时还包括端口）由上游服务器（源NAT配置）或中间路由器（路由器NAT配置）重写。
• 远程客户端接收具有正确四元组（源和目标IP地址及端口）的数据报。
• NGINX Plus不会等待接收任何响应数据报，并会立即关闭上游套接字。

最终，响应数据包会绕过NGINX Plus中的第7层处理，直接发送到远程客户端。

故障排除

如果IP Transparency或DSR未按预期工作，请参考以下建议排查可能的原因：

以root 身份运行

确认NGINX Plus工作进程已配置为以root身份运行。否则，当NGINX Plus尝试将套接字绑定到非本地地址时，错误日志中会出现类似以下内容的错误消息：

setsockopt(IP_TRANSPARENT) failed (1: Operation not permitted) while connecting to upstream, client: 192.168.99.1, server: , request: "GET / HTTP/1.1", upstream: "http://172.16.0.11:80/", host: "192.168.99.10"

使用ping 测试

验证是否可以从NGINX Plus代理ping客户端和服务器。除非先创建必要的路由配置，并将NGINX Plus中间代理配置为转发数据包，否则上游服务器无法ping远程客户端IP地址。

IP地址范围不得重叠

确保远程客户端使用的IP子网未直接连接到上游服务器。否则，可能会出现以下两个问题：

• Linux的“反向路径过滤”保护机制可能会静默拒绝来自NGINX Plus的数据包，因为源IP地址关联的子网位于另一个接口上。
• 返回数据包不使用默认路由，而是直接发送到本地连接的远程客户端。

随处使用tcpdump Everywhere

在逐步完成配置并测试每个中间步骤时，请在每台服务器上持续运行tcpdump，以验证每个阶段的数据包是否发送至正确的端点并从正确的端点接收：

$ sudo tcpdump -i any -n tcp port 80

使用下列检查项调查任何异常行为。

检查路由表

仔细检查每台服务器上的路由表，尤其要注意上游服务器：

# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.0.1      0.0.0.0         UG    0      0        0 eth2
10.0.2.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0
172.16.0.0      0.0.0.0         255.255.255.0   U     0      0        0 eth2
192.168.56.0    0.0.0.0         255.255.255.0   U     0      0        0 eth1

是否存在意外路由？能否确认流中的所有数据包都将路由到正确的目的地？请注意，在iptables和路由器NAT配置中，所有出站数据包都必须通过中间的NGINX Plus代理进行路由。

数据包丢失

如果数据包意外丢失（tcpdump显示数据包已由一台计算机发送，但另一台计算机未收到），反向路径过滤可能是一个不易察觉的原因。要暂时禁用反向路径过滤，请运行以下命令：

# for f in /proc/sys/net/ipv4/conf/*/rp_filter; do echo 0 > $f ; done

允许上游服务器访问外部服务器

如果上游服务器位于专用网络中，并使用NGINX Plus（或其他服务器）作为默认网关，您可能需要配置该网关，以便上游服务器访问外部（Internet）主机。

需要启用“IP 转发”，以便网关转发来自上游服务器的数据包。IP 转发通常默认处于禁用状态。如果这些服务器没有可路由的 IP 地址（例如使用 172.16.0.0/24 等私有地址），还需要在网关服务器的外部接口上配置“IP 伪装”：

# sysctl -w net.ipv4.ip_forward=1
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

验证是否可以从内部上游服务器ping外部服务器：

root@dev1:~# ping 8.8.8.8
PING 8.8.8.8 (8.8.8.8) 56(84) bytes of data.
64 bytes from 8.8.8.8: icmp_seq=1 ttl=61 time=6.72 ms
64 bytes from 8.8.8.8: icmp_seq=2 ttl=61 time=5.49 ms
^C

要显示当前的转发、路由和iptables nat配置，请运行以下3条命令：

# sysctl net.ipv4.ip_forward
# route -n
# iptables -t nat -L

获取 NGINX 帮助

IP透明或直接服务器返回的配置较为复杂，其他中间网络设备可能会丢弃或以其他方式重写数据包，从而影响部署。如果需要帮助，NGINX的专业服务团队可随时提供支持。

亲自体验NGINX Plus的IP透明和DSR功能，立即开始30天免费试用，或联系我们，讨论您的用例。

关于作者

Owen Garrett产品管理高级总监

Owen Garrett 的更多博客文章