nginx proxy_pass로 Discourse 컨테이너로 포워딩 및 Discourse에서 호스트 서버로의 링크

Discourse 팀,

호스트 머신에서 nginx 서버를 실행 중이고, Docker에서 꽤 표준적인 Discourse 컨테이너를 구동하고 있습니다. 기본적으로 호스트 nginx가 제공하는 특정 (http) 폴더가 몇 개 있고, 나머지는 모두 proxy_pass를 통해 Discourse 컨테이너로 전달됩니다.

제가 이해한 문제의 핵심을 요약하자면, 호스트 nginx 설정 파일에 호스트 nginx가 처리하는 location /xyz가 정의되어 있고, 그다음 location /이 Discourse 컨테이너로 proxy_pass되도록 정의되어 있다는 것입니다.

제 사용 사례에서는 Discourse 게시글에 my.domaiin.com/xyz/some.html과 같은 링크를 게시해야 합니다. 즉, Discourse 내부의 링크가 호스트 nginx가 제공하는 페이지를 가리키고 있습니다.

이것은 마지막 Discourse 업데이트까지 잘 작동했습니다. 그런데 이제 링크를 클릭하면 Discourse의 “찾을 수 없음…” 페이지로 이동합니다. 반면, 링크 주소를 복사하여 새 탭에서 열면 정상적으로 작동합니다.

저는 저위 프로토콜에 대해 꽤 잘 알고 있지만, 프로토콜 스택이 올라갈수록 아는 것이 적어집니다 :slight_smile:
현재 작동하는 가설은 Discourse의 nginx가 연결을 열어두는 것(keepalive?) 때문에, 호스트 nginx가 새로운 요청 경로를 분석하여 올바른 서버를 선택할 기회를 놓친다는 것입니다. 연결이 유지되는 동안 요청은 그대로 컨테이너로 전달됩니다. 그러면 /xyz 경로에 대한 요청은 이 폴더를 모르는 Discourse에 의해 응답됩니다..

이 문제를 어떻게 접근해야 할까요? 간단한 해결책이 없다면, 몇 가지 방향만 제시해 주셔도 도움이 될 것입니다. 적당 수준의 http 프로토콜 지식을 전제로 한 좋은 설명만이라도 도움이 될 것입니다.

감사합니다!

추가 참고 사항: 만약 이것이 실제로 keep-alive 문제라면, keep-alive를 비활성화하고 일부 비용 오버헤드를 감수하는 데 전혀 문제가 없습니다. 이 설치 환경은 대량의 사용자를 처리하기 위한 것이 아닙니다.

생각해보니, 호스트의 nginx도 이름이 지정된 파이프(named pipe)를 경청하도록 설정하고, 이 파이프를 Discourse 컨테이너에 노출한 뒤, Discourse의 nginx 설정에 커스텀 폴더 /xyz를 추가하여 새로 생성된 파이프를 통해 proxy_pass하도록 해야 할 것 같습니다. (호스트 nginx가 먼저 시작되지 않으면 docker-compose가 이름이 지정된 파이프를 제대로 노출하지 않기 때문에, 이러한 세부 사항들을 먼저 해결해야 합니다.)

그래도 도움이 된다면 감사하겠습니다 :wink:

이는 Ember.JS 라우터가 Discourse 애플리케이션이 지원하는 전체 경로 목록을 알고 있기 때문이며, 서버에 해당 콘텐츠가 없다는 것을 알고 있어 404 페이지가 클라이언트 사이드에서 렌더링됩니다.

파일을 다른 서브도메인에 배치하세요.