文档
一个 项目

reverse_proxy

将请求代理到一个或多个后端，支持可配置的传输方式、负载均衡、健康检查、请求操作和缓冲选项。

语法

reverse_proxy [<matcher>] [<upstreams...>] {
	# 后端
	to      <upstreams...>
	dynamic <module> ...

	# 负载均衡
	lb_policy       <name> [<options...>]
	lb_retries      <retries>
	lb_try_duration <duration>
	lb_try_interval <interval>
	lb_retry_match  <request-matcher>

	# 主动健康检查
	health_uri          <uri>
	health_upstream     <ip:port>
	health_port         <port>
	health_interval     <interval>
	health_passes       <num>
	health_fails	    <num>
	health_timeout      <duration>
	health_method       <method>
	health_status       <status>
	health_request_body <body>
	health_body         <regexp>
	health_follow_redirects
	health_headers {
		<field> [<values...>]
	}

	# 被动健康检查
	fail_duration     <duration>
	max_fails         <num>
	unhealthy_status  <status>
	unhealthy_latency <duration>
	unhealthy_request_count <num>

	# 流式传输
	flush_interval     <duration>
	request_buffers    <size>
	response_buffers   <size>
	stream_timeout     <duration>
	stream_close_delay <duration>

	# 请求/头部操作
	trusted_proxies [private_ranges] <ranges...>
	header_up   [+|-]<field> [<value|regexp> [<replacement>]]
	header_down [+|-]<field> [<value|regexp> [<replacement>]]
	method <method>
	rewrite <to>

	# 往返
	transport <name> {
		...
	}

	# 可选拦截来自上游的响应
	@name {
		status <code...>
		header <field> [<value>]
	}
	replace_status [<matcher>] <status_code>
	handle_response [<matcher>] {
		<directives...>

		# 仅在 handle_response 可用的特殊指令
		copy_response [<matcher>] [<status>] {
			status <status>
		}
		copy_response_headers [<matcher>] {
			include <fields...>
			exclude <fields...>
		}
	}
}

上游

  • <upstreams...> 是要代理到的上游（后端）列表。
  • to 是指定上游列表的另一种方式，每行一个或多个。
  • dynamic 配置 动态上游 模块。这样可以为每个请求动态获取上游列表。见下文 动态上游。动态上游会在每次代理循环迭代时获取（即如果启用了负载均衡重试，则每个请求可能多次），并优先于静态上游。如果发生错误，将回退到静态配置的上游。

上游地址

静态上游地址可以采用仅包含 scheme 和主机/端口的 URL，或传统的 Caddy 网络地址。有效示例：

  • localhost:4000
  • 127.0.0.1:4000
  • [::1]:4000
  • http://localhost:4000
  • https://example.com
  • h2c://127.0.0.1
  • example.com
  • unix//var/php.sock
  • unix+h2c//var/grpc.sock
  • localhost:8001-8006
  • [fe80::ea9f:80ff:fe46:cbfd%eth0]:443

默认情况下，将通过明文 HTTP 连接到上游。使用 URL 形式时，可以通过 scheme 设置一些 transport 默认值作为简写。

  • 使用 https:// 作为 scheme 时，将使用 http 传输 并启用 tls。

    此外，您可能需要重写 Host 头，使其与 TLS SNI 值匹配，服务器会用它进行路由和证书选择。详见下文 HTTPS。

  • 使用 h2c:// 作为 scheme 时，将使用 http 传输 并允许明文 HTTP/2 连接。

  • 使用 http:// 作为 scheme 与省略 scheme 相同，因为 HTTP 已是默认值。此语法仅为与其他 scheme 对称。

scheme 不能混用，因为它们会修改通用传输配置（启用 TLS 的传输不能同时承载 HTTPS 和明文 HTTP）。任何显式的传输配置都不会被覆盖，省略 scheme 或使用其他端口不会假定特定传输。

使用带 zone 的 IPv6（如带特定网络接口的链路本地地址）时，不能用 scheme 简写，因为 % 会导致 URL 解析错误；此时请显式配置传输。

