こんにちは。インストールしようとすると、「推奨」でビットがリストされているところで「500エラー」が表示されます。
プレビューに移動すると、ページの中央に次のように表示されます。
これはなぜでしょうか？
サービスへの接続が実際には拒否されていると推測しますが、なぜでしょうか。
それは正しいリンクではないようです。OPのリンクを使用すると問題なく動作するはずです - GitHub - discourse/discourse-custom-header-links
どこからそのリンクをインストールしようとしていたか教えていただければ、更新できるかどうか確認します。
git – GitHub - discourse/discourse-custom-header-links で試すと、「500エラー」が同じように発生します。
うーん。 
私の方では（「人気」セクションからも、リンク「https://github.com/discourse/discourse-custom-header-links」を貼り付けても）正常に動作しているようです。
代わりに、OPの「このテーマコンポーネントをインストールする」ボタンを試していただけますか？
それを実行することはできません。私のサイトはテストラボであり、公開アクセス可能でなければならないと理解していますが、正しいですか？
すべて正常に動作しているようです。sidekiq には、明白なエラーや警告はありません。
その他のビット、例えばカテゴリバナーなどは、popular okey を介してインストールされました。
バージョン 3.0.5 / 461966e028
zip を試してみます。
「いいね！」 1
参考までに、最新の stable バージョンは 3.1 であり（tests-passed は少なくとも 3.2.0.beta1-dev です）、アップグレードが必要だと思います。
「いいね！」 1
それが完了したかどうかはわかりませんが、コンテナの破棄と作成が完了したのかもしれません。しかし、バージョン3.0.6に更新された現在、DiscourseはCHLをpopular経由でインストールできます。
「いいね！」 1
すべてのテーマやコンポーネントで、このエラーが引き続き発生します。
「プレビュー」に移動すると、ポップアップと「テーマを表示」ボタンが表示され、「https://discourse.theme-creator.io/c/discourse/1」にたどり着くのですが、これらの機能は動作しますか？
Discourse はどのようにインストールしましたか？標準的なインストールですか？現在のバージョン 3.1 にアップグレードしましたか？
はい。ちなみに、「standard」インストールで開発版（私の環境では 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 プロキシが原因である可能性はありますか？（すべて正常に動作しているように見えます）
コンテナ内から、500 エラーで失敗するコンポーネントの URI を curl することはできます — 問題なく動作します。
これらの部分について、より詳細なデバッグ情報を取得する方法はありますか？
zip 経由でインストールされたコンポーネントは正常に動作しているようです。
はい、デフォルトブランチは「テスト済み」です（Understanding Discourse release channels も参照）。
「dev」サフィックスは最近追加されました。
From Discourse 3.2: adding -dev suffix to beta versions under active development
「いいね！」 1
パフォーマンスの問題かもしれません。RAMは十分ですか？CPUをすべて消費している他のものがありますか？
そうは思えません。4コア8GBのRAMで、インストールしたばかりのラボです。Discourseがそのように失敗したまさにその瞬間、コンテナ内で同じURIにcurlできます。
ここで役立つのは、ログをより詳細/デバッグ可能にする方法を知ることだと思います。develがここにいるなら、それについてアドバイスしてくれるかもしれません。
tail -f /var/discourse/shared/standalone/log/rails/production.log
またはコンテナ内では
/shared/log/rails/production.log
これを振り返ってみると、Dockerの設定に問題があり、GitHubにアクセスできないのではないかと推測されます。しかし、標準的なインストールを行った場合、コンテナ内からプラグインをクローンしているはずなので、それがどのようにして起こりうるのかはわかりません。
これらは、以前に貼り付けたログです。もっと詳細で分かりやすいものにしていただけると幸いです。
また、前回のコメントで、コンテナ内でGitHub URIのコンポーネントのURIをcurlできると述べました。Dockerの設定が本当に問題であるとお考えですか？
「いいね！」 1
コンテナの再構築、ホストのDNSなど、いくつかの要因が考えられますが、現在は500エラーもなく動作しています。
「いいね！」 1