Nginx

Nginxエラーページのダークモード対応、賛成10対1の投票後も1年以上放置

Nginxエラーページへのダークモード対応が、コミュニティ投票で10対1の支持を得ながら1年半放置されている。変更はmetaタグ1行。Nginx自身が2021年に別のページへ同じ仕組みを適用済み。

岬徹

2026年8月22日 10:3800

1行のmetaタグが通らない

Nginxのデフォルトエラーページは、白地に黒文字のシンプルなHTMLで構成されている。404や502といったHTTPエラーが発生すると、ブラウザにはこの素朴なページが表示される。OSやブラウザでダークモードを使っている場合でも、このページだけは真っ白なまま画面に現れる。

2025年3月、anvmeというユーザーがNginxの公式リポジトリにPR（プルリクエスト、コードの変更提案）#567を提出した。変更内容は<meta name="color-scheme" content="light dark">というmetaタグを1行追加するもので、これによりブラウザがユーザーの配色設定に応じてエラーページの背景色を自動的に切り替えるようになる。

ダークモードを使っていれば暗い背景に、ライトモードならこれまで通り白い背景に表示される。このmetaタグはWHATWGのHTML仕様で定義されている標準的な仕組みで、非対応のブラウザは単にこのタグを無視する。既存の動作が壊れることはない。

9日後の3月17日、Nginx開発者のArut氏がPRをクローズした。

理由は短かった。「デフォルトエラーページはシンプルであるべき。気に入らなければerror_pageディレクティブで独自のページを設定すればよい」

このコメントには👎175に対して👍28という反応が付いた。

Nginxダークモード対応の経緯

2021年8月

welcomeページにダークモード対応を追加

Cソース内のエラーページ（404等）は対象外

2024年2月

コミット作者がNginxを離れフォーク

ドゥニン氏、F5との対立でFreenginxを立ち上げ

2025年3月

PR #567提出

エラーページへのmetaタグ1行追加を提案

3月17日

開発者が却下

理由は「シンプルさを保つため」

3月19日

議論過熱でロック、公式投票を開始

F5社員が賛否を問う投票ページを作成

〜6月

賛成591、反対60。返答なし

投票結果への回答を求める声にも沈黙

2026年8月

進展なし

公式回答なし。PRはクローズ・ロックのまま

※投票数は2026年8月時点。PRの変更内容はmetaタグ1行の追加

投票、そして沈黙

PRのクローズ後、コミュニティの反発は拡大した。PRのコメント欄には74件の議論が集まり、20人が参加。議論は過熱し、Nginxチームは3月19日にスレッドをロックした。

同日、F5社（Nginxの親会社）の従業員であるMaryna-f5氏が、GitHub Discussions上に投票ページを作成した。ダークモード対応の賛否を問う単純な投票で、ロックされたPR上での議論に代わる公式のフィードバック手段として設けられた。

結果は圧倒的だった。賛成（👍）が591に対して反対60。およそ10対1の比率で賛成が上回った。

ところが、この投票の後に何も起きなかった。

2025年6月5日、投票を受けた結論の公開を求める投稿が立てられた。Nginx開発者からの回答はない。同月27日には、PR提出者のanvme自身が改めてマージの検討を求めた。開発者側からの反応は、やはりなかった。

2026年8月に至るまで、投票結果に対する公式な回答も、PRの再検討も行われていない。元のPR #567はクローズ・ロックされたまま残っている。

すでにやっていた

ここで見落とされがちな事実がある。

2021年8月、当時Nginxの中心的な開発者だったMaxim Dounin（マクシム・ドゥニン）氏が、Nginxのwelcomeページ（index.html）と50xエラーページ（50x.html）にhtml { color-scheme: light dark; }というCSSを追加するコミットをマージしている。PR #567と同じ仕組みで、目的も効果も同じ。ドゥニン氏は2024年にF5との運営方針の対立からNginxプロジェクトを離れ、フォークであるFreenginxを立ち上げている。

ではなぜ404ページには適用されないのか。

技術的な理由がある。welcomeページと50xページはdocs/html/に格納された静的HTMLファイルで、Nginxのインストール時にそのまま配置される。一方、404や403といったHTTPエラーページはCソースコード（ngx_http_special_response.c）に直接埋め込まれており、ソフトウェアのビルド時にバイナリへ組み込まれる。同じ変更を適用するには、静的ファイルの編集ではなくCコードの修正が必要になる。

PR #567が提案していたのは、まさにそのCコードへの修正だった。

ユーザーから見れば、welcomeページの「Welcome to nginx!」も、404エラーの「Not Found」も、見た目はほぼ同じ素朴なHTMLページに映る。片方がダークモードに対応し、もう片方が対応しないことに技術的必然性はあっても、「シンプルさ」という却下理由との整合性は取りにくい。Nginx自身が2021年に「シンプルさを損なわない」と判断した事実が、3年半後の却下理由と矛盾している。

閉じたドア

この問題は、Nginx単体のバグレポートの枠を超えて広がっている。Linuxディストリビューションの一つであるDebianでは、本家Nginxが却下したパッチをDebian側で独自に適用するよう求めるバグ報告が提出された。PR #567の提出者anvmeは、もう一つの主要ウェブサーバーであるApache httpdにも同様のPRを出している。Nginxのバグ追跡システムにはチケット#2434として、エラーページ全体へのダークモード拡張が要望されている。

問題の核はダークモードそのものではない。コミュニティが手順を踏み、投票で明確な支持を示し、技術的な反論もないまま1年以上放置されている、というプロセスの断絶にある。

Nginxは世界のウェブサイトの大きな割合を支えるインフラであり、F5 Networks社が開発を主導している。オープンソースプロジェクトのメンテナが変更を拒否する権限を持つこと自体は健全な仕組みで、すべてのPRがマージされるべきではない。だが、自らが設置した投票の結果に対して説明すら行わないのは、権限の行使とは呼べない。

metaタグ1行の話に1年半を費やしている。技術的に解決済みの問題を、誰が、なぜ止めているのか。その説明が出てくる気配は、今のところない。