재 미 있 는 Ngin x 선 에 오 류 를 적어 주세요.

현상.

두 서버 에 nginx 한 대 를 부하 균형 이 높 은 데 사용 할 수 있 도록 설정 하 였 으 나, nginx 를 통 해 데 이 터 를 요청 할 때, 매번 첫 번 째 서버 에 전 화 를 걸 때마다 오 류 를 보고 하고, 두 번 째 서버 는 문제 가 없 음 을 발견 하 였 다.

그러나 모든 서버 의 인 터 페 이 스 를 단독으로 호출 하면 정상적으로 데 이 터 를 얻 을 수 있다.

조사 과정

[첫 번 째 단계: 네트워크 문제 인지 아 닌 지]

nginx 에서 ping 과 telnet port 를 통 해 네트워크 와 포트 가 통 하지 않 는 지 확인 하고 두 대의 서비스 와 nginx 의 방화벽 이 모두 개통 되 었 는 지 확인 합 니 다.

결 과 는 모두 통 했다.

[두 번 째 단계: 기계 적 원인 인지 확인]

부하 균형 을 한 대의 역방향 대리 로 바꾼다.결 과 는 1 대 는 여전히 안 되 고 2 대 는 문제없다.

대략 1 대의 일부 배치 와 관계 가 있다.

[세 번 째 단계: 가방 을 잡 아 데이터 가 도 착 했 는 지 확인 하고 차이 점]

각각 서버 에 Wireshark 스냅 백 을 설치 한 결과 nginx 에서 온 요청 은 postman 의 token 을 제외 하고 모두 같 지만 두 기계 의 response 가 다 르 기 때문에 첫 번 째 는 error 정 보 를 영원히 출력 하고 두 번 째 는 성공 적 인 정 보 를 영원히 출력 합 니 다.첫 번 째 error 정 보 를 보 세 요. 권한 인증 과 관련 이 있 는 것 같 습 니 다.

첫 번 째 권한 인증 과 관련 이 있 을 것 으로 추정 된다.

[네 번 째 단계: nginx 의 error. log 보기]

유용 한 정 보 를 찾 지 못 했다.

[다섯 번 째 단계: 회사 의 사내 에 게 도움 을 청 합 니 다]

세 션 이 유지 되 는 원인 이 아 닌 지 추측 하여 nginx 의 설정 파일 을 수정 하 였 으 며, 그 중에서 upstream 의 배분 알고리즘 은 ip 로 수정 되 었 습 니 다.hash。

이전에 패키지 에서 도 nginx 를 통 해 전 송 된 메시지, connection: close 를 발 견 했 고 직접 호출 된 메시지 의 connection = keep - alive 를 발 견 했 기 때문에 링크 를 유지 하지 않 아 인증 에 실 패 했 음 을 의심 할 이유 가 있다.

문 제 를 성공 적 으로 해결 하고 테스트 할 때 매번 데 이 터 를 성공 적 으로 얻 었 다.

후기

5 분 후에 집에 돌아 오 는 길에 제 가 틀 렸 다 고 생각 합 니 다. 이 문 제 는 해결 되 지 않 았 습 니 다. 왜냐하면 iphash 알고리즘 은 같은 ip 이 같은 백 엔 드 에 매 핑 되 고 세 션 을 유지 하도록 하 는 것 입 니 다. 제 가 테스트 할 때 이 컴퓨터, 같은 ip 입 니 다. 다행히 저 는 두 번 째 데스크 에 매 핑 되 었 기 때문에 매번 요청 이 성공 적 입 니 다.

오늘 계속 검증 할 때 기계 한 대 를 바 꾸 어 요청 을 보 냈 는데 과연 실 패 했 습 니 다. 사후에 제갈량 이 세 가지 확실한 증 거 를 발 견 했 습 니 다.

전에 단독 대리 1 대도 성공 하지 못 했 기 때문에 세 션 유지 의 원인 일 수 없습니다

nginx 를 통 해 리 트 윗 할 때 두 기계 의 메 시 지 는 모두 connection: close 이기 때문에 세 션 이 유지 되 는 이유 라면 한 대 는 통 하지 않 고 한 대 는 통 하지 않 습 니 다.

퍼 가기 알고리즘 을 ip 로 수정 하 였 습 니 다.hash 이후 스냅 백 을 통 해 메 시 지 는 여전히 connection: close 이 고 nginx 는 응답 머리 에 Keep - Alive 를 추가 할 수 없습니다. nginx 는 http 1.0 프로 토 콜 을 사용 하기 때문에 이 럴 수 없습니다.nginx 가 책임 지지 않 는 세 션 유지 체제 에 대해 서 는 Nginx 세 션 유지

를 참조 하 십시오.

잘못된 보고 정 보 를 반복 적 으로 본 후에 회사 의 큰 사내 가 나 에 게 nginx 의 http 를 tcp 로 전환 해 보라 고 건의 한 결과 반복 적 인 테스트 를 통 해 이번 이 정말 성공 한 것 임 을 확인 했다.

http{
     
    upstream tomcat_pool{
     
        #server tomcat  :    weight    ，    ，        ;
        server 192.168.80.22:8080 weight=4 max_fails=2 fail_timeout=30s;
        server 192.168.80.22:8081 weight=4 max_fails=2 fail_timeout=30s;
    }
    server {
     
        listen       80;
        server_name  tomcat_pool;
        location / {
     
            #root   html;
            #index  index.html index.htm;
            proxy_pass http://tomcat_pool;    #  tomcat  
            proxy_set_header   Host             $host;
            proxy_set_header   X-Real-IP        $remote_addr;
            proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;
        }
}

바꾸다

stream {
     
    upstream rtmp {
     
        server 127.0.0.1:8089; #            
        server 127.0.0.2:1935;
        server 127.0.0.3:1935; #       ，         RTMP     1935
    }
    server {
     
        listen 1935;  #        
        proxy_timeout 20s;
        proxy_pass rtmp;
    }
}

주의: nginx 를 다시 컴 파일 해 야 합 니 다. 추가: – with - stream, 그리고 make & make install.

http 는 세 션 유지 가 필요 하고 인 증 된 token 을 가 져 가 야 합 니 다. nginx 의 tcp 를 통 해 백 엔 드 기기 에 전송 하고 백 엔 드 기기 에서 인증 정 보 를 구축 해 야 합 니 다. nginx 는 tcp 요청 만 전달 하고 응용 층 에서 정 보 를 처리 하지 않 습 니 다.

조사 방향: nginx 의 역할 을 낮 추고 퍼 가기 만 하면 http 층 에서 tcp 층 으로 강등 된다.

현상

nginx 를 사용 하여 부하 균형 을 이 루 는 두 서버 의 다른 서 비 스 는 모두 방문 할 수 있 습 니 다. 특정한 서비스 만 방문 할 수 없 지만 nginx 를 돌아 서 는 단독 방문 할 수 있 습 니 다.

해결 방법:

상기 방법 을 시험 해 본 결과 nginx 가 전송 하 는 포트 가 점용 되 었 다.점용 한 이 서 비 스 는 비교적 일찍 시작 되 었 기 때문에 후속 재 시작 서 비 스 를 할 때 잊 어 버 렸 습 니 다. 이 포트 는 8888 이 라 고 하 는데 여러분 은 이런 특수 포트 를 사용 하지 마 세 요.