2026/06/26(金)nginxに未定義のホスト名で要求が来たときにエラーを返せるようにした

更新日:
投稿日:

nginxのバーチャルホストを増やしたり減らしたりしていて未定義のドメインにアクセスしたとき、最も若い設定ファイルに飛ばされることに気づいた。

これだと未定義のバーチャルホストを叩いたときに変なところに飛んでいくので、エラーにするようにした。

起きていた現象

git.lycolia.infoの設定をnginxから削除し、DNSにレコードが残っている状態でhttps://git.lycolia.infoを叩くと他の特定のドメインでホストしているサイトに飛ばされる状態になっていた。

例えば/etc/nginx/conf.d/access-analizer.confがあるとした場合、未定義の任意のドメイン名を叩くと、この設定ファイルで定義した場所が表示される状態だった。リダイレクトなどはなく、URLそのままで表示される感じ。

確認環境

  • nginx/1.26.1

対処方法

/etc/nginx/conf.d/default.confなど、適当に設定ファイルを作って次の設定を記述すると対処できる。

server {
  listen 80 default_server;
  listen 443 ssl default_server;
  listen [::]:80 default_server;
  listen [::]:443 ssl default_server;

  ssl_reject_handshake on;

  return 444;
}

default_serverと書くと、未定義のホストに対するアクセスがすべてここに吸収される。

server_name ""にしておくとIP直打ちのアクセスもトラップできるらしいが、手元で確認した感じは、あってもなくても機能するように見えたので付けていない。

ssl_reject_handshake onにしておくことで、未定義のホストに対してHTTPSでアクセスしてきたときに、ハンドシェイクをせず突き返す事ができるようだ。わずかではあるもののサーバーの負荷やネットワークのトラフィックが抑えられそうだ。

以下のようにlisten443sslをつけなくても同じように動いたが、違いはよく分かっていない。

server {
  listen 80 default_server;
  listen 443 default_server;
  listen [::]:80 default_server;
  listen [::]:443 default_server;

  ssl_reject_handshake on;

  return 444;
}

余談がうちのサーバーは外向きに80番ポートを開けていないので、80に対して制御を入れているのはもっぱらローカル用だ。開発環境を増減させてる時に変なところに繋がると面倒なので入れている。

検証結果

この設定をしたことで次のようなHTTP要求をすべてエラーで返せるようになった。

curl -H "Host:hoge.lycolia.info" "https://[2400:4153:8f01:c800:c14b:3f7a:2b54:353a]"
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 unrecognized name

curl "https://[2400:4153:8f01:c800:c14b:3f7a:2b54:353a]"
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 unrecognized name

curl -H "Host:hoge.lycolia.info" "https://180.33.219.150"
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 unrecognized name

curl "https://180.33.219.150"
curl: (35) error:14077458:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 unrecognized name

但しhttpスキーマにして443ポートに投げるとHTMLが返ってくるようだった。まぁ別にいいかと思ったが、サーバーのバージョンが出てると微妙な気がしたのでserver_tokens off;/etc/nginx/nginx.confに足しておいた。記事で明かしているとはいえ、悪意のあるBOTが機械的に叩いてきたときに見られると余りよくない。

curl -H "Host:hoge.lycolia.info" "http://[2400:4153:8f01:c800:c14b:3f7a:2b54:353a]:443"
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx/1.24.0 (Ubuntu)</center>
</body>
</html>

curl "http://[2400:4153:8f01:c800:c14b:3f7a:2b54:353a]:443"
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx/1.24.0 (Ubuntu)</center>
</body>
</html>

curl -H "Host:hoge.lycolia.info" "http://180.33.219.150:443"
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx</center>
</body>
</html>

curl "http://180.33.219.150:443"
<html>
<head><title>400 The plain HTTP request was sent to HTTPS port</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<center>The plain HTTP request was sent to HTTPS port</center>
<hr><center>nginx</center>
</body>
</html>

おまけで80番を叩いて見たらそもそも繋がらなかった。ルーターで塞いでるのでnginxに届いていない。

curl -H "Host:hoge.lycolia.info" "http://[2400:4153:8f01:c800:c14b:3f7a:2b54:353a]"
curl: (7) Failed to connect to 2400:4153:8f01:c800:c14b:3f7a:2b54:353a port 80 after 4 ms: 接続が拒絶されました

