nginx 접근 로그 의 400 오류 부터

최근 nginx + php + mysql 사이트 에 설치 한 결과 nginx 의 access. log 파일 (즉 방문 로그) 에 400 개의 오류 가 발생 했 습 니 다. HTTP 상태 코드 를 아 는 동 화 는 이 상태 코드 가 잘못된 클 라 이언 트 요청 을 표시 한 다 는 것 을 알 고 있 습 니 다. 다시 말 하면 서버 가 사용자 측의 요청 을 이해 할 수 없습니다.
서버 의 오류 기록 은 다음 과 유사 합 니 다: 127.0.0.1 -- [01 / Oct / 2011: 11: 51: 04 + 0800] "-" 4000 "-" - "-" - "
밟 기:
  nginx 의 log 파일 을 분석 한 결과 정상 적 인 방문 후에 발생 하 는 400 개의 오류 가 있 고 매번 에 1 - 6 개의 오류 가 연속 적 으로 발생 하 는 것 을 발견 했다. 또한 매번 에 고객 이 방문 할 때마다 400 개의 오류 가 발생 하 는 것 도 아니다.
  400 오류 가 발생 한 이전 방문 은 정상 적 이 었 습 니 다. 200 상태 코드, 정상 적 인 파일, 정상 적 인 경로, 정상 적 인 User - agent... 모든 것 이 조 화 롭 습 니 다. 400 은 어떻게 부 었 습 니까?
  자세히 살 펴 보 니 400 오류 가 발생 한 이전 방문 한 User - agent 는 모두 Google Chrome 브 라 우 저가 남 긴 것 으로, 즉 400 오 류 는 Chrome 브 라 우 저 에서 발생 한 것 이다.그러나 로 컬 스냅 백 을 통 해 chrome 은 서버 에 이상 요청 이나 패 킷 을 보 내지 않 은 것 으로 밝 혀 졌 다.
  스냅 백 분석 에서 크롬 이 서버 에 접근 할 때 시작 하 는 연결 은 하나 가 아니 라 보통 5 ~ 6 개가 다 르 며, 요청 한 자원 이 그렇게 많은 연결 이 필요 하지 않 을 경우 크롬 은 사용 하지 않 는 연결 을 닫 는 기술 을 pre - connection '사전 연결' 이 라 고 한다.
  보통 우리 가 한 사 이 트 를 방문 할 때 첫 번 째 로 얻 은 것 은 html 메 인 파일 이 고 그 안에 웹 페이지 에 필요 한 css, js, 이미지 등 다른 미디어 자원 파일 이 연결 되 어 있 습 니 다. 일반 자원 파일 과 메 인 html 파일 은 한 도 메 인 에 있 습 니 다. 미리 연결 하 는 것 은 html 를 얻 기 전에 많은 tcp 연결 을 하 는 것 입 니 다.html 파일 을 가 져 온 후에 서버 에 연결 하여 다른 파일 을 가 져 오 는 것 이 아니 라 서버 에 연결 하 는 데 시간 이 좀 걸 리 기 때문에 이 기술 은 웹 페이지 의 표현 속 도 를 어느 정도 가속 화 할 수 있다.
웹 페이지 html 링크 의 자원 이 비교적 적 거나 클 라 이언 트 에 캐 시가 있어 서 다운로드 에 연결 할 필요 가 없다 면 크롬 브 라 우 저가 보 내 는 5 - 6 개의 연결 은 1 개 만 필요 할 수 있 고 다른 것 은 모두 꺼 야 한다. 그러면 문제 가 발생 한다. 서버 에 연결 되 어 아무런 요청 도 보 내지 않 았 다.이러한 상황 에 대해 nginx 는 400 오류 로 처리 되 었 으 나 연결 이 닫 혔 기 때문에 오류 정 보 는 클 라 이언 트 에 전송 되 지 않 습 니 다. 이 로 인해 로그 파일 에 오 류 를 기록 하고 패키지 분석 에서 아무것도 볼 수 없 는 현상 이 발생 했 습 니 다.
테스트:
  위의 분석 결 과 를 검증 하려 면 간단 합 니 다. 명령 행 cmd. exe 를 열 고 telnet server rip 80 을 입력 하 십시오. 연결 이 성공 한 후에 cmd 를 끄 십시오. 이때 nginx 의 log 파일 에 400 오류 기록 이 하나 더 있 습 니 다.
한 마디 댓 글:
  pre - connection 의 장점 은 이미 잘 알 고 있 지만 단점 도 있 습 니 다. 만약 에 역장 이 최적화 되 어 Cookie - free 기술 을 사용 하거나 웹 페이지 와 정적 자원 이 서로 다른 서버 를 사용 하면 웹 페이지 에 필요 한 css, js 자원 은 주 html 와 같은 도 메 인 에 있 지 않 고 같은 IP 에 있 지 않 을 수도 있 습 니 다. 그러면 pre - connection 은 닭 갈비 뿐만 아니 라또한 주 html 서버 에 불필요 한 부담 을 줄 수 있 습 니 다.
이상 원문 은 다음 과 같 습 니 다.http://www.shily.net/topic/speaking-from-400-error-in-nginx-access-logs/
다른: telnet 127.0.0.1 80 에 도 유사 한 400 로그 가 나타 납 니 다.
access 로그 에서 400 을 지 우 는 방법:
0.7.12 이전 버 전의 nginx 는 빈 요청 을 받 았 습 니 다. nginx 는 어떠한 가상 호스트 와 도 일치 하지 않 고 400 오 류 를 되 돌려 줍 니 다.
다음 버 전 nginx 는 servername _;빈 요청 헤더 와 일치 합 니 다.
그래서 만약 에 낡은 버 전 을 0.7.12 이후 버 전 으로 업그레이드 하면...
업그레이드 후 기본 가상 호스트 server 를 추가 합 니 다.
기본 설정 파일, default. conf 를 추가 하고 nginx. conf 에 include 로 포함 합 니 다.

server {
  listen 80 default_server;
  server_name _;
  return 404;
  access_log off;
}