보통 사용하는 간단한 테스트 방법은, nginx가 챌린지 파일을 서빙하는 디렉토리에 확장자 없이 1234라는 이름의 파일을 만들고 그 안에 "5678"을 입력하는 것입니다. 만약 스마트폰의 브라우저에서 해당 파일에 접근할 수 있다면(자체 와이파이 대신 무선 데이터를 사용하는 경우), 일반적으로 Let’s Encrypt 인증 서버(주 서버 1개와 보조 서버 3개)도 해당 파일에 접근할 수 있을 것입니다.
다만 한 가지를 덧붙이자면, 동일한 정적 IP 주소 환경을 가진 두 번째 서버가 있습니다. 이 서버는 Discourse를 실행하지는 않지만, 다른 사이트들을 위해 Apache를 실행하고 있습니다(이제 certbot을 사용 중이라고 생각하는데, 확인해봐야 할 것 같습니다). 이 서버는 인증서를 정기적으로 문제 없이 갱신하고 있습니다.
외부 인프라 측면에서는 좋은 신호입니다. 오니언(Onion) 관점에서는 루트에서 Discourse 박스 안쪽으로, acme.sh 컨테이너까지 추적하고 있는 것입니다. 이 작업이 한동안 정상적으로 작동하다가 갑자기 실패했다는 점은 어떤 형태의 업데이트나 구성 변경이 원인이었을 가능성이 높다는 것을 시사합니다.
수동 파일 생성 및 액세스 테스트를 해보신 후 알려주세요. 보통 매우 신뢰할 수 있는 검증 방법입니다.
이 도구를 사용하여 응답을 확인하는 것도 좋습니다:
주소는 다음과 같은 형식이어야 합니다:
http://yourdomain.com/.well-known/acme-challenge/1234
휴대전화에서 수동 파일 1234를 테스트하는 것과 https://redirect-checker.org/ 사용이 모두 정상적으로 작동한다면, ACME 클라이언트 프로세스에 사용되는 스크립트/파라미터가 문제의 원천임을 명확히 알 수 있습니다.
빙고! 문제가 해결되었습니다. 근본 원인은 디스코urs 포럼과 연결된 단일 IP 주소를 제공하는 터널을 통한 불안정한 연결이었습니다. 외부 사이트를 포함한 다른 사이트들을 통한 테스트에서는 이 문제가 드러나지 않았지만, 당신이 추천한 모바일 테스트(생각해 보았어야 했는데, 그동안 수많은 테스트를 진행하다 보니 이번에는 그 생각이 나지 않았습니다)를 수행했을 때 성능 문제가 실제로 확인되었습니다. 이 문제는 Let’s Encrypt가 사용하던 경로를 통해 인증서 갱신이 완료되지 못할 정도로 심각했습니다. 터널이 원인으로 지목된 후에는 해결이 간단했고, Discourse 앱을 재빌드하자마자 갱신된 인증서가 즉시 적용되어 완전히 정상적인 운영 상태로 돌아왔습니다. Jonathan님과 모두에게 감사드립니다. 새해 복 많이 받으세요!
훌륭합니다!
이렇게 빨리 해결되어 기쁩니다!
새해 복 많이 받으세요!