使用 网络地址 形式时，网络类型作为前缀。不能与 URL scheme 混用。特殊情况，unix+h2c/ 支持作为 unix/ 网络加上 h2c:// scheme 的简写。端口范围支持简写，会展开为多个相同主机的上游。

上游地址不能包含路径或查询字符串，否则意味着代理时同时重写请求，这种行为未定义也不支持。如需此功能，请使用 rewrite 指令。

如果地址不是 URL（即无 scheme），则可使用 占位符，但这会使上游变为“动态静态”，即许多不同后端在健康检查和负载均衡上视为单一静态上游。建议优先使用 动态上游 模块。使用占位符时，必须包含端口（无论是占位符替换还是静态后缀）。

动态上游

Caddy 的反向代理内置了一些动态上游模块。注意，使用动态上游对负载均衡和健康检查有影响，具体取决于策略配置：主动健康检查不会对动态上游运行；如果上游列表相对稳定一致（尤其是轮询），负载均衡和被动健康检查效果最佳。理想情况下，动态上游模块只返回健康、可用的后端。

SRV

从 SRV DNS 记录获取上游。

	dynamic srv [<full_name>] {
		service   <service>
		proto     <proto>
		name      <name>
		refresh   <interval>
		resolvers <ip...>
		dial_timeout        <duration>
		dial_fallback_delay <duration>
	}
  • <full_name> 要查询的完整域名（即 _service._proto.name）。
  • service 服务组件。
  • proto 协议组件，tcp 或 udp。
  • name 名称组件，或当 service 和 proto 为空时要查询的完整域名。
  • refresh 刷新缓存结果的频率，默认 1m。
  • resolvers 覆盖系统解析器的 DNS 解析器列表。
  • dial_timeout 查询拨号超时时间。
  • dial_fallback_delay RFC 6555 快速回退连接的等待时间，默认 300ms。

A/AAAA

从 A/AAAA DNS 记录获取上游。

	dynamic a [<name> <port>] {
		name      <name>
		port      <port>
		refresh   <interval>
		resolvers <ip...>
		dial_timeout        <duration>
		dial_fallback_delay <duration>
		versions ipv4|ipv6
	}
  • name 要查询的域名。
  • port 后端端口。
  • refresh 刷新缓存结果的频率，默认 1m。
  • resolvers 覆盖系统解析器的 DNS 解析器列表。
  • dial_timeout 查询拨号超时时间。
  • dial_fallback_delay RFC 6555 快速回退连接的等待时间，默认 300ms。
  • versions 要解析的 IP 版本列表，默认 ipv4 ipv6，分别对应 A 和 AAAA 记录。

Multi

追加多个动态上游模块的结果。适用于需要冗余上游来源的场景，例如主集群 SRV 备份为次集群 SRV。

	dynamic multi {
		<source> [...]
	}
  • <source> 动态上游模块名称及其配置，可指定多个。

负载均衡

负载均衡通常用于在多个上游间分流流量。启用重试后，也可用于一个或多个上游，在找到健康上游前保持请求（如重启或重新部署上游时缓解错误）。

