CLI: 프로세스가 설정을 읽는지 확인
CLI 프로그램이 시스템 프록시를 자동으로 사용하는 것은 아닙니다. 먼저 사용하는 SDK나 도구의 프록시 지원 방식을 확인한 뒤 앱 설정, 환경 변수, 클라이언트의 네트워크 모드 중 적절한 방법을 선택하세요. HTTPS_PROXY, HTTP_PROXY, NO_PROXY의 적용 여부는 런타임과 실행 환경에 따라 달라집니다. 변수만 설정되어 있다고 해서 요청이 프록시를 통과한다고 단정할 수 없습니다.
프록시 주소와 포트는 로컬 클라이언트 설정에서 확인하고 다른 사람의 설정을 그대로 복사하지 마세요. 환경 변수를 변경해도 이미 실행 중인 터미널이나 프로그램에는 이전 값이 남아 있을 수 있으므로 해당 프로세스를 다시 시작해야 합니다. 문제를 확인할 때는 민감 정보를 가린 연결 오류를 참고하되 전체 요청 헤더, 인증 정보, 구독 정보를 출력하지 마세요.
IDE 플러그인: 화면과 실행 위치를 구분
에디터 본체, 확장 프로그램 호스트, 내장 터미널이 각기 다른 프록시 설정을 사용할 수 있습니다. Cursor 또는 Copilot의 로그인 창이 열려도 플러그인 요청까지 같은 네트워크 경로를 사용한다는 뜻은 아닙니다. 앱 설정, 확장 프로그램 안내, 오류 로그를 확인해 인증, 모델 응답, 리소스 다운로드 중 어느 단계가 실패했는지 파악한 뒤 해당 설정을 조정하세요.
원격 개발, 컨테이너, 작업 공간 연결을 사용하면 코드 실행 위치가 다른 호스트로 옮겨갈 수 있습니다. 로컬 클라이언트의 회선이 원격 프로세스에 자동으로 적용되지는 않습니다. 실제 요청을 실행하는 환경에서 네트워크를 점검하고 조직의 네트워크 관리 정책을 따르세요. 조직에서 일괄 배포한 보안 설정은 임의로 변경하지 마세요.
CI: 실행기가 연결된 네트워크에서 확인
CI 작업은 실행기에서 요청을 보내므로 로컬 브라우저 테스트 결과가 직접적인 증거가 되지 않습니다. 실행기의 네트워크 경로, 플랫폼 지원 지역, 인증 정보 권한, 작업 실행 시 적용되는 프록시 설정을 확인하세요. 컨테이너 네트워크도 별도의 경계를 가집니다. 컨테이너 내부의 로컬 주소는 호스트 주소와 같지 않습니다.
CI의 보호된 변수로 비밀 키를 주입하고 해당 키를 읽을 수 있는 작업 범위를 제한하세요. 실패 로그에는 오류 유형을 파악할 정보만 남기고 인증 정보, 비공개 프롬프트, 업무 내용을 가려야 합니다. 자동 재시도 전에 일시적인 네트워크 오류, 플랫폼 요청 제한, 권한 오류를 구분하고 실패 작업이 계속 반복 제출되지 않도록 하세요.