두 서버 에 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 로 전환 해 보라 고 건의 한 결과 반복 적 인 테스트 를 통 해 이번 이 정말 성공 한 것 임 을 확인 했다.
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 이 라 고 하 는데 여러분 은 이런 특수 포트 를 사용 하지 마 세 요.
이 내용에 흥미가 있습니까?
현재 기사가 여러분의 문제를 해결하지 못하는 경우 AI 엔진은 머신러닝 분석(스마트 모델이 방금 만들어져 부정확한 경우가 있을 수 있음)을 통해 가장 유사한 기사를 추천합니다:
