CLI 및 SDK
프로그램이 시스템 프록시를 읽는지, 아니면 HTTP 또는 SOCKS 프록시를 직접 설정해야 하는지 먼저 확인하세요. 일부 런타임은 HTTP_PROXY, HTTPS_PROXY 또는 ALL_PROXY를 읽지만 변수 지원 여부, 우선순위, DNS 확인 위치는 사용하는 도구에 따라 다릅니다. 모든 SDK가 같은 규칙을 따른다고 가정하지 마세요. 프록시 주소에는 클라이언트가 실제로 제공하는 로컬 주소와 포트를 사용하고, 튜토리얼을 보고 임의로 추측하지 마세요.
NO_PROXY에 대상 서비스가 잘못 제외되어 있지 않은지 확인하세요. 환경 변수를 수정한 뒤에는 터미널이나 관련 프로세스를 다시 시작해야 합니다. 이미 실행 중인 프로세스에는 새 값이 적용되지 않을 수 있습니다. TLS 인증서 오류가 발생하면 시스템 시간, 인증서 체인, 기업 네트워크 정책을 확인하고 인증서 검증을 꺼서 문제를 덮지 마세요.
IDE, 플러그인 및 원격 개발
Cursor, GitHub Copilot 및 다른 편집기 플러그인은 앱의 기본 프로세스, 확장 프로그램 호스트, 통합 터미널에서 각각 요청을 보낼 수 있습니다. 브라우저 인증은 성공했는데 편집기에서 오류가 계속되면 인증 결과가 앱으로 돌아왔는지 확인한 뒤 편집기와 확장 프로그램의 프록시 설정을 점검하세요. 통합 터미널에서 접속된다고 모든 플러그인이 같은 경로를 사용한다고 단정할 수는 없습니다.
원격 개발, 컨테이너 또는 하위 시스템을 사용할 때 localhost는 현재 환경을 가리키며 데스크톱 클라이언트가 있는 기기를 가리키지 않을 수 있습니다. 먼저 네트워크 경계와 합법적으로 접근 가능한 프록시 주소를 확인한 뒤 도구 문서에 따라 설정하세요. 원격 연결을 위해 로컬 프록시를 인터넷에 공개하면 위험이 커지므로 기본 해결책으로 삼지 마세요.
CI 및 자동화 작업
CI의 네트워크 출구는 러너가 실행되는 환경에 따라 결정되며, 로컬 회선 설정은 코드 저장소와 함께 업로드되지 않습니다. 러너에서 DNS와 대상 API 연결을 확인하고 실제 작업 프로세스에 프록시 설정을 전달하세요. 기업의 자체 호스팅 러너라면 조직 네트워크 규칙도 확인해야 합니다. 공유 러너의 출구 IP가 바뀌면 지역 판정에도 영향을 줄 수 있습니다.
API 키는 CI의 시크릿 변수에 보관하고 저장소, 빌드 결과물, 디버그 로그에 기록하지 마세요. 문제 해결 로그에는 필요한 오류 유형, 발생 단계, 비식별 처리된 요청 ID만 남기고 인증 헤더, 전체 키, 구독 주소는 출력하지 마세요. 장시간 실행 작업에서는 최초 연결뿐 아니라 자격 증명 갱신, 요청 취소, 서버의 요청 제한 처리도 고려해야 합니다.