문제해결

403: 계정이 사용 중지됨

문제: 버킷을 만들려 했지만 403 Account Disabled 오류가 발생했습니다.

해결 방법: 이 오류는 관련 프로젝트에서 결제를 사용 설정하지 않은 경우에 발생합니다. 결제 설정 방법은 프로젝트에 대한 결제 설정을 참조하세요.

결제를 사용 설정해도 오류 메시지가 계속 나타나는 경우 프로젝트 ID와 문제에 대한 설명을 제공하여 지원을 받을 수 있습니다.

403: 액세스 거부됨

문제: 버킷의 객체를 나열하려 했지만 403 Access Denied 오류가 발생했습니다.

해결 방법: 사용자 인증 정보가 올바른지 확인하세요. 예를 들어 gsutil을 사용하는 경우 Boto 파일에 저장된 사용자 인증 정보가 정확한지 확인합니다.

올바른 사용자 인증 정보를 사용 중이라고 가정하고 HTTPS 대신 HTTP를 사용하여 프록시를 통해 요청이 라우팅되는지 확인하세요. 라우팅된다면 프록시가 해당 요청에서 Authorization 헤더를 삭제하도록 구성되어 있는지 확인하세요. 이 경우에 해당하면 요청에 HTTP 대신 HTTPS를 사용하도록 합니다.

409: 충돌

문제: 버킷을 만들려고 시도했지만 다음 오류가 발생했습니다.

409 Conflict. Sorry, that name is not available. Please try a different one.

