목차
티스토리 접속오류, HTTP ERROR 400 오류 해결방법, HTTP 상태코드
01
of 04
크롬 브라우저 HTTP ERROR 400 발생
어느 날부터인가 크롬 브라우저에서 갑자기 티스토리 메인 페이지에 접속이 안 된다. 개인 티스토리 블로그엔 접속이 되는데 티스토리 메인 페이지와 내가 운영 중인 블로그 목록이 뜨지 않는다. 혹시나 해서 웨일 브라우저를 사용해보니 이상 없이 잘 접속이 된다.
어차피 티스토리 메인 페이지는 접속할 일이 없어서 그냥 내버려 뒀는데, 운영 중인 블로그 목록이 뜨지 않고, 피드에 접속이 되지 않아서 결국은 해결책을 찾게 되었다.
02
of 04
HTTP 상태코드 4xx
상태 코드 | 상태 텍스트 | 서버 측면에서의 의미 |
4XX | Client Error | 클라이언트의 요청에 오류가 있다. |
400 | Bad Request | 요청의 구문이 잘못되었다. 클라이언트가 모르는 4xx 계열 응답 코드가 반환된 경우에도 클라이언트는 400과 동일하게 처리하도록 규정하고 있습니다. |
401 | Unauthorized | 지정한 리소스에 대한 액세스 권한이 없다. 응답 헤더 WWW-Authenticate에 필요한 인증 방식을 지정합니다. |
402 | Payment Required | 지정한 리소스를 액세스하기 위해서는 결제가 필요하다. 이 응답 코드는 실제로는 사용되지 않습니다. |
403 | Forbidden | 지정한 리소스에 대한 액세스가 금지되었다. 401 인증 처리 이외의 사유로 리소스에 대한 액세스가 금지되었음을 의미합니다. 리소스의 존재 자체를 은폐하고 싶은 경우는 404 응답 코드를 사용할 수 있습니다. |
404 | Not Found | 지정한 리소스를 찾을 수 없다. |
405 | Method Not Allowed | 요청한 URI가 지정한 메소드를 지원하지 않는다. 응답 헤더 Allow에 이 URI가 지원하는 메소드 목록을 기록합니다. |
406 | Not Acceptable | 클라이언트가 Accept-* 헤더에 지정한 항목에 관해 처리할 수 없다. 응답 바디에는 300 응답처럼 서버가 수용 가능한 다른 선택지 리스트가 기록됩니다. |
407 | Proxy Authentication Required | 클라이언트는 프록시 서버에 인증이 필요하다. 프록시 서버의 응답 헤더 Proxy-Authenticate에 필요한 인증 방식을 지정합니다. |
408 | Request Timeout | 요청을 기다리다 서버에서 타임아웃하였다. |
409 | Conflict | 서버가 요청을 수행하는 중에 충돌이 발생하였다. 예를 들어 사용자명을 new_name으로 변경하려 하였지만, 서버에 이미 new_name이라는 사용자가 존재하는 경우입니다. 응답 헤더 Location에는 충돌이 발생한 리소스의 URI를 기록합니다. |
410 | Gone | 지정한 리소스가 이전에는 존재하였지만, 현재는 존재하지 않는다. 예를 들어 기간이 한정된 프로모션 사이트가 사라진 경우 사용할 수 있는 응답 코드입니다. |
411 | Length Required | 요청 헤더에 Content-Length를 지정해야 한다. |
412 | Precondition Failed | If-Match와 같은 조건부 요청에서 지정한 사전 조건이 서버와 맞지 않는다. |
413 | Request Entity Too Large | 요청 메시지가 너무 크다. 서버는 접속을 끊습니다. |
414 | Request-URI Too Large | 요청 URI가 너무 길다. |
415 | Unsupported Media Type | 클라이언트가 지정한 미디어 타입을 서버가 지원하지 않는다. 예를 들어 서버가 지원하는 이미지는 JPG, PNG뿐인데 클라이언트가 GIF 형식의 이미지를 요청하는 경우입니다. |
416 | Range Not Satisfiable | 클라이언트가 지정한 리소스의 범위가 서버의 리소스 사이즈와 맞지 않는다. |
417 | Expectation Failed | 클라이언트가 지정한 Expect 헤더를 서버가 이해할 수 없다. |
418 ~ 421 | Unassigned | 현재 할당되지 않은 상태 코드입니다. |
422 | Unprocessable Entity | (WebDAV) 클라이언트가 송신한 XML이 구문은 맞지만, 의미상 오류가 있다. |
423 | Locked | (WebDAV) 지정한 리소스는 잠겨있다. |
424 | Failed Dependency | (WebDAV) 다른 작업의 실패로 인해 본 요청도 실패하였다. |
426 | Upgraded Required | 클라이언트의 프로토콜의 업그레이드가 필요하다. 응답에 Upgrade 헤더를 보내 필요한 프로토콜을 알려 줍니다. |
428 | Precondition Required | If-Match와 같은 사전조건을 지정하는 헤더가 필요하다. If-Match 헤더가 있지만, 맞지 않는 경우는 412 응답을 보냅니다. |
429 | Too Many Requests | 클라이언트가 주어진 시간 동안 너무 많은 요청을 보냈다. 요청의 속도를 제한할 때 사용합니다. 응답에 Retry-After 헤더를 보내 얼마나 기다릴지를 알려 줄 수 있습니다. |
431 | Request Header Fields Too Large | 헤더의 길이가 너무 크다. 헤더의 전체 크기가 크거나 또는 하나의 헤더가 매우 큰 경우입니다. 보통 Referer URL이 길거나 쿠키 항목이 많은 경우입니다. |
444 | Connection Closed Without Response | (NGINX) 응답을 보내지 않고 연결을 종료하였다. 보통 악의적인 요청에 대해서 사용하며 클라이언트에서는 응답을 볼 수 없고 Nginx 로그에는 나타납니다. |
451 | Unavailable For Legal Reasons | 법적으로 문제가 있는 리소스를 요청하였다. |
452 ~ 499 | Unassigned | 현재 할당되지 않은 상태 코드입니다. |
03
of 04
HTTP ERROR 400 발생 원인
웨일 브라우저에선 정상이고, 크롬 브라우저에서만 비정상인 걸 보면 아마도 크롬 브라우저 설정에서 무언가 문제가 발생한 것 같았다.
우선 HTTP ERROR 400 발생 원인은 잘못된 요청으로 문법상 오류가 있어서 서버가 요청사항을 이해하지 못하는 경우 (쉽게 말해서 주소 입력 오타 등) 또는, 브라우저 캐시에 문제가 있을 때 발생한다.
주소는 똑바르게 썼으니 주소 입력 오류는 아니기 때문에 브라우저 캐시 문제라 할 수 있다. 또한 웨일 브라우저에선 정상이니, 확실히 크롬 브라우저의 캐시 문제라 할 수 있겠다.
04
of 04
HTTP ERROR 400 해결방법
단순히 캐시 문제라면 해결 방법은 크롬 브라우저에서 캐시 삭제만 해주면 될 것 같다. 아래와 같이 크롬 브라우저에서 캐시를 삭제해준다.
1. 크롬 설정 접속
크롬 브라우저 오른쪽 상단 “크롬 맞춤설정 및 제어” 클릭 후 아래 쪽에 나오는 메뉴에서 “설정”을 클릭한다.
2. 인터넷 사용 기록 삭제 선택
좌측 메뉴에서 “개인정보 및 보안”을 클릭하고, 우측 개인정보 및 보안 하단 메뉴에서 “인터넷 사용 기록 삭제”를 클릭한다.
3. 쿠키 삭제
인터넷 사용 기록 삭제 팝업창이 새로 뜨는데, 오른쪽의 고급 탭을 선택하고, 기간은 전체기간을 선택, 쿠키 및 기타 사이트 데이터 체크 후 아래쪽 “인터넷 사용 기록 삭제” 파란색 버튼을 클릭한다.
4. 정상 접속
다시 티스토리에 접속하니 정상적으로 접속이 된다.