默认启用，策略为 random。重试默认关闭。

  • lb_policy 负载均衡策略名称及选项，默认 random。

    对于涉及哈希的策略，使用 最高随机权重（HRW） 算法，确保同一哈希键的客户端或请求在上游列表变化时仍映射到同一上游。

    某些策略支持 fallback 选项（如有说明），可用 块 配置 fallback <policy>，指定备用策略。默认 fallback 为 random。配置 fallback 可在主策略未选中时使用次策略，支持多层嵌套。

    例如，header 可作为主策略，允许开发者选择特定上游，fallback 为 first 实现主/备故障转移。

    lb_policy header X-Upstream {
	fallback first
}

    • random 随机选择上游

    • random_choose <n> 随机选择 n 个上游，再选负载最小的（n 通常为 2）

    • first 选择配置顺序中的第一个可用上游，实现主/备故障转移；需配合健康检查，否则不会故障转移

    • round_robin 轮询每个上游

    • weighted_round_robin <weights...> 按权重轮询上游，权重数与上游数一致，权重为非负整数。权重为 0 时，该上游不会被选中。

    • least_conn 选择当前请求数最少的上游，若有多个则随机选一个

    • ip_hash 按远程 IP（直接对端）映射到固定上游

    • client_ip_hash 按客户端 IP 映射到固定上游，建议配合 servers > trusted_proxies 全局选项 否则行为同 ip_hash

    • uri_hash 按请求 URI（路径和查询）映射到固定上游

    • query [key] 按请求查询参数哈希映射到固定上游，若无该 key 则用 fallback 策略（默认 random）

    • header [field] 按请求头哈希映射到固定上游，若无该头则用 fallback 策略（默认 random）

    • cookie [<name> [<secret>]] 首次请求（无 cookie）时用 fallback 策略（默认 random）选上游，并在响应中添加 Set-Cookie（默认名为 lb）。cookie 值为选中上游地址与 secret 的 HMAC-SHA256。

      后续请求带 cookie 时，若上游可用则映射到同一上游，否则用 fallback 策略重新选择并设置 cookie。

      如需调试，可用 PHP 计算 cookie 值（如上游为 10.1.0.10:8080，secret 为 secret）：

      echo hash_hmac('sha256', '10.1.0.10:8080', 'secret');
// cdd96966817dd14a99f47ee17451464f29998da170814a16b483e4c1ff4c48cf

      浏览器控制台设置 cookie：

      document.cookie = "lb=cdd96966817dd14a99f47ee17451464f29998da170814a16b483e4c1ff4c48cf";

  • lb_retries 每个请求重试选择可用后端的次数，若下一个主机不可用。默认关闭（0）。

    若同时配置了 lb_try_duration，则重试可能提前终止（以持续时间为准）。

  • lb_try_duration 持续时间值，定义每个请求重试选择可用后端的最长时间。默认关闭（0）。

    客户端会等待至多该时间，负载均衡器尝试找到可用上游。合理起点为 5s，因 HTTP 传输默认拨号超时为 3s，可保证至少一次重试。

  • lb_try_interval 持续时间值，定义选择下一个主机前的等待时间。默认 250ms。仅在上游请求失败时相关。设为 0 且 lb_try_duration 非零时，若所有后端都挂掉且延迟极低，可能导致 CPU 占用过高。

  • lb_retry_match 限制哪些请求允许重试。若连接上游成功但后续往返失败，只有匹配此条件的请求才会重试。若连接失败，总是允许重试。默认仅重试 GET 请求。

    语法同 命名请求匹配器，但不带 @name。单个匹配器可同行配置，多个需用块。

主动健康检查

主动健康检查会定时在后台进行。需配置 health_uri 或 health_port。

  • health_uri 主动健康检查的 URI 路径（可带查询）。

  • health_upstream 主动健康检查用的 ip:port，若与上游不同。建议配合 health_header 和 {http.reverse_proxy.active.target_upstream} 使用。

  • health_port 主动健康检查用端口，若与上游端口不同。若用 health_upstream 则忽略。

  • health_interval 持续时间值，定义主动健康检查频率。默认 30s。

  • health_passes 连续健康检查通过次数，才标记为健康。默认 1。

  • health_fails 连续健康检查失败次数，才标记为不健康。默认 1。

  • health_timeout 持续时间值，等待回复的最长时间，超时则标记为不可用。默认 5s。

  • health_method 主动健康检查的 HTTP 方法。默认 GET。

  • health_status 健康后端应返回的 HTTP 状态码，可为 3 位码或 xx 结尾的状态类，如 200（默认）或 2xx。

  • health_request_body 主动健康检查请求体字符串。

  • health_body 主动健康检查响应体需匹配的子串或正则。不匹配则标记为不可用。

  • health_follow_redirects 允许健康检查跟随上游重定向。默认重定向视为失败。

  • health_headers 指定主动健康检查请求头。适用于需更改 Host 或认证等场景。

