터미널에서는 되는 프록시가 PHP-FPM에서 사라지는 이유
프록시 구성을 PHP-FPM 워커까지 추적하고 그 환경을 PHP 스트림 컨텍스트와 구분합니다.
같은 PHP 파일이 터미널에서는 프록시를 쓰고 PHP-FPM이 서비스할 때는 직접 연결할 수 있습니다. 먼저 실행하는 프로세스를 비교하세요. 터미널은 셸 환경으로 PHP를 시작하지만, 웹 서버는 FPM이 미리 만든 워커에 요청을 보냅니다.
워커의 환경을 확인하세요
FPM 풀 구성은 clear_env와 명시적 env[NAME] 항목을 제공합니다. 환경 정리가 켜져 있으면 로그인 셸에서 변수를 내보내도 워커에 들어가지 않습니다. 풀 항목으로 선택한 변수를 전달할 수 있습니다:
env[http_proxy] = http://203.0.113.10:8080
env[https_proxy] = http://203.0.113.10:8080배포의 일반적인 FPM 재시작 절차로 구성 변경을 적용하세요. 값을 실제로 애플리케이션을 서비스하는 풀에 넣으세요. 다른 풀, 서비스 계정 또는 컨테이너가 있으면 겉보기에 올바른 수정이 왜 효과가 없는지 설명될 수 있습니다.
실행 중인 요청을 디버깅할 때는 예상한 설정이 있는지만 확인하세요. 전체 환경 값을 출력하는 공개 진단 페이지는 프록시 자격 증명과 무관한 비밀까지 노출할 수 있습니다.
그다음 PHP 전송 계층을 확인하세요
libcurl에는 문서화된 프록시 환경 처리 방식이 있고, 명시적 PHP cURL 핸들에도 자체 옵션이 있습니다. PHP의 HTTP 스트림 래퍼에는 별도의 컨텍스트 구성이 있습니다. 워커에 변수를 제공한다고 해서 모든 PHP 네트워크 API가 그것을 사용하는 것은 아닙니다.
이렇게 하면 유용한 두 단계 점검이 됩니다. 워커가 무엇을 받았는지 확인한 다음, 선택한 HTTP 클라이언트가 프록시 설정을 어떻게 읽는지 확인하세요. CLI와 FPM이 같은 값을 받는데도 다르게 동작한다면 다음으로 클라이언트 옵션과 우회 규칙을 비교하세요. 셸 프로필을 반복해서 수정해도 워커의 HTTP 클라이언트 내부 차이는 해결되지 않습니다.