systemd 서비스에 셸의 프록시 설정이 전달되지 않는 이유

터미널의 export로 실행 중인 프로세스가 바뀌기를 기대하지 말고 systemd 서비스가 실제로 사용하는 환경에 프록시를 설정하세요.

터미널에서 변수를 하나 더 내보내는 대신 실패하는 서비스를 살펴보세요. systemctl cat example.service는 유닛과 드롭인 설정을 보여 줍니다. EnvironmentFile, 다른 재정의 설정 또는 애플리케이션 자체 프록시 설정이 있는지 확인하세요. 인증 정보가 포함된 출력은 로컬에서 읽으세요.

애플리케이션이 HTTP 프록시 환경 변수를 사용한다면 서비스 드롭인에 다음을 지정할 수 있습니다.

[Service]
Environment="HTTP_PROXY=http://203.0.113.10:8080"
Environment="HTTPS_PROXY=http://203.0.113.10:8080"

문서용 예제 주소를 바꾸고 애플리케이션이 지원하는 변수 이름을 사용하세요. 공개 HTTP 프록시 사용이 허용된 서비스라면 HTTP 프록시 목록에서 후보 주소를 찾을 수 있습니다. 자체 설정이 있는 클라이언트는 이 입력을 무시할 수 있습니다. 또한 의도한 시스템 서비스가 맞는지 확인하세요. 사용자 서비스는 관리자와 환경이 다르므로 이름이 비슷한 시스템 유닛을 바꿔도 해결되지 않습니다.

의도한 유닛이나 드롭인을 편집한 뒤 정의를 다시 읽고, 작업을 중단할 수 있을 때 해당 서비스를 재시작하세요.

sudo systemctl daemon-reload
sudo systemctl restart example.service

daemon-reload만으로는 실행 중인 프로세스의 환경이 바뀌지 않습니다. 재시작해야 새 프로세스가 시작됩니다. 셸에서 export를 하면 해당 셸과 그 이후에 해당 셸이 시작하는 자식 프로세스에만 영향을 줍니다.

서비스가 예상한 URL을 받으면 실제 오류를 따라가세요. 서비스 계정에 CA 파일 접근 권한이 없을 수 있고, 네트워크 네임스페이스에서 리스너에 도달하지 못하거나 프록시가 요청을 거부할 수도 있습니다. 이들은 다음에 확인할 사항이며, 관련 없는 셸 프로필을 계속 편집할 이유가 아닙니다.

관련 글