被动健康检查

被动健康检查在实际代理请求时进行。需配置 fail_duration。

  • fail_duration 持续时间值，定义失败请求的记忆时长。大于 0 启用被动健康检查，默认 0（关闭）。合理起点为 30s，平衡错误率与恢复速度。

  • max_fails 在 fail_duration 内最大失败次数，超过则视为不可用，必须 >= 1，默认 1。

  • unhealthy_status 若响应为这些状态码，则计为失败。可为 3 位码或 xx 结尾的状态类，如 404 或 5xx。

  • unhealthy_latency 持续时间值，若请求耗时超过则计为失败。

  • unhealthy_request_count 单个后端允许的最大并发请求数，超过则视为“过载”，优先选择其他后端。

    该值应较大；配置后，代理最大并发为 unhealthy_request_count × 上游数，超出则因无可用上游而报错。

事件

当上游从健康变为不健康或反之时，会 触发事件。可用于通知、日志等。事件如下：

  • healthy：上游从不健康变为健康时触发
  • unhealthy：上游从健康变为不健康时触发

两种情况下，事件元数据中包含 host，可用 {event.data.host} 占位符在 exec 事件处理器中引用。

流式传输

默认情况下，代理会部分缓冲响应以提高传输效率。

代理也支持 WebSocket 连接，会执行 HTTP 升级请求，然后转为双向隧道。

  • flush_interval 持续时间值，调整 Caddy 向客户端刷新响应缓冲区的频率。默认不定期刷新。负值（如 -1）表示“低延迟模式”，完全禁用缓冲，每次写入后立即刷新，即使客户端提前断开也不会取消对后端的请求。若响应满足以下任一条件，则忽略此选项并立即刷新：

    • Content-Type: text/event-stream
    • 未知 Content-Length
    • 代理两端均为 HTTP/2，未知 Content-Length，且 Accept-Encoding 未设置或为 "identity"

  • request_buffers 代理在发送到上游前，最多从请求体读取 <size> 字节到缓冲区。非常低效，仅当上游要求无延迟读取请求体时使用（建议上游应用修复）。支持 go-humanize 所有格式。

  • response_buffers 代理在返回给客户端前，最多从响应体读取 <size> 字节到缓冲区。性能原因应尽量避免，但若后端内存受限可用。支持 go-humanize 所有格式。

  • stream_timeout 持续时间值，流式请求（如 WebSocket）超时后强制关闭。适用于限制连接存活时间。合理起点如 24h，默认无限制。

  • stream_close_delay 持续时间值，配置卸载时延迟关闭流式请求（如 WebSocket），允许连接在延迟结束前保持。可避免配置重载时大量客户端重连。合理起点如 5m，默认无延迟。

头部

代理可操作头部：

  • header_up 设置、添加（+ 前缀）、删除（- 前缀）或替换（两个参数，查找与替换）发往上游的请求头。

  • header_down 设置、添加（+ 前缀）、删除（- 前缀）或替换（两个参数，查找与替换）来自上游的响应头。

例如，设置请求头，覆盖原值：

header_up Some-Header "the value"

添加响应头（同名头可有多个值）：

header_down +Some-Header "first value"
header_down +Some-Header "second value"

删除请求头，防止其到达上游：

header_up -Some-Header

后缀匹配删除所有请求头：

header_up -Some-*

删除所有请求头，仅保留手动添加的（不推荐）：

header_up -*

对请求头进行正则替换：

header_up Some-Header "^prefix-([A-Za-z0-9]*)$" "replaced-$1-suffix"

正则语法为 Go 内置 RE2。见 RE2 语法参考 和 Go regexp 语法概览。替换字符串支持捕获组，如 $1 表示第一个分组。

默认行为

默认情况下，Caddy 会将入站头部（包括 Host）原样传递给后端，例外有三：

对于这些 X-Forwarded-* 头，默认代理会忽略入站请求中的值，以防止伪造。

