Zendesk 有一套完善的滥用保护系统,可保护所有 Zendesk 实例和平台的整体稳定性。大多数 Zendesk 客户及其客户(终端用户)直接通过互联网访问 Zendesk。Zendesk 采用此标准设置。偏离此标准的客户在连接到 Zendesk 时可能会遇到问题。
例如,一个组织可能希望其专员和终端用户通过设置反向代理从单一访问点或他们自己的 CDN 访问 Zendesk。反向代理拦截来自网络客户端尝试访问 Zendesk 的请求,并将其转发到 Zendesk。网络客户端从不直接与 Zendesk 通讯。只有代理直接与 Zendesk 通讯。
Zendesk 无法阻止客户以这种方式配置其访问权限。然而,这是一个非标准用例,可能导致不良行为,包括:
- 智能机器人管理挑战 (CAPTCHA)——如果所有请求都来自一个 IP 或 ASN,那么即使是合法用户,它们也更有可能被识别为智能机器人。如果代理或 CDN 以某种方式更改了 HTTP 标头,则更有可能出现这种情况。
- 拒绝搜索引擎抓取程序和其他“好”智能机器人——Cloudflare 可通过请求 IP 和 ASN 识别好智能机器人。例如,如果带有 Googlebot 用户代理的请求的请求 IP 与 Google 的注册 IP 不同,则该请求将被 Cloudflare 拒绝。
- 索引错误的页面——如果未被 Cloudflare 拒绝,搜索抓取程序可能会尝试使用 Zendesk 网站元数据标签提供的规范 URL。因此,如果搜索引擎实际抓取了一个被代理的网站,它会将非代理 URL 的页面编入索引。
- 速率限制 - 速率限制根据请求 IP 应用。如果所有客户请求都通过一个或一小组 IP 地址发送,则更有可能应用速率限制。
- 缓存问题 - 如果您的代理或 CDN 设置有自定义缓存逻辑,Zendesk 无法保证此缓存的完整性。例如,已删除文章在代理中可见的时间可能比在帮助中心里的时间长。对权限的更改也可能会延迟。
在使用反向代理之前,请考虑它是否真的有必要。如果您需要更改帮助中心的 URL,可以使用主机映射。请参阅 主机映射 —— 更改帮助中心的 URL。
指南
如果使用反向代理访问 Zendesk 不可避免,请记住以下指南:
-
通过代理的所有流量都必须使用多个 IP 进行传出,以避免速率限制和看起来像智能机器人
-
反向代理必须是透明的,不得以任何方式操纵标头,例如覆盖用户代理
即便如此,流量仍可能被 Zendesk 系统归类为智能机器人流量。如果您遵循这些指南后仍然遇到问题,请联系您的 IT 部门寻求帮助。
翻译免责声明:本文章使用自动翻译软件翻译,以便您了解基本内容。 我们已采取合理措施提供准确翻译,但不保证翻译准确性
如对翻译准确性有任何疑问,请以文章的英语版本为准。