curl "http://[2400:4153:8f01:c800:c14b:3f7a:2b54:353a]"
curl: (7) Failed to connect to 2400:4153:8f01:c800:c14b:3f7a:2b54:353a port 80 after 8 ms: 接続が拒絶されました

curl -H "Host:hoge.lycolia.info" "http://180.33.219.150"
curl: (7) Failed to connect to 180.33.219.150 port 80 after 7 ms: 接続が拒絶されました

curl "http://180.33.219.150"
curl: (7) Failed to connect to 180.33.219.150 port 80 after 6 ms: 接続が拒絶されました

あとがき

HTTPステータスコードに444なんてあったっけ?と思ったらnginxの特殊コードの様で、このコードが指定されるとnginxはレスポンスを返さず、その場でTCPコネクションを切るらしい。

前述のdefault_serverのマニュアルを読み返すと軽く触れられていることに気がついたのでドキュメントを漁ったら根拠が出てきた。

公式ドキュメントのreturnに以下のようにあるため、コネクションを閉じ何も返さないという事は間違いなさそうだ。

Stops processing and returns the specified to a client. The non-standard code 444 closes a connection without sending a response header. code

あとがきのあとがき

80に対して設定するとnginx_exporterにホスト名を指定できない関係上、上手くいかなくなるので80向けの設定は後日外した。

恐らくstub用のvhostにsocketを指定してnginx_exporterから読めるようにしたらいい気はするのだが、面倒なのでそれはまた今度やろうと思う。

2026/06/25(木)自宅サーバーの一部がダウンしたが監視を入れていてよかった話

仕事を終えて自分のサイトを見ると一部がダウンしておりGrafanaを見てみたらディスク使用率が100%になっていた。Mastodonがダウン、Grafanaも不安定な状態だった。

Prometheusのsyslog集めが強すぎてストレージパンクしたかな?と思ってPrometheusを止めてみたが効果はなかった。

ディスク占有しているやつを探す

ひとまずディスクを占有している主を突き止めるため、ディレクトリ単位の容量を出して突き止めることにした。犯人はForgejoだった。

犯人探しに使った軌跡

sudo du -xh --max-depth=1 /
sudo du -xh --max-depth=1 /var
sudo du -xh --max-depth=1 /var/lib
sudo du -xh --max-depth=1 /var/lib/forgejo
sudo du -xh --max-depth=1 /var/lib/forgejo/data
sudo du -xh --max-depth=1 /var/lib/forgejo/data/repo-archive

一次対応としてForgejoへの外部アクセスを遮断

取り敢えずForgejoが攻撃されてると面倒だなと思い、nginxの設定を書き換えてForgejoへの外部接続を拒否した。

次にrepo-archiveはキャッシュらしいのでForgejoの管理画面から消すことにした。すると即座にディスクは空き、全てが元に戻った。

犯人捜し

一旦サーバーは安定状態になったので犯人を捜すことにした。

まずはForgejoのログを見たのだが役に立たなかったので、次に私はGrafanaのLokiからnginxのログを引くことにした。

そしてLokiからnginxのログを見たらすぐに分かった。meta-externalagent、つまり悪名高いFacebookのクローラーだった。過去にこのブログにやってくる海外IPのBOTの挙動を軽く調べたでも出したが、こいつはやたらアクセスしてくる。

しかし何故Facebookのクローラーがなぜ…?と思ったがURLを見てすぐわかった。アーカイブにアクセスしているのだ。

もしかしたらForgejoはアーカイブURLにアクセスされるとその都度.zipや.tar.gzを生成しているのかもしれないと思って調べたらその通りだった。そんなクソみたいな仕様ある…?と思ったが、アーカイブを作るなら他に方法はない。

ForgejoはGitHubと違ってパス単位に作れるため、パスが多いリポジトリほど大量に作れるし、過去のバージョンを参照されたら事実上ほとんど無限に生成できる。そりゃパンクする。

Forgejoはどう思っているのか?

こんなのほとんど脆弱性である。しかもディスククォーターを設定したところでどうにもならない。ダウンロードできなくなって詰むだけだ。定期的にクリアしてもいいがSSDの寿命が縮んでしまう。

そこでForgejoの人たちはどう思っているのか調べてみたら案の定課題が起票されていた。最後の奴に至ってはメインコントリビューターの一人と思われるGusted氏の起票である。

結局どうすることにしたか