若 Caddy 不是客户端的首个服务器（如前有 CDN），可用 trusted_proxies 配置受信任 IP 段（CIDR），信任这些来源的头部。

强烈建议通过 servers > trusted_proxies 全局选项 配置，这样可作用于所有代理处理器，并启用客户端 IP 解析。

此外，使用 http 传输 时，若请求缺少 Accept-Encoding: gzip，会自动添加，允许上游返回压缩内容。可通过传输配置 compression off 关闭。

HTTPS

由于大多数头部在代理时保持原值，代理到 HTTPS 时通常需将 Host 头重写为上游地址，使其与 TLS ServerName 匹配：

reverse_proxy https://example.com {
	header_up Host {upstream_hostport}
}

X-Forwarded-Host 头仍会 默认 传递，因此上游可用其获取原始 Host 值。

重写

默认情况下，Caddy 以与入站请求相同的方法和 URI 向上游发起请求，除非在到达 reverse_proxy 前已被中间件链重写。

代理前会克隆请求，确保处理期间的修改不会影响其他处理器。适用于需要在代理后继续处理的场景。

除 头部操作 外，还可在发送到上游前更改请求方法和 URI：

  • method 更改克隆请求的 HTTP 方法。若改为 GET 或 HEAD，则不会将请求体发送到上游。适用于允许其他处理器消费请求体的场景。
  • rewrite 更改克隆请求的 URI（路径和查询）。类似于 rewrite 指令，但仅在本处理器作用域内生效。

这些重写常用于“预检请求”模式，如将请求发送到认证网关判断用户是否已认证（如有 session cookie），决定是否继续或重定向到登录页。Caddy 提供了快捷指令 forward_auth 简化配置。

传输方式

Caddy 的代理传输方式可插拔：

  • transport 定义与后端通信方式，默认 http。

http 传输

