nginx -t 검사 통과는 웹사이트가 열린다는 것을 의미하지 않습니다. 우리는 전 사이트가 사용 불가능해지는 사고를 한 차례 겪었습니다: 문법 검사는 모두 정상이었지만, 정확한 location 지시어의 301 리다이렉션과 try_files 지시어가 서로를 반복적으로 리다이렉션하여 브라우저에서 "리다이렉션 횟수 초과" 오류를 직접 보고했습니다. 이 도구는 두 가지를 제공합니다: 첫째, 주석에 모든 함정을 명시한 nginx 구성 파일 기본 틀; 둘째, 단순한 문법 검사가 아닌 HTTP 상태 코드와 리다이렉션 횟수까지 확인하는 실제 HTTP 자체 점검 스크립트.
한 줄에 하나씩. 홈페이지는 반드시 포함되어야 하며, 2차 페이지는 최소한 각각 하나씩 포함되어야 합니다.
—
—
1 · 정확한 location + 301로 인해 무한 루프가 발생합니다.작성하세요 location = /path { return 301 …; }, 그리고 try_files 요청을 다시 동일한 location으로 내부 리디렉션하면 브라우저가 "리디렉션 횟수가 너무 많음" 오류를 표시하고 전체 사이트가 열리지 않습니다.nginx -t 완전히 파악할 수 없습니다.
2 · 장기 캐시 + 버전 번호 없음 = 수정 사항이 "적용되지 않은 것처럼 보임".동일한 실수를 세 번 반복했습니다(CSS 두 차례, JS 한 차례). 규칙은 간단합니다:expires를 설정했다면, CSS/JS에도 반드시 적용해야 합니다. ?v=; 한 번 수정하면 한 번 버전 업그레이드합니다.
3 · <base href>는 모든 상대 경로 리소스 이전에 반드시 위치해야 합니다.에 작성됨 <link> 그 후, 2차 페이지가 CSS를 잘못된 디렉터리로 해석하여 스타일이 조용히 무효화됩니다—1차 페이지에서는 전혀 확인할 수 없습니다.
4 · 백엔드 데이터는 basic auth 뒤에 배치하여 fetch로 사용하지 마십시오.브라우저가 하위 요청의 자격 증명을 캐시하는 방식은 제어할 수 없으며, 페이지는 항상 "로딩 중" 상태에 머무릅니다. "페이지 로그인 + 데이터에 키 매개변수 포함" 방식으로 변경하세요.
5 · 로컬 프록시에서 가짜 경고 발생사이트 온라인 여부를 판단할 때는 항상 이 점을 확인 --noproxy '*'; 우리는 프록시가 반환한 410 응답을 잘못 "사이트 다운"으로 판단했으나, 실제 응답은 200이었습니다.