명령줄: 프로세스가 실제로 읽는 설정 확인
터미널에서 실행하는 도구가 시스템 프록시를 사용하는 것은 아닙니다. 일부 프로그램은 HTTP_PROXY, HTTPS_PROXY, ALL_PROXY를 읽지만, SDK에 따라 코드에서 프록시 전송 계층을 별도로 설정해야 할 수도 있습니다. 사용 중인 도구의 문서를 확인하고 클라이언트에 표시된 로컬 리스닝 주소와 포트를 사용하세요. 다른 사람의 값을 그대로 복사하지 마세요. 프록시 프로토콜, 인증 방식, SDK 지원 범위도 서로 맞아야 합니다.
설정을 바꾼 뒤에는 관련 프로세스를 다시 시작하고 테스트하세요. NO_PROXY에서 대상 도메인이 의도치 않게 제외되지 않았는지, 컨테이너와 자식 프로세스가 환경 변수를 상속하는지도 확인합니다. 동기화되는 셸 설정, 명령 기록, 프로젝트 저장소에 키를 저장하지 마세요. 디버그 출력도 민감 정보를 가려야 합니다.
IDE 플러그인: 편집기와 플러그인 호스트를 따로 확인
IDE 내장 브라우저에서 로그인할 수 있다고 해서 플러그인 호스트도 모델 API에 연결된다는 뜻은 아닙니다. 편집기의 프록시 옵션, 플러그인 로그, 인증 상태를 확인하세요. 원격 개발 환경에서는 플러그인이 로컬과 원격 중 어디에서 실행되는지도 확인해야 합니다. 인증서 오류가 나면 시스템 시간, 인증서 체인, 조직 네트워크 요구 사항을 점검하고, 문제를 덮기 위해 TLS 검증을 끄는 방법은 권장하지 않습니다.
CI 및 원격 호스트: 로컬 설정은 자동으로 이어지지 않습니다
클라우드 CI 러너, 원격 호스트, 개발 컨테이너는 각각 별도의 네트워크 환경을 사용합니다. 노트북이 VPNPack에 연결되어 있어도 원격 작업이 같은 출구를 공유하는 것은 아닙니다. 실행 환경 및 도구 이용 약관을 준수하는 범위에서 별도로 설정하고, 플랫폼의 비밀 정보 관리 기능으로 자격 증명을 전달하세요. 로그에 환경 변수 전체를 출력하거나 로컬 프록시 리스닝 서비스를 인터넷에 직접 노출하지 마세요.
문의하기 전에 클라이언트 이름, 운영체제, 오류가 발생한 단계, 민감 정보를 가린 오류 내용을 정리해 두면 도움이 됩니다. 단순히 'AI가 안 돼요'라고 쓰는 것보다 '로컬 브라우저는 정상인데 원격 플러그인에서 실패함'이라고 설명하면 문제의 원인을 파악하기 쉽습니다. VPNPack 연결 문제와 제3자 플랫폼 계정 문제는 해당 서비스의 지원 채널에 각각 문의하세요.