リポジトリの中身をzipで落としたい需要というのはどうしても出てくるし、それは仕方がない。しかし世代ごとパスごとに作ってしまうとなると、その数は無数になりすぎてしまう。

そしてダウンロードさせる以上どこかにデータを置く必要はある。仮に定期的に消すとしてもストレージの消耗は避けられない。

結論としてForgejoは撤去し、成果物は配布ページを作ってそこでzip配信するのが無難だなと思った。

簡単なコードについてはゴミ箱みたいな場所を作ってそこに転がしておくのもいいだろう。

明らかに利用者がいるValueDomainの奴とかもあるので、ひとまず土曜日にページを作って配信しようと思った。

meta-externalagentのアクセス推移

全部で何アクセス化までは見れていないが万単位でアクセスされてそうなので無茶苦茶だなと思った。

metaは最早攻撃者にも近いと思う。

経緯とか

18時頃にメトリクスが切れているのは多分書き込めなくて一時的に死んだからと思われる。再開できた理由は不明。この時点でネットワークトラフィックも死んでおりまともにアクセスできない状態だったと思われる。

19時半頃に手当を開始したが、FacebookのクローラーはForgejoを遮断するまでダウンロード不能(statできずにエラーを吐いていた)になったURLにひたすらアクセスしていた。

あとがき

今回の障害はいい勉強になった。

ディスク容量の急増という障害があることと、単にログとメトリクスを集めているだけでも解ることがあることが知れた。

勿論、閾値を設定した上での発報や、毎回クエリを叩かなくていいダッシュボードがあればよりよいと思うが、単に監視装置を置いているだけでもこうやって知ることができるのだなというので、いい経験になった。

2026/06/25(木)フライパンが壊れたので買いなおしたら快適になった

投稿日:

シンクの縁にフライパンを載せてたら取っ手を下にして落下し、取っ手が壊れてしまったので買い替えたら快適になった話。

買い替えたやつ

ニトリのIH・ガス火 超軽量フライパン 20cm(KY067)というやつを買った。たぶん前買ったやつの後継商品。

まず新品なのでピカピカで、二枚目の写真はサバを二回焼いて洗った後だが、全く黒くなっていない。汚れもすぐ落ち非常に快適だ。

前のフライパンは汚れが落ちづらくなっており、表面も黒ずんでいたので、寿命を知らせてくれるために壊れてくれたのかもしれない。

しかしフライパンを買い替えるたびにIHはいらないなと思うのだが、IH用とガス火用を分けて生産するとコストがかかるので仕方がないのだろう、と思ったらガス火 超軽量フライパン 20cm(KY066)という、表面仕様やサイズ感がほとんど同じものがあるようなので、こっちに買い替えようかなとか思った。

こちらの方が底面の表面積が広く、火の通りが良さそうだ。

ニトリのこのフライパンのいいところは20cmを名乗っているのにコーナンで売っている20cmのフライパンや、ニトリで売ってる他の20cmのフライパンより大きく見えることだ。実際22cm用のフライパンの二がハマる謎のサイズだし、ニトリで売ってる他のフライパンに間口を重ねてもデカい。

22cmの浅型フライパンなんて探してもそうそう存在しないので、中々都合のいいサイズである。

同日夜追記

ガス火 超軽量フライパン 20cm(KY066)を見てきたが、一回り小さかったので、これを買うのはやめることにした。

あとがき

このフライパンは確か8年ほど前に買い替えたものだと思うので、十分働いてくれた。ニトリで買って持ち帰ってる途中にアスファルトに落として傷を入れてしまい、すぐ買いなおしたのを今でも覚えている。

前述でガス火用のフライパンもあるとの情報を得たが、前回行ったとき見つけられなかったし、どこにあるのだろうとフロアマップを見たら、どうやらIHと全然違うところにあるようで気づけなかったようだ。残業した後に閉店前30分前に滑り込んだので、あまり探す余裕がなかったかもしれない。

しかし今年はモニタが壊れたり、イヤーパッドが壊れたり、スマホを買い替えたりで、買い替えが多い年だ。

モニタの買い替えについて過去記事を探したら書いてなさそうだったので、これについてもまた書きたいと思う。年初にモニタが壊れたのは中々盛大な出来事だった…。

2026/06/24(水)ForgejoでWebUIからのコミットに署名させる

投稿日:

GitHubではWebUIからPRのマージやファイル編集をしたときにコミットに署名がつくが、これをForgejoでもやる方法。