해결 방법: 사용하려 했던 버킷 이름(예: gs://cats 또는 gs://dogs)이 이미 사용 중입니다. Cloud Storage에는 전역 네임스페이스가 있으므로 기존 버킷과 동일한 이름을 사용해서는 안 됩니다. 사용 중이 아닌 이름을 선택하세요.

프록시 서버

문제: 프록시 서버를 통해 연결 중입니다. 무엇을 해야 하나요?

해결 방법: Cloud Storage에 대한 요청은 accounts.google.com(OAuth2 토큰 교환)과 *.googleapis.com(스토리지 요청)에 액세스해야 합니다. 프록시 서버를 통해 Cloud Storage에 액세스하는 경우 이러한 도메인에 액세스를 허용해야 합니다. 프록시 서버 또는 보안 정책이 도메인별 허용 목록을 지원하지 않고 대신 IP 네트워크 블록별 허용 목록이 필요한 경우 모든 Google IP 주소 범위에 대해 프록시 서버를 구성하는 것이 좋습니다. ARIN에서 WHOIS 데이터를 쿼리하여 주소 범위를 찾을 수 있습니다. 권장사항으로는 정기적으로 프록시 설정을 검토하여 Google의 IP 주소와 일치하는지 확인하는 것입니다.

storage.googleapis.comaccounts.google.com을 통한 한 번의 조회에서 얻은 개별 IP 주소로 프록시를 구성하지 않는 것이 좋습니다. Google 서비스는 시시각각 변하는 매우 많은 IP 주소에 매핑되는 DNS 이름을 통해 노출되기 때문에 한 번의 조회를 기반으로 프록시를 구성하면 Cloud Storage에 연결하지 못할 수 있습니다.

프록시 서버를 통해 요청이 라우팅 되는 경우 네트워크 관리자로부터 사용자 인증 정보를 포함한 Authorization 헤더가 프록시에서 제거되지 않았는지 확인해야 합니다. Authorization 헤더가 없으면 요청이 거부되고 MissingSecurityHeader 오류가 발생합니다.

gsutil stat

문제: gsutil stat 명령어를 사용하여 하위 디렉토리의 객체 상태를 표시하려 했지만 오류가 발생했습니다.

해결 방법: Cloud Storage는 플랫 네임스페이스를 사용하여 객체를 버킷에 저장합니다. 객체 이름에 슬래시('/')를 넣어 객체가 계층구조에 속한 것처럼 보이게 할 수 있지만 gsutil stat 명령어는 맨 뒤의 슬래시를 객체 이름의 일부로 처리합니다.

예를 들어 gsutil -q stat gs://my-bucket/my-object/ 명령어를 실행하면 gsutil은 my-bucket/my-object/ 아래에 중첩된 객체가 아닌 my-object/ 객체(뒤에 오는 슬래시 포함)에 대한 정보를 조회합니다. 실제로 이 이름을 가진 객체가 없으면 작업은 실패합니다.

하위 디렉토리 목록을 보려면 대신 gsutil ls를 사용하세요.

웹사이트로 구성된 버킷

다음은 정적 웹사이트를 호스팅할 버킷을 설정할 때 일반적으로 발생하는 문제입니다.

HTTPS 제공

문제: HTTPS를 통해 콘텐츠를 제공하고 싶습니다.

해결 방법: https://storage.googleapis.com/my-bucket/my-object와 같은 직접 URI를 사용하여 HTTPS를 통해 콘텐츠를 제공할 수 있지만, CNAME 리디렉션을 사용하여 정적 웹사이트를 호스팅하는 경우 Cloud Storage는 HTTP만 지원합니다. SSL을 통해 커스텀 도메인으로 콘텐츠를 제공하려면 부하 분산기를 설정하거나, 타사 콘텐츠 전송 네트워크를 Cloud Storage와 함께 사용하거나, Cloud Storage 대신 Firebase 호스팅에서 정적 웹사이트 콘텐츠를 제공해야 합니다.

도메인 확인

문제: 내 도메인을 인증할 수 없습니다.

해결 방법: 일반적으로 Search Console의 확인 프로세스에서는 파일을 도메인에 업로드하도록 지시하지만 도메인 확인을 수행한 후에만 만들 수 있는 관련 버킷이 없어 이 작업을 수행하지 못할 수 있습니다.

이러한 경우 도메인 이름 공급업체 인증 방법을 사용하여 소유권을 인증하세요. 이 작업을 수행하는 방법은 소유권 인증을 참조하세요. 버킷을 만들기 전에 이 인증을 수행할 수 있습니다.

액세스 불가 페이지

문제: 웹사이트에서 제공하는 웹페이지에 Access denied 오류 메시지가 표시됩니다.

해결 방법: 객체가 공개로 공유되는지 확인하세요. 그렇지 않은 경우 데이터 공개 설정을 참조하세요.

이전에 객체를 업로드하고 공유한 후 새 버전을 업로드한 경우 객체를 다시 공개로 공유해야 합니다. 이는 새 업로드가 공개 권한을 덮어쓰기 때문입니다.

콘텐츠 다운로드

문제: 내 페이지의 콘텐츠를 브라우저에서 보는게 아니라 다운로드하라는 메시지가 표시됩니다.

해결 방법: MainPageSuffix를 웹 콘텐츠 유형이 아닌 객체로 지정하면 페이지를 제공하는 대신 사이트 방문자에게 콘텐츠를 다운로드하라는 메시지가 표시됩니다. 이 문제를 해결하려면 content-type 메타데이터 항목을 text/html과 같은 적절한 값으로 업데이트하세요. 이 작업을 수행하는 지침은 객체 메타데이터 수정을 참조하세요.

301: 영구 이전

문제: 디렉토리 경로에 액세스하면 빈 객체와 301 HTTP 응답 코드가 반환됩니다.

해결 방법: http://www.example.com/dir/과 같은 디렉토리에 액세스할 때 브라우저에서 0바이트 객체가 다운로드되고 301 HTTP 응답 코드가 반환되는 경우 버킷에 해당 이름의 빈 객체가 있을 가능성이 높습니다. 이러한 경우인지 확인하고 문제를 해결하려면 다음 단계를 따릅니다.

  1. Google Cloud Platform Console에서 Cloud Storage 브라우저를 엽니다.
    Cloud Storage 브라우저 열기
  2. Google Cloud Platform Console 상단의 Cloud Shell 활성화 버튼을 클릭합니다. Cloud Shell 활성화
  3. gsutil ls -R gs://www.example.com/dir/을 실행합니다. 출력에 http://www.example.com/dir/이 포함되어 있으면 해당 위치에 빈 객체가 있는 것입니다.
  4. 다음 명령어를 사용하여 빈 객체를 삭제합니다. gsutil rm gs://www.example.com/dir/

이제 http://www.example.com/dir/에 액세스하여 빈 객체 대신 해당 디렉토리의 index.html 파일을 반환하도록 할 수 있습니다.

다음 단계

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

도움이 필요하시나요? 지원 페이지를 방문하세요.