transport http {
	read_buffer             <size>
	write_buffer            <size>
	max_response_header     <size>
	proxy_protocol          v1|v2
	dial_timeout            <duration>
	dial_fallback_delay     <duration>
	response_header_timeout <duration>
	expect_continue_timeout <duration>
	resolvers <ip...>
	tls
	tls_client_auth <automate_name> | <cert_file> <key_file>
	tls_insecure_skip_verify
	tls_curves <curves...>
	tls_timeout <duration>
	tls_trust_pool <module>
	tls_server_name <server_name>
	tls_renegotiation <level>
	tls_except_ports <ports...>
	keepalive [off|<duration>]
	keepalive_interval <interval>
	keepalive_idle_conns <max_count>
	keepalive_idle_conns_per_host <count>
	versions <versions...>
	compression off
	max_conns_per_host <count>
	forward_proxy_url <url>
}

  • read_buffer 读缓冲区大小，支持 go-humanize 格式，默认 4KiB。

  • write_buffer 写缓冲区大小，默认 4KiB。

  • max_response_header 响应头最大字节数，默认 10MiB。

  • proxy_protocol 启用 PROXY 协议（如 HAProxy），在连接上游时添加真实客户端 IP。建议配合 servers > trusted_proxies 全局选项。支持 v1/v2，仅当上游支持解析时使用。默认关闭。

  • dial_timeout 连接上游 socket 的最大 持续时间，默认 3s。

  • dial_fallback_delay RFC 6555 快速回退连接的最大等待时间，负值禁用，默认 300ms。

  • response_header_timeout 读取上游响应头的最大 持续时间，默认无限制。

  • expect_continue_timeout 若请求带 Expect: 100-continue，写完请求头后等待上游首个响应头的最大 持续时间，默认无限制。

  • read_timeout 读取后端的最大 持续时间，默认无限制。

  • write_timeout 向后端写入的最大 持续时间，默认无限制。

  • resolvers DNS 解析器列表，覆盖系统解析器。

  • tls 与后端使用 HTTPS。若上游为 https:// 或端口 :443，或配置了下方任一 tls_* 选项时自动启用。

  • tls_client_auth 启用 TLS 客户端认证，可指定自动获取证书的域名，或指定证书和密钥文件。

  • tls_insecure_skip_verify 关闭 TLS 握手验证，极不安全，易受中间人攻击。生产环境禁用。

  • tls_curves 支持的椭圆曲线列表。Caddy 默认已足够安全，仅特殊需求时配置。

  • tls_timeout TLS 握手最大 持续时间，默认无限制。

  • tls_trust_pool 配置受信任证书颁发机构，类似 tls 指令文档 的 trust_pool 子指令。标准 Caddy 安装可用的信任池见 此处。

  • tls_server_name 设置 TLS 握手时用于验证证书的服务器名，默认用上游地址主机部分。

    仅当上游地址与证书不符（如为 IP）时需重写。可用请求占位符，此时每次请求会克隆 HTTP 传输配置，可能影响性能。

  • tls_renegotiation 设置 TLS 重协商级别。TLS 重协商即首次握手后再次握手。可选：

    • never（默认）禁用重协商。
    • once 允许远程服务器每连接请求一次重协商。
    • freely 允许远程服务器多次请求重协商。

  • tls_except_ports 启用 TLS 时，若上游端口为指定端口，则禁用 TLS。适用于动态上游部分为 HTTP、部分为 HTTPS 的场景。

  • keepalive 取值为 off 或 持续时间值，指定连接保持时间，默认 2m。

  • keepalive_interval 活跃性探测间隔 持续时间，默认 30s。

  • keepalive_idle_conns 最大保持连接数，默认无限制。

  • keepalive_idle_conns_per_host 每主机最大保持连接数，默认 32。

  • versions 自定义支持的 HTTP 版本。

    可选：1.1、2、h2c、3。

    默认：1.1 2，若 上游 scheme 为 h2c://，则默认 h2c 2。

    h2c 启用明文 HTTP/2 连接。为非标准特性，不能与其他特性共用。

    3 启用 HTTP/3，⚠️ 实验性特性，可能变动。

  • compression 设为 off 可禁用与后端的压缩。

  • max_conns_per_host 限制每主机最大连接数（拨号、活跃、空闲），默认无限制。

  • forward_proxy_url 指定 HTTP 传输代理请求到上游服务器的代理服务器 URL。默认遵循 Go 标准库 的环境变量（如 HTTP_PROXY）。配置后，请求流向为：

    • 客户端 🡒 reverse_proxy 🡒 forward_proxy_url 🡒 上游

fastcgi 传输

transport fastcgi {
	root  <path>
	split <at>
	env   <key> <value>
	resolve_root_symlink
	dial_timeout  <duration>
	read_timeout  <duration>
	write_timeout <duration>
	capture_stderr
}

  • root 站点根目录，默认 {http.vars.root} 或当前工作目录。

  • split 路径分割点，用于获取 URI 末尾的 PATH_INFO。

  • env 设置额外环境变量，可多次指定。

  • resolve_root_symlink 启用后会解析 root 目录的符号链接。

  • dial_timeout 连接上游 socket 的超时时间，支持 持续时间值，默认 3s。

  • read_timeout 读取 FastCGI 服务器的超时时间，默认无限制。

  • write_timeout 发送到 FastCGI 服务器的超时时间，默认无限制。

  • capture_stderr 启用后会捕获并记录上游 fastcgi 服务器的 stderr 消息。默认以 WARN 级别记录，若响应为 4xx 或 5xx，则为 ERROR。默认忽略 stderr。

拦截响应

反向代理可配置拦截来自后端的响应。为此可定义 响应匹配器（语法类似请求匹配器），第一个匹配的 handle_response 路由会被调用。

响应处理器被调用时，后端响应不会直接写给客户端，而是执行 handle_response 路由，由该路由负责写响应。若未写响应，则继续执行本 reverse_proxy 之后的处理器。

  • @name 响应匹配器名称。只要每个响应匹配器名称唯一，可定义多个。可按状态码、响应头等匹配响应。

  • replace_status 匹配时简单更改响应状态码。

  • handle_response 匹配时定义要执行的路由（如省略匹配器则匹配所有响应）。第一个匹配块会被应用。handle_response 内可用任意 指令。