確認環境

  • Forgejo 15.0.3

やり方

基本は公式にあるInstance Commit Signingの通り。

  1. 署名用のSSH鍵を作る
    ssh-keygen -t ED25519 -f forgejo
    ssh-keygen -y -f forgejo > forgejo.pub
    sudo mv forgejo* /etc/forgejo
    sudo chown git:git /etc/forgejo/forgejo
    sudo chown git:git /etc/forgejo/forgejo.pub
    
  2. /etc/forgejo/app.iniに設定を足す
    [repository.signing]
    FORMAT = ssh
    SIGNING_KEY = /etc/forgejo/forgejo.pub
    SIGNING_NAME = "Example Git Instance"
    SIGNING_EMAIL = "noreply@git.example.com"
    INITIAL_COMMIT = pubkey
    WIKI = pubkey
    CRUD_ACTIONS = pubkey
    MERGES = pubkey
    
  3. Forgejoを再起動する
    sudo systemctl restart forgejo.service
    

結果

対応前 対応後

コミットに署名がつき、自分のアイコンが出るようになった。

但しGitHubとは違い、Forgejoが署名したことが分かる見た目になっている。

実はGitHubでもWebUIからの修正にはGitHubの鍵で署名が行われているのだが、GitHubではUI上その区別がない。Forgejo はその区別があるため、より明確な表示になったといえる。

あとがき

コミット履歴のアイコンにForgejoがいるのが気に食わなかったので、自分のアイコンで上書きできてよかった。これで履歴の気味悪さを忘れてWebUIから気軽に治せる。

署名なしコミットは文字やアイコンが大きく、行も広くなるため、表示がしっくりこなかったので丁度よくなった。

2026/06/24(水)Xperia 1 VIIIのZEROSHOCKとSpigenのRUGGED ARMORを両方買ったので比べてみた

Xperia 1 VIIIを買った話ではケースはZEROSHOCKがいいかなーと思ってZEROSHOCKを買ったのだが、MagSafe対応で磁器があると舞奈カードの読み取りなどで都合が悪く、ついでにZEROSHOCKは重くかさばるため、SpigenのRUGGED ARMORも買ってみようというので結局両方買ったやつ。

ZEROSHOCKの方が早く出ていたためSpigenのRUGGED ARMORが届くまでの一週間はZEROSHOCKを使っていた。

ZEROSHOCKとRUGGED ARMORの比較写真

表面(スマホはめるとこ)

写真撮影の都合でややこしいが左がSpigenのRUGGED ARMOR、右がZEROSHOCKだ。

大きな違いとしてはZEROSHOCKの方が大きく、特に四隅のバンパーがゴツく、いかにも保護してくれる感じだ。多分よほどのことがなければ角が壊れることはないだろう。ZEROSHOCKには内側にハニカム構造があるため地面にバシーン!と落としてしまったときにもダメージは少ないと思われる。しかもカメラの段差分の分厚さがあるからなおさらだ。

とはいえ、四隅に関してはRUGGED ARMORにもエアポケットがあるため、最低限の保護はある。

また地味な部分だが、ZEROSHOCKは電源ボタンの表側に梁が入っており、表側から指を滑らせて電源ボタンにアクセスしづらいのに対し、RUGGED ARMORはそう言ったものがなく素直にアクセスできる。

裏面

裏返してみたところ。

ZEROSHOCKはカメラの段差を極限までなくしているがRUGGED ARMORは段差が目立つ。

またカメラの保護に関してはレンズ外周スレスレまで保護しているZEROSHOCKの方が優位だ。恐らくレンズの穴ピンポイントにアスファルトの突起が刺さらない限り、舗装路に落としてもレンズが守られるだろう。

一方でRUGGED ARMORは外周に出っ張りがあるため、ZEROSHOCKと比較した場合にやや脆弱に見える。しかし出っ張りが高めなので意外と平気かもしれない。またSONYのロゴが見えるため、美観的が良いのがいいところだ。

電源ボタンに関してみてみるとZEROSHOCKは裏側に梁がなく、このケースは裏側から電源ボタンにアクセスさせる設計なのが伺える。RUGGED ARMORは表裏どっちからでも電源ボタンにアクセスできる。

表面加工についてはZEROSHOCKはゴムっぽくて滑りづらい、RUGGED ARMORはザラザラしていて滑りづらい感じだ。手で持った時の感触はZEROSHOCKも悪くないのだが、RUGGED ARMORの触り心地はXperia 1 VIII本来の表面に近く、ケースを付けているのに、まるで付けていないような感覚があり、これは非常に良いと感じた。

