로그인 실패 시 (즉, force_https=true일 때) 실행 중인 도커 컨테이너의 log/production.log에는 어떤 내용이 기록됩니까?
@RGJ – 당신의 해결책이 좋습니다! 마지막 제안에 따라 force-https를 사용해야 하나요? proxy_pass https에 대해 질문드립니다.
수정: proxy_pass https://192.168.86.108만 사용할 경우 502 오류가 발생합니다.
수정2: app.yml을 통해 Discourse에서 80 포트를 비활성화했지만 여전히 문제가 발생했습니다. 방금 당신의 게시글을 다시 읽어보니, Discourse 컨테이너가 자체 Nginx 인스턴스를 가지고 있는 건가요? 즉, 실질적으로 프록시를 프록시로 전달하는 구조인 건가요? 지금은 정말로 혼란스러운 상태입니다. 죄송합니다.
@itsbhanusharma 80:80 #http 주석을 처리하고 @RGJ의 조언대로 proxy_pass https를 사용해야 하나요?
여기서 멀티사이트에 대한 지원되는 프로세스를 따르지 않는 이유는 무엇인가요? 매우 취약한 수레바퀴를 다시 발명하는 것과 같습니다.
지금까지 너무 많은 링크가 제공되어서, @Stephen-- 이 모든 것을 어떻게 이해해야 할지 막막합니다. 저는 지원되는 프로세스를 따르고 있다고 생각했는데요. 위에 달린 댓글들은 지원되지 않는 건가요? 
네, force_https를 사용하지 않았기 때문에 위에서 unsupported-install 태그가 붙었습니다. 지원되는 설정에서 벗어나면 도움을 많이 받기 어렵습니다.
여기서 시작하세요:
멀티사이트 환경에서 SSL 캡슐화를 처리하는 별도의 가이드가 있습니다.
그렇다면 표준 컨테이너는 http만 실행하나요? 제가 하려는 작업이 어떻게 멀티사이트 방식인가요? 저는 여러 도메인을 호스팅하려는 것이 아닙니다. 단일 도메인만 사용하고 있습니다. 제 문제를 어떻게 해결하는지 명확히 설명해 주시겠습니까?
다음 문장에서 무엇을 의미하셨나요?
지금까지 약 5개의 인스턴스에서 Discourse 서버를 설정해 보았는데, 모두 이상한 동작을 보이고 있습니다. 실제로 버그인지, 아니면 다른 분들도 같은 경험을 하고 있는지 확실하지 않습니다.
서로 어떠한 연결도 없는 독립적인 인프라들입니다.
그러나 모두 위와 매우 유사한 설정을 사용하고 있습니다.
그렇다면 nginx가 왜 호스트를 프록시하는 것일까요? 해당 머신에서는 다른 어떤 일이 일어나고 있을까요?
외부에서 접근할 수 없는 VM이 여러 대 있습니다. 트래픽은 프록시(이는 외부에 노출되어 있음)를 통해 내부의 Discourse VM으로 라우팅됩니다. 각 독립 설치 환경에서도 상황이 비슷합니다. 이렇게 설명하면 더 명확해지나요?
별로 그렇지 않지만, 어쨌든 이는 감내해야 할 기술적 고통입니다. 사용 사례와 토폴로지가 너무 모호해서 더 나은 접근 방식이 있는지 평가하기가 불가능합니다.
적절한 *해결책의 조합은 다음과 같다고 생각합니다:
@itsbhanusharma 님의 말씀대로:
수정 /var/discourse/containers/app.yml 파일을 편집하여 포트를 커스텀 값으로 변경했습니다. 저는 다음을 사용했습니다:
- "8080:80" #http
- "4343:443" #https
./launcher rebuild app을 실행했습니다.
이후 외부에서 접근 가능한 프록시를 수정하여 80/443 포트로 들어오는 요청을 http://internal_ip:8080으로 전달하도록 했습니다.
sudo nginx -t와 sudo systemctl restart nginx를 실행한 후, https://discourse.mobiusnode.io 서버(아직 위에서 언급한 문제가 발생하고 있던 상태)에 로그인하여 force_https를 활성화했습니다. 그 시점에 모든 것이 정상적으로 작동하는 것으로 보입니다.
이제 나머지 서버/인프라에서도 이 설정을 재현할 예정입니다.
정확히 말씀드리자면, 제가 제안한 내용은 아닙니다.
저는 로컬 IP에서 포트 80을 노출하고 리버스 프록시에서 SSL을 종료해 달라고만 요청했습니다.
즉, 외부로 노출된 프록시에는 SSL을 사용하지 않고, 대신 평문 http 요청을 Discourse 서버로 전달한 뒤 force_https가 해당 요청을 처리하게 하는 것이 맞나요? 그렇다면 인증서는 어떻게 전달되나요? 첫 번째 Nginx 인스턴스를 통해서인가요? 여기서부터는 제가 이해가 되지 않습니다.
글쎄, 제대로 작동하고 깔끔하게 재구축/업그레이드할 수 있다면 괜찮죠. @itsbhanusharma 님이 최근 게시물에서 제안한 것을 이미 하고 계신 것 같습니다.
단일 IP로 여러 SSL 연결을 공유하는 경우, 프록시 프론트엔드에는 SAN 인증서가 필요합니다. 네트워크가 안전하다면, 그 뒤의 모든 트래픽은 암호화되지 않아도 됩니다.
사용자가 SSL을 통해 연결하는 경우 Discourse에는 force_https가 필요하며, 위에서 언급된 헤더가 보존되고 전달되도록 확인해야 합니다.
아니요, SNI라는 것이 있습니다.
그 점은 충분히 인지하고 있습니다. 하지만 인증서가 모두 Let’s Encrypt에서 발급되는 상황에서, 개별 인증서를 요청하는 것이 어떤 가치가 있는지 궁금합니다. LE는 SAN을 지원하니까, 왜 사용하지 않는 건가요?