명령줄 프로세스의 프록시를 명시적으로 확인해야 합니다
터미널 도구가 시스템 프록시를 사용하는지는 운영체제, Shell, 런타임, 구체적인 클라이언트에 따라 달라집니다. 점검할 때는 먼저 현재 터미널에서 확인되는 환경 변수를 살펴본 뒤, 같은 터미널에서 실제 프로그램을 실행해 보세요. 설정을 변경해도 차이가 없다면 터미널을 다시 열어 이전 프로세스가 시작 당시 읽은 환경을 계속 사용하는 일을 방지하세요.
요청 대상이 우회 목록에서 제외되어 있는지도 확인하세요. 너무 넓은 우회 규칙 때문에 AI API는 직접 연결되고 웹은 브라우저 확장 기능을 통해 정상적으로 접속하는, 겉보기에는 모순된 결과가 나타날 수 있습니다.
IDE와 플러그인은 독립적인 네트워크 스택을 사용할 수 있습니다
Cursor, Copilot 및 다른 편집기 플러그인은 편집기 주 프로세스, 확장 호스트 또는 백그라운드 하위 프로세스에서 요청을 보낼 수 있습니다. 시스템 프록시가 이미 적용되었다고 해서 모든 플러그인이 자동으로 상속하는 것은 아닙니다. 프록시를 변경한 뒤에는 편집기를 완전히 재시작하고 로그인, 모델 요청, 내장 터미널을 각각 확인하세요.
플러그인만 실패하고 브라우저는 정상이라면 편집기의 프록시 설정, 인증서 처리, 확장 기능 로그를 확인하세요. 여러 지역으로 연속해서 변경하지 마세요. 계정 환경의 변화를 늘려 원래 문제를 오히려 가릴 수 있습니다.
CI 환경에서는 고정 출구와 작업 격리를 고려해야 합니다
자동화 작업은 보통 독립된 환경에서 실행되므로 개인 컴퓨터의 회선 설정을 상속하지 않습니다. 설정할 때는 작업이 어디에서 시작되는지, 어떤 출구를 사용하는지, 빌드 단계에서 대상 서비스에 접근할 수 있는지를 명확히 해야 합니다. 여러 작업을 병렬로 실행할 때는 타사 플랫폼의 호출 규정과 요청 제한 정책도 준수해야 합니다.
네트워크 재시도는 일시적인 연결 실패만 처리해야 하며, 인증 실패나 매개변수 오류를 무한히 반복해서는 안 됩니다. 오류를 네트워크, 권한, 할당량, 요청 내용으로 분류하면 불필요한 호출을 줄이고 문제가 네트워크 계층에서 발생했는지 애플리케이션 계층에서 발생했는지도 쉽게 파악할 수 있습니다.
인증 정보와 네트워크 설정을 분리해 관리하세요
API 키는 관리되는 환경 변수나 보안 키 관리 시스템에 보관하고 스크립트, 로그, 공개 저장소에 기록하지 마세요. 프록시 주소, 인증 정보, 업무용 키도 서로 분리해 관리해야 네트워크를 점검하는 과정에서 민감한 내용이 실수로 출력되는 일을 막을 수 있습니다. 로그를 공유하기 전에는 요청 헤더, 쿼리 매개변수, 환경 변수를 먼저 정리하세요.