fatal: unable to access: The requested URL returned error: 502 에러 해결하기

구체적인 에러 해결 방법을 알아보기 전, 500번대 에러 코드들에 대해 알아보고 가자.

 

먼저 500번대 에러 코드는 서버 오류로, 클라이언트 측의 문제가 아니라 서버나 서버와의 연결 문제로 발생한다.

에러 코드	에러 설명	발생 원인
500 Internal Server Error	서버에서 예상치 못한 오류가 발생했을 때 나타난다. 구체적인 원인은 로그나 설정 파일을 통해 파악해야 한다.	서버 설정 오류, 어플리케이션의 버그, 과부하로 인한 서버 자원 부족 등
502 Bad Gateway	서버가 다른 서버로부터 잘못된 응답을 받았을 때 발생한다. 주로 프록시 서버나 게이트웨이 서버가 다른 서버와 통신하며 문제가 발생했을 때 나타난다.	프록시 서버와 연결된 서버의 응답 지연, 서버 다운, 네트워크 문제, 서버 간의 데이터 통신 오류 등
503 Service Unavailable	서버가 일시적으로 사용 불가능할 때 발생한다. 주로 서버 과부하나 서버 점검 시 나타난다.	서버의 자원 과부하, 서버 점검 중, 서비스 유지보수 중, 일시적인 네트워크 장애 등
504 Gateway Timeout	서버가 다른 서버로부터 응답을 받지 못할 때 발생한다. 게이트웨이 서버가 일정 시간 내에 요청을 처리할 수 없는 경우이다.	연결된 서버의 응답 지연, 네트워크 문제, 서버가 처리할 수 있는 양을 초과한 요청 등
505 HTTP Version Not Supported	클라이언트가 서버에 요청한 HTTP 버전을 서버가 지원하지 않을 때 발생한다. 주로 서버와 클라이언트 간의 프로토콜 불일치 시 나타난다.	클라이언트가 서버가 지원하지 않는 HTTP 버전을 사용하거나 서버가 특정 HTTP 버전을 지원하지 않는 등
507 Insufficient Storage	서버가 요청을 처리하기에 충분한 저장 공간이 없을 때 발생한다.	서버의 디스크 공간 부족, 데이터베이스나 파일 시스템의 공간 부족 등
508 Loop Detected	서버가 무한 루프를 발견했을 때 발생한다.	잘못된 리디렉션 설정, 무한 루프에 빠진 서버 설정 등

 

fatal: unable to access: The requested URL returned error: 502 에러

 

로컬 저장소에서 변경 사항 add, commit 후 push를 하려고 하니 아래와 같은 에러가 발생하였다.

1
2
3

 

원격 저장소에 접근할 수 없고 500 에러가 발생했다는 것이다.

 

일반적으로 500 에러는 서버 측에서 문제가 발생한 경우이지만 설마 GitHub 측에서 문제가 발생했겠나 싶어

 

네트워크 문제는 아닌지, 그리고 찾아보니 HTTPS를 통해 GitHub에 연결할 때 인증 문제가 발생하는 경우가 많다고 하여* 자격 증명 캐시를 삭제**해보았다.

 

* 이 경우 서버에는 정상적으로 연결되었지만 GitHub에서 사용자 인증을 거부하는 경우로, 예를 들어 잘못된 자격 증명이 캐시된 상태에서 push를 실행하면 사용자 인증이 거부되어 오류가 발생할 수 있다.

 

** Git은 인증 정보를 자격 증명 캐시에 저장하여 매번 인증을 입력하지 않도록 한다. Windows의 경우 '자격 증명 관리자'에서 자격 증명 캐시를 관리하는데, 자격 증명 관리자에서 github.com 항목을 삭제하면 자격 증명 캐시가 삭제되고 이후 push를 실행하면 새로운 인증 정보를 입력하도록 한다.

 

그러니 이제는 502 에러가 발생했다.

1
2

 

에러 해결하기

 

이 정도 되니 서버 측에서 문제가 발생한건가 싶어 GitHub Status를 확인해보았다.

 

clone, pull, push 등과 관련된 Git Operations에 문제가 발생했다고 한다.

 

한 10분 정도 기다려보니 degraded git operations를 해결했다는 공지가 올라왔다.

 

상태표도 모두 정상으로 수정되었다.

 

push도 정상적으로 실행되었다!

1
2
3
4
5
6
7
8
9
10
11
12
13

 

에러가 발생하면 항상 나를 먼저 의심해보곤 했는데, 그리고 대부분 그런 경우가 많았는데

 

하필 GitHub 보수 중에 push를 하여 이런 상황도 겪어보다니 신기했다.