WordPress가 자체 사이트를 프록시 밖에 두는 이유
프록시 상수가 외부에서는 작동하지만 사이트 자체로 가는 요청이 직접 나갈 때 WordPress HTTP API의 우회 규칙을 고려하십시오.
WP_PROXY_HOST와 WP_PROXY_PORT가 설정되어 있습니다. 외부 API로 가는 요청은 프록시를 사용하지만, WordPress 자체의 호스트 이름으로 돌아가는 요청은 사용하지 않습니다. 이는 HTTP API의 의도된 우회 정책일 수 있습니다.
WP_HTTP_Proxy는 특정 URI가 프록시를 통과해야 하는지 결정합니다. 기본 로직은 localhost와 사이트의 설정된 siteurl에서 파생된 호스트 이름을 우회합니다. 이는 프록시 상수가 존재하는지만 결정하는 것과는 별개입니다.
WordPress가 평가한 URL을 확인하십시오
요청한 호스트 이름, 설정된 사이트 URL, WP_PROXY_BYPASS_HOSTS를 함께 확인하십시오. 공용 호스트 이름으로 가는 요청과 내부 별칭으로 가는 요청은 둘 다 같은 애플리케이션에 도달하더라도 다른 결정을 내릴 수 있습니다.
WP_PROXY_BYPASS_HOSTS는 설정된 호스트 제외 목록을 추가합니다. 원격 프록시가 허용하는 목적지 집합이 아니며, 다른 방식으로 차단된 외부 요청을 허용 가능하게 만들지 않습니다.
기본 자체 사이트 제외는 유용할 수 있습니다. 로컬 루프백 형태의 애플리케이션 요청이 중간자로 나가는 것을 피합니다. 그러나 공개 사이트 호스트 이름이 특정 승인된 경로로만 도달 가능한 설치에서는 다른 의도적인 결정이 필요할 수 있습니다.
지원되는 훅에서 결정을 변경하십시오
pre_http_send_through_proxy 필터는 URI별 결정을 재정의할 수 있습니다. 모든 재정의를 좁게 유지하고 처리해야 하는 호스트나 조건에 맞추십시오. 모든 URI에 하나의 고정된 답을 반환하면 전체 HTTP API의 정책이 바뀝니다.
선택한 전송 방식도 검토하십시오. 별도의 SDK나 원시 PHP 네트워크 함수를 호출하는 코드는 WordPress의 HTTP API와 그 필터를 자동으로 사용하지 않습니다.
이 경로를 진단할 때는 전체 요청 인자를 공개하지 않고 우회 결정을 기록하십시오. 여기에는 쿠키, 계정 정보, 프록시 비밀이 포함될 수 있습니다. 일치하는 요청이 없는 프록시 로그는 우회와 일치하지만, 그것만으로는 한 번도 이루어지지 않은 요청과 구분하기에 충분하지 않습니다.