此外，handle_response 内可用两个特殊处理器指令：

  • copy_response 将后端响应体复制回客户端，可选更改状态码。该指令 排序在 respond 之前。

  • copy_response_headers 将后端响应头复制回客户端，可选包含或排除某些头（不可同时指定 include 和 exclude）。该指令 排序在 header 之后。

handle_response 路由内可用三个占位符：

  • {rp.status_code} 后端响应的状态码

  • {rp.status_text} 后端响应的状态文本

  • {rp.header.*} 后端响应头

示例

将所有请求反向代理到本地后端：

example.com {
	reverse_proxy localhost:9005
}

负载均衡所有请求到 3 个后端：

example.com {
	reverse_proxy node1:80 node2:80 node3:80
}

仅 /api 路径请求，且通过 cookie 策略实现粘性会话：

example.com {
	reverse_proxy /api/* node1:80 node2:80 node3:80 {
		lb_policy cookie api_sticky
	}
}

使用 主动健康检查 判断后端健康，并在连接失败时启用 重试，直到找到健康后端：

example.com {
	reverse_proxy node1:80 node2:80 node3:80 {
		health_uri /healthz
		lb_try_duration 5s
	}
}

配置部分 传输选项：

example.com {
	reverse_proxy localhost:8080 {
		transport http {
			dial_timeout 2s
			response_header_timeout 30s
		}
	}
}

反向代理到 HTTPS 上游：

example.com {
	reverse_proxy https://example.com {
		header_up Host {upstream_hostport}
	}
}

反向代理到 HTTPS 上游，但⚠️ 禁用 TLS 验证。极不推荐，因会禁用所有 HTTPS 安全检查；如可行，建议在私有网络用 HTTP，避免虚假的安全感：

example.com {
	reverse_proxy 10.0.0.1:443 {
		transport http {
			tls_insecure_skip_verify
		}
	}
}

也可通过 信任上游证书 建立信任，并（可选）设置 TLS-SNI 匹配证书主机名：

example.com {
	reverse_proxy 10.0.0.1:443 {
		transport http {
			tls_trust_pool file /path/to/cert.pem
			tls_server_name app.example.com
		}
	}
}

去除路径前缀 后再代理；注意 子目录问题 ：

example.com {
	handle_path /prefix/* {
		reverse_proxy localhost:9000
	}
}

代理前替换路径前缀，使用 rewrite：

example.com {
	handle_path /old-prefix/* {
		rewrite * /new-prefix{path}
		reverse_proxy localhost:9000
	}
}

X-Accel-Redirect 支持，即按请求拦截响应 实现静态文件服务：

example.com {
	reverse_proxy localhost:8080 {
		@accel header X-Accel-Redirect *
		handle_response @accel {
			root    * /path/to/private/files
			rewrite * {rp.header.X-Accel-Redirect}
			method  * GET
			file_server
		}
	}
}

为上游错误响应自定义错误页，通过 按状态码拦截响应：

example.com {
	reverse_proxy localhost:8080 {
		@error status 500 503
		handle_response @error {
			root    * /path/to/error/pages
			rewrite * /{rp.status_code}.html
			file_server
		}
	}
}

动态获取后端，通过 A/AAAA 记录 DNS 查询：

example.com {
	reverse_proxy {
		dynamic a example.com 9000
	}
}

动态获取后端，通过 SRV 记录 DNS 查询：

example.com {
	reverse_proxy {
		dynamic srv _api._tcp.example.com
	}
}

结合 主动健康检查 和 health_upstream，可用于中间服务做更复杂健康检查。此时可用 {http.reverse_proxy.active.target_upstream} 作为头部传递原始上游：

example.com {
	reverse_proxy node1:80 node2:80 node3:80 {
		health_uri /health
		health_upstream 127.0.0.1:53336
		health_headers {
			Full-Upstream {http.reverse_proxy.active.target_upstream}
		}
	}
}