안녕하세요. 설치하려고 할 때, 해당 항목이 나열된 “권장” 섹션에서 "500 error"가 발생합니다.
미리 보기로 이동하면 페이지 중앙에 다음이 표시됩니다:
이런 현상의 원인에 대해 조언을 주실 수 있을까요?
서비스에 대한 제 연결이 실제로는 거부되고 있는 것 같지만… 왜 그런지 모르겠습니다.
그 링크가 올바른 링크가 아닌 것 같습니다. OP(원포스트)의 링크를 사용하시면 정상적으로 작동할 것입니다 - GitHub - discourse/discourse-custom-header-links · GitHub
어디서 그 링크를 설치하려고 했는지 알려주시면, 해당 링크를 업데이트할 수 있는지 확인해 보겠습니다.
git로 시도해 보았지만 — GitHub - discourse/discourse-custom-header-links · GitHub
같은 "500 오류"가 발생합니다
음. 
내 환경에서는 정상적으로 작동하는 것 같습니다(‘인기’ 섹션에서도, https://github.com/discourse/discourse-custom-header-links 링크를 붙여넣어도 마찬가지입니다).
대안으로 OP의 ‘이 테마 컴포넌트 설치’ 버튼을 눌러보시겠어요?
제가 제 사이트를 이해하는 바로는, 이 사이트가 테스트 랩이므로 공개적으로 접근 가능해야 하는 것 아닌가요?
모든 것이 정상적으로 작동하는 것 같습니다. sidekiq도 문제없고, 눈에 띄는 오류나 경고도 없습니다.
카테고리 배너 같은 다른 부분들은 popular 플러그인으로 정상적으로 설치되었습니다.
버전: 3.0.5 / 461966e028
zip으로 시도해 보겠습니다
참고로, 최신 stable 버전은 3.1이고(tests-passed는 최소 3.2.0.beta1-dev) 업그레이드가 필요할 것 같습니다. 
그것이 해결책이었는지 확신은 없지만, 컨테이너를 삭제하고 다시 생성한 것이 효과를 본 것 같습니다. 어쨌든 3.0.6 버전으로 업데이트한 후, Discourse는 이제 popular를 통해 CHL을 설치할 수 있습니다.
이제 모든/어떤 테마와 컴포넌트에 대해 계속 그 오류가 발생합니다.
이것들이 제대로 작동하는 건지 묻고 싶은데요 — "미리보기"를 가려고 하면 팝업과 “View Theme” 버튼이 표시된 Theme Creator 로 리디렉션됩니다. 이 버튼을 클릭하면 ‘discourse - Theme Creator’ 로 이동하게 됩니다.
디스코urs를 어떻게 설치하셨나요? 표준 설치인가요? 현재 3.1 버전으로 업그레이드하셨나요?
네. 참고로 - “standard” 설치 환경에서 dev 릴리스(제 환경에서는 3.2.0.beta1-dev로 표시됨)가 포함되는 것이 정상인가요?
일부 로그에서 다음 내용을 확인했습니다:
…
Processing by Admin::ThemesController#import as */*
Parameters: {"remote"=>"https://github.com/discourse/discourse-category-banners"}
Rendered text template (Duration: 0.0ms | Allocations: 1)
Completed 418 in 2ms (Views: 0.4ms | ActiveRecord: 0.0ms | Allocations: 1273)
Failed to process hijacked response correctly : Timeout::Error : Timeout::Error
호스트/노드 외부에 Nginx 프록시가 있는 것이 이 문제와 관련이 있을까요? (모든 기능이 정상적으로 작동하는 것으로 보입니다)
컨테이너 내부에서 curl을 사용하여 해당 URI에 접근하면 — 500 오류가 발생하는 일부 구성 요소의 view를 확인하는 경우 — 정상적으로 응답됩니다.
이러한 부분에 대해 더 자세한 디버그 정보를 얻을 수 있는 방법이 있을까요?
zip 파일로 설치된 구성 요소는 정상적으로 작동하는 것으로 보입니다.
네, 기본 브랜치는 “테스트 통과” 상태입니다(관련 링크: Understanding Discourse release channels).
“dev” 접미사는 최근에 추가되었습니다.
From Discourse 3.2: adding -dev suffix to beta versions under active development
성능 문제일 수도 있습니다. RAM이 충분한가요? 다른 프로세스가 CPU를 모두 차지하고 있나요?
그렇지 않다고 생각합니다. 4코어 8GB RAM을 사용하고 있으며, 방금 설치된 실험 환경(lab)이기 때문입니다. Discourse가 그런 방식으로 실패하는 바로 그 순간에, 컨테이너 내에서 동일한 URI를 curl로 요청하면 정상적으로 작동합니다.
여기서 도움이 될 것 같다고 생각하는 것은 로그를 더 상세하게/디버그 모드로 설정하는 방법을 아는 것입니다. devel 팀이 여기서 조언해 주실 수 있다면 좋겠습니다.
tail -f /var/discourse/shared/standalone/log/rails/production.log
또는 컨테이너 내부에서
/shared/log/rails/production.log
다시 살펴보니, 도커 설정에 문제가 있어 GitHub에 접근하지 못하고 있는 것으로 추정됩니다. 다만 표준 설치를 했다면 컨테이너 내부에서 플러그인을 클론했을 것이므로, 어떻게 그런 일이 일어날 수 있는지 정확히 확신은 하지 못하겠습니다.
이미 앞서 붙여넣은 로그들입니다. 이 로그들이 더 자세하고 유용한 정보를 제공하도록 개선될 수 있기를 여전히 희망합니다.
또한, 마지막 댓글에서 해당 컴포넌트의 GitHub URI를 컨테이너 내부에서 curl로 정상적으로 요청할 수 있다고 말씀드렸습니다. 말씀하신 도커 설정이 실제로 문제의 원인일 수 있다고 생각하시나요?
컨테이너 재빌드, 호스트 DNS 설정 등 여러 요인이 복합적으로 작용한 것 같습니다. 지금은 문제가 해결되어 500 에러가 더 이상 발생하지 않습니다.