Zendesk는 모든 Zendesk 인스턴스와 플랫폼의 전반적인 안정성을 보호하는 정교한 남용 방지 시스템을 갖추고 있습니다. 대부분의 Zendesk 고객사와 그들의 고객(최종 사용자)은 인터넷을 통해 직접 Zendesk에 액세스합니다. Zendesk는 이러한 표준 설정을 가정합니다. 이러한 표준에서 벗어나는 고객은 Zendesk에 연결할 때 문제를 겪을 수 있습니다.
예를 들어 조직에서 역방향 프록시를 설정하여 단일 액세스 지점이나 자체 CDN에서 상담사와 최종 사용자가 Zendesk에 액세스하도록 하고자 할 수 있습니다. 역방향 프록시는 Zendesk에 액세스하려는 웹 클라이언트의 요청을 가로채 Zendesk에 전달합니다. 웹 클라이언트는 Zendesk와 직접 통신하지 않습니다. 프록시만 Zendesk와 직접 통신합니다.
Zendesk는 고객이 이러한 방식으로 액세스를 구성하는 것을 막을 수 없습니다. 하지만 이러한 방식은 표준 사용 사례가 아니며 다음을 포함하여 원치 않는 동작이 발생할 수 있습니다.
- 봇 관리 챌린지(CAPTCHA) - 모든 요청이 단일 IP 또는 ASN을 통해 들어오는 경우 올바른 사용자일지라도 봇으로 식별될 가능성이 높습니다. 프록시나 CDN이 어떤 식으로든 HTTP 헤더를 변경하는 경우에는 더욱 그렇습니다.
- 검색 엔진 크롤러 및 기타 “좋은” 봇 거부 - Cloudflare는 요청 IP 및 ASN을 통해 부분적으로 좋은 봇을 식별합니다. 예를 들어 Googlebot 사용자 에이전트를 통한 요청에 Google에 등록된 IP와 다른 요청 IP가 있으면 Cloudflare가 이 요청을 거부합니다.
- 잘못된 페이지 인덱싱 - Cloudflare에서 거부하지 않으면 검색 크롤러는 Zendesk 사이트 메타데이터 태그에서 제공하는 표준 URL을 사용하려고 시도할 가능성이 높습니다. 그 결과, 검색 엔진이 실제로 프록시된 사이트를 크롤링하는 경우 프록시되지 않은 URL이 있는 페이지를 인덱스합니다.
- 호출 빈도 제한 - 요청 IP를 기반으로 호출 빈도 제한이 적용됩니다. 모든 고객 요청이 단일 또는 적은 수의 IP 주소를 통해 이동하는 경우 호출 빈도 제한이 적용될 가능성이 높습니다.
- 캐시 문제 - 프록시 또는 CDN 설정에 사용자 지정 캐싱 논리가 있는 경우 Zendesk는 이 캐시의 무결성을 보장할 수 없습니다. 예를 들어 삭제된 문서는 헬프 센터보다 프록시에서 더 오래 볼 수 있습니다. 권한 변경 내용이 지연될 수도 있습니다.
역방향 프록시를 사용하기 전에 꼭 필요한지 다시 생각해 보시기 바랍니다. 헬프 센터의 URL을 변경해야 하는 경우에는 대신 호스트 맵핑을 사용할 수 있습니다. 호스트 맵핑 - 헬프 센터의 URL 변경하기를 참조하세요.
가이드라인
Zendesk에 액세스하는 데 역방향 프록시를 사용하는 것이 불가피한 경우 다음 가이드라인을 염두에 두세요.
-
프록시를 통한 모든 트래픽은 호출 빈도 제한을 피하고 봇처럼 표시되지 않도록 여러 IP를 송신에 사용해야 합니다.
-
역방향 프록시는 투명해야 하며 사용자 에이전트를 덮어쓰는 등 어떤 방식으로도 헤더를 조작해서는 안 됩니다.
그렇더라도 Zendesk 시스템에서 트래픽을 여전히 봇 트래픽으로 분류할 수 있습니다. 이러한 가이드라인을 따른 후에도 계속 문제가 발생하면 회사 IT 부서에 연락하여 도움을 구하세요.
댓글 0개