またRUGGED ARMORのストラップホールは千切れやすいという評判があるため、ストラップホールを使う場合は、明らかに分厚くて頑丈そうなZEROSHOCKの方が耐久性がある可能性がある。

下側

下側から見たところ。

ZEROSHOCKは厚みがあり、コネクタが挿しづらい。またコネクタの穴がRUGGED ARMORに比べて小さかった。

RUGGED ARMORはUSB Type-Cとその横のスピーカー分の切り欠きがあるが、ZEROSHOCKはUSB Type-Cとスピーカーで穴が分かれている関係でこうなっている。

スピーカーから音を出す場合、余計なものが少ないRUGGED ARMORの方が音はクリアだろう。

上側

上側から見たところ。この写真だけ左側がZEROSHOCK、右側がRUGGED ARMORになっている。

ZEROSHOCKはイヤホンジャックの開口部を大きく取りすぎて、余りにも縁を捕捉しすぎて手前側の縁が容易く千切れやすそうになっている。

RUGGED ARMORの方は特にそんなことがない。

またカメラ部分の段差はZEROSHOCKにはほとんどなく気にならないが、RUGGED ARMORはやや気になる。なれれば気にならないとは思うが、音ゲーを机の上でやる場合は向かないだろう。

操作感

ZEROSHOCKはその分厚さゆえに、シャッターボタンを押すのに力が必要で、すぐにカメラを起動したいときに空振りすることがしばしばあった。逆に言えばボタンの保護は堅牢といえるだろう。とはいえ、スマホは表裏面か角から落ちるものなのでボタンを強打するシーンは余り思いつかないが…。

RUGGED ARMORはボタンが非常に押しやすく、シャッターボタンはもちろん、ボリュームボタンを押すのも快適だ。電源ボタンへのアクセスもいい。

着脱のしやすさではZEROSHOCKの方が遥かに良く、RUGGED ARMORは装着や脱着がし辛かったが、逆に言えばRUGGED ARMORはミチミチなので隙間にゴミとかが入りづらく、ケースが何かの弾みで脱落する可能性も低いと感じた。今回のは過去に使ったRUGGED ARMORの中でも最強クラスにミチミチだと思う。

あとがき

RUGGED ARMORはMagSafeがないのでマイナカードを押し付けても磁気ストライプが壊れないのが最大の利点である。

最近では少なくなったとはいえ磁気ストライプや磁器硬券と一緒に入れる場合、MagSafeがあると支障になるので、そういった心配をしなくていいのは非常にいいところだ。

ZEROSHOCKはサイズ的に胸ポケットに入り、実用面では問題なかったが、過度に大きすぎた部分もある。とはいえ、個人的に最大の欠点はMagSafeである。

ただ磁力が弱いのか、家電店でMagSafe対応充電器に貼り付けてもずり落ちたので、内蔵の磁石がどれだけ役に立つのかは謎だった。

結果として私はZEROSHOCKには戻らず、これまで通りRUGGED ARMORを使うことにした。

しかしなぜ今回RUGGED ARMORは出るのが遅かったのだろうか…。少なくともAmazonに出てきたときは発売日以降だったように思うし、商品が出ても配送日もかなり先だった。今でこそ即日配送になっているが私が買ったときは6/20が最短だった。この時は配送時期に一ヶ月近いブレがあったと思う。

ZEROSHOCKを買うことにして一旦キャンセルしたものの、やはり買い直したときは最短が後ろに倒れ、やはり一ヶ月近いブレがあった。注文後は結果として6/23が配送日になった。まぁ二度目の注文のときはXperia 1 VIII発売キャンペーンとか言うので値引きが入ってタイプ安くなっていたので結果としては良かった気もするが…。

こういうのがあるとXperiaへの対応がおざなりになりそうで今後が心配だ…。ただ表面加工は素晴らしいの一言だし、ひょっとしたら製品のクオリティを高めていたとかなのかも知れない。或いは日本市場が見捨てられているのか…。

まぁもし、RUGGED ARMORが対応しない時になったら、きっとその時はZEROSHOCKが生きるのかもしれない。いやまぁ、その時にZEROSHOCKがXperiaへの対応を続けていてくれたらの話ではあるが…。