Reverse proxies let you delegate content under certain path prefixes to external services (e.g., Wordpress)
Similar to landing pages and redirects, reverse proxies also embed the concept of Referrals .
If the content you are proxying to generates a sitemap (e.g., Wordpress makes a sitemap index available at /sitemap.xml), you should add the full proxied sitemap URL to the application's Sitemaps.
Landing page / redirect path collision
If an enabled reverse proxy shares a path prefix with a landing page or redirect, the reverse proxy will have precedence
Attributes:
| Name | Type | Description |
|---|---|---|
| path_prefix | uri | The path prefix to proxy all traffic. Must be unique for the application. If you have nested reverse proxies sharing a common path prefix, the most specific enabled path prefix will be used first. So if you have a path prefix at /reverse/ and another defined at /reverse/proxy, requests to /reverse/proxy/a will be routed to the second. |
| proxy_host | uri | The fully qualified host to proxy traffic. Should include the protocol (e.g., https://example.com not example.com). |
| proxy_prefix | uri | The prefix in the proxy host that should replace the path_prefix. If not set, the full path_prefix will be sent as the path request. Should start with a leading /. |
| enabled | boolean | If this redirect is currently enabled. Disabled redirects will be ignored. Redirects are automatically enabled upon upsert. |
| referral_methodology | string | The Methodology used to merge referral parameters defined in the landing page vs supplied in the URL. |
| referral | object | The default Referral object associated with the landing page version. |
| created_at | integer | Unix timestamp of when the redirect was created (in seconds since the Unix epoch). |
| updated_at | integer | Unix timestamp of when the redirect was last updated (in seconds since the Unix epoch). |