Lycolog

ログを取っていないので記憶で書いているし、順序は効率よくなるように変えているため、上手くいかない可能性がある。

• 前提
• 1. ConoHa VPS側でSSH接続できるようにする
• 2. ConoHa VPS側でnginxの設定
• 3. 自宅サーバー側で疎通可能にする
• 4. DNSの切り替えをする
• 5. nginxの設定を再読み込みする
• 6. 疎通確認
• 7. 掃除
• あとがき

前提

• IPv4接続だけをConoHa VPSに移し、IPv4はConoHa VPSに立てたリバプロから受ける
• ConoHa VPSスペックとしてOSはDebian GNU/Linux 13、メモリは512MB、CPU 1コアの最安インスタンス
• ConoHa VPSから自宅サーバーへはIPv6でリバースプロキシする
• ConoHa VPSから自宅サーバーへはHTTP通信で接続する
  • つまりIPv4側のTLS終端はConoHa VPS、IPv6側は自宅サーバーという構成
• ConoHa VPSのIPv6アドレスは2400:8500:2002:3175:160:251:206:248

1. ConoHa VPS側でSSH接続できるようにする

この時点ではSSHで繋げないためWeb画面からすべて行う。

1. SSHとICMPが繋がるようにする
2. SSHDの設定方法
3. 秘密鍵を作成し、公開鍵を取り出し.ssh/authorized_keysに追加
   • rootユーザーに追加した

2. ConoHa VPS側でnginxの設定

ここからはSSHで快適操作！

1. nginxをインストールして証明書置き場を作る

   apt update
   apt upgrade -y
   apt install -y nginx
   
   mkdir -p /etc/nginx/cert/lycolia.info
   

2. 証明書をSFTPで移す

3. 自宅サーバーへのリバプロ設定の作成。メンテナンスを最小限にするためにワイルドカードで飛ばす

   cat <<'EOF' | tee /etc/nginx/conf.d/lycolia-info.conf
   map $http_upgrade $connection_upgrade {
     default upgrade;
     ''    close;
   }
   
   upstream backend {
     server [2400:4153:8f01:c800:c14b:3f7a:2b54:353a];
   }
   
   server {
     http2 on;
     listen 443 ssl;
     server_name lycolia.info *.lycolia.info;
   
     ssl_certificate   /etc/nginx/cert/lycolia.info/fullchain1.pem;
     ssl_certificate_key /etc/nginx/cert/lycolia.info/privkey1.pem;
   
     client_max_body_size 500m;
   
     location / {
       proxy_pass http://backend;
   
       proxy_set_header Host $host;
       proxy_set_header X-Real-IP $remote_addr;
       proxy_set_header X-Forwarded-Proto $scheme;
   
       proxy_http_version 1.1;
       proxy_set_header Upgrade  $http_upgrade;
       proxy_set_header Connection $connection_upgrade;
     }
   }
   EOF
   
   # enbaleは勝手にやってくれた気がする
   systemctl enable nginx
   systemctl restart nginx
   

3. 自宅サーバー側で疎通可能にする

1. OpenWrtで80番ポートを開く
   1. LuCIを開き、Network→Firewall→Traffic Rulesで443を開けてるところに80を追加
2. ufwにある既存の設定からIPv4で443に繋ぐ設定を消す

3. ufwに新しい設定を足す

   # IPv6のみ許可する
   sudo ufw allow to ::/0 port 443
   # ConoHa VPSからの接続のみ80で受けられるようにする
   sudo ufw allow from 2400:8500:2002:3175:160:251:206:248 to any port 80
   

4. nginx側でConoHa VPSを信頼するようにする

   set_real_ip_from 2400:8500:2002:3175:160:251:206:248;
   real_ip_header X-Real-IP;
   

5. ConoHa VPSから来たX-Forwarded-Protoがhttpsならhttps、それ以外なら$schemeと解釈できるようなmapを書く
   これはConoHa→自宅サーバーがhttpで結ばれており、標準ではスキーマがhttpになってしまうが、それを回避しつつ、IPv6からの自作場への直アクセスがhttpないしhttpsだった場合は、そちらを取れるように変換するためである

   map "$realip_remote_addr:$http_x_forwarded_proto" $real_scheme {
     default $scheme;
     "2400:8500:2002:3175:160:251:206:248:https" "https";
   }
   

6. 対応するスキーマのバインドを全部変更する。以下はMastodonの例（4.5.4では二箇所ある）
   CGIであればCGIヘッダを書き換えるとよいと思うが、今回は該当がなかった

   +    proxy_set_header X-Forwarded-Proto $real_scheme;
   -    proxy_set_header X-Forwarded-Proto $scheme;
   

4. DNSの切り替えをする

1. AレコードをすべてConoHa VPSのIPv4に変更

5. nginxの設定を再読み込みする

DNSレコードが伝播するまでの間に粉うことでダウンタイムを最小化できる！

1. nginxの設定を再読み込みする

   sudo systemctl reload nginx
   

6. 疎通確認

1. 現時点で一般公開しているサイトに対し疎通するかどうか確認する

   curl -4 https://lycolia.info
   curl -4 https://blog.lycolia.info
   curl -4 https://mstdn.lycolia.info
   curl -4 https://eco.lycolia.info/wiki/
   

2. 落ちてたら設定を見直し再試行

7. 掃除

1. OpenWrtでIPv4向けの443を閉じる
   1. LuCIを開き、Network→Firewall→Traffic Rulesで443を開けてるところを消す
2. OpenWrtのDDNSスクリプトを無効化
3. nginxの設定でIPv4で443をlistenしてるところを全部消す

あとがき

やるだけやったが、結果的に現時点では全部撤回したので実証実験みたいになってしまった。

元々はフレッツ光クロスに切り替えてIPv4が失われることを想定して行ったが、よくよく考えたら切り替えたところで、今使っているルーターであるR86S U1のSFP+ポートが片方不安定で現状活用できないことや、IPv4のポート枯渇のためレスポンスが返せなくなる恐れを考えると、今やることではないなと思い、全撤回することにした。

ただまぁせっかくだしログを残していれば将来役に立つこともあるだろうというので残したが、色々あり構築時のログが消え去っていたので記憶を頼りに書くことになってしまったのは反省点である。

しかしR86S U1のSFP+が片側死んでいるのはどうしたものか。最近は何もかもすべてが高いのでおいそれと買い替えなどできないし…。まぁ現状困ってないし、IPv4は無料で手に入るし、別にクロスに変えなくてもいい気はした。

ところで全然関係ないけどWiFi 7を入れようと思ったもののSFP+の口が付いてるWiFiルーターは価格が高く、そうでなくとも、まともに速度が出る奴はどれもこれもデカく場所も取るので難しいね…。ひとまずやるとしたら1WくらいのトランシーバーでRJ45に変換するのが無難そうだと思った。その場合、10GtekのASF-10G-T80辺りはいい選択肢になりそうだ。

ルーターも最低でもトライバンドないと速度が出ないっぽいのでWXR18000BE10P辺りが5万円程度で、比較的小さいので無難だろう。この製品は過去に設置したことがあるのでサイズ的には問題ないことは確認済みである。今は手放しているので持っていない。経緯としてはかつてクロスを入れようとして導入したが、結局入れなかったし、デカくて邪魔だったので売った。

とはいえWiFiの速度には大きな不満があるので再導入を検討するのはありかもしれない。トランシーバーとセットで6万とかになるので眩暈がしそうだが…ｗ

ConoHa VPSをフロントエンドにし、自宅サーバーにリバースプロキシする構成を組んだ時のトラブルメモ。

• 起きていた条件
• 起きていた事象
• 解決した方法
• 何故解決したのか
• あとがき
  • バイナリ読解
  • 今回組んだ構成
  • 結果的にできた構成
  • おまけConoHa VPSで帯域実測

起きていた条件

nginxからnginxへリバースプロキシする構成で前段がTLS終端で、後段へはHTTPで接続していた。前段はVPS、後段は物理サーバーで別の環境。

起きていた事象

lycolia.infoと*.lycolia.info全体で前段が後段に接続できない状態になっていた。

curl -iSsl4 https://blog.lycolia.info/
HTTP/2 000 
server: nginx
date: Fri, 03 Jul 2026 15:24:44 GMT

前段のnginxにcurlを投げるとステータスコード000が返ってきて、curlが終了コード23で異常終了していた。

2026/07/04 00:11:33 [error] 2537#2537: *12468 upstream sent no valid HTTP/1.0 header while reading response header from upstream, client: xxx.xxx.xxx.xxx, server: lycolia.info, request: "GET /pub/lycolia/rss.xml HTTP/2.0", upstream: "http://[2400:4153:8f01:c800:c14b:3f7a:2b54:353a]:80/pub/lycolia/rss.xml", host: "blog.lycolia.info", referrer: "https://blog.lycolia.info/pub/lycolia/rss.xml"

nginxのエラーログには「アップストリームからのレスポンスヘッダーの読み取り中に、アップストリームが有効な HTTP/1.0 ヘッダーを送信しませんでした。」という意味のエラーを出力していた。

後段のnginxには何もログが出ていなかった。

curl -v --http1.1 -H 'Host: blog.lycolia.info' "http://[2400:4153:8f01:c800:c14b:3f7a:2b54:353a]:80/"
*   Trying [2400:4153:8f01:c800:c14b:3f7a:2b54:353a]:80...
* Connected to 2400:4153:8f01:c800:c14b:3f7a:2b54:353a (2400:4153:8f01:c800:c14b:3f7a:2b54:353a) port 80
* using HTTP/1.x
> GET / HTTP/1.1
> Host: blog.lycolia.info
> User-Agent: curl/8.14.1
> Accept: */*
> 
* Request completely sent off
* Received HTTP/0.9 when not allowed
* closing connection #0
curl: (1) Received HTTP/0.9 when not allowed

前段のnginxのあるVPSから、後段のnginxに対してhttpバージョン1.1を明示して叩くと「HTTP/0.9 when not allowed」というエラーが出てきた。HTTP/0.9…？初めて聞く概念だ…。

curl -s --http0.9 'http://[2400:4153:8f01:c800:c14b:3f7a:2b54:353a]/' | xxd           
00000000: 0000 1204 0000 0000 0000 0300 0000 8000  ................
00000010: 0400 0100 0000 0500 ffff ff00 0004 0800  ................
00000020: 0000 0000 7fff 0000 0000 0807 0000 0000  ................
00000030: 0000 0000 0000 0000 01                   .........

httpバージョン0.9を明示して叩き、帰ってきたレスポンスのバイナリ。端的に言うとプロトコルエラーで帰れと言われているが、理由は後述する。

解決した方法

+listen [::]:80;
-listen [::]:80 http2;

後段のmstdn.lycolia.infoの設定を上記に変更することで、他のドメインでも問題が解決した。

何故解決したかはわからないが、恐らく80 http2と書くと、他の80番ポートのリッスンにも影響が波及するのだと思う。

http2通信にしなくても問題ないのかでいうと、Mastodonは問題なさそうに見えたのでたぶん大丈夫なんだと思う。知らんけど。

何故解決したのか

使用しているnginxのバージョンがproxy_passするときにhttp 2.0をサポートしてなかったからだ。

nginx 1.29.4になるとproxy_passでhttp 2.0がサポートされるようで、2025年12月9日のリリースには以下の一文があった。

*) Feature: the ngx_http_proxy_module supports HTTP/2.

この時ばかりは今までnginxのバージョンに興味が微塵になかった私もバージョンを上げたくなった瞬間だった。

ただ後続のバージョンのバグフィックスを見るに結構バグが出てそうなので、今あげるのは時期尚早かもしれない。まぁ現状困ってないので上げなくてもいいのは幸いだ。

ところでv1.25.1になるとlisten単位のhttp2が非推奨になり、代わりにhttp2 onという全体単位？が推奨設定になるため、将来的に現状のポート単位にhttpバージョンを分ける技は使えなくなりそうである。

あとがき

バイナリ読解

前述したHTTP 2.0のバイナリレスポンスを読んでみようのコーナー。

curl -s --http0.9 'http://[2400:4153:8f01:c800:c14b:3f7a:2b54:353a]/' | xxd           
00000000: 0000 1204 0000 0000 0000 0300 0000 8000  ................
00000010: 0400 0100 0000 0500 ffff ff00 0004 0800  ................
00000020: 0000 0000 7fff 0000 0000 0807 0000 0000  ................
00000030: 0000 0000 0000 0000 01                   .........

そのバイナリを見るといいという情報をやってみたので試してみた結果。

まず16進数なので1桁に0-Fが入る。これは0000～1111ということだ。つまり1桁が4bitであることが分かる。

さて、HTTP/0.9は一旦忘れて、先ほどやってきたHTTP/2.0として解釈してRFC 9113 - HTTP/2を読んでみる。

「4. HTTPフレーム」によればHTTPフレームの先頭24bitがLength、8bitがType、8bitがFlag、1bitがReserved、31bitがStream Identifierらしい。

つまり先頭を分解するとこうなる。

Length: 00 00 12
Type: 04
Flag: 00
Reserved+Stream Identifier: 00 00 00 00

Lengthだ。0x000012なので18個の8bitフィールドがある。

次の8bitがTypeで0x04となっている。0x04は6.5.1. 設定フォーマットだ。

Reserved+Streamは全て0なので無価値だろう。

設定フォーマットではそこから48bit単位が設定フィールドとなる。先頭16bitがIdentifier、後ろ32bitがValueだ。

18個の8bitフィールドが設定になるため18 * 8 = 144, 144 / 48 = 3で3つの設定が存在すると読める。

00 03 00 00 00 80

つまりこの部分になる。

Identifierは00 03なのでSETTINGS_MAX_CONCURRENT_STREAMS。最大同時ストリーム数だ。

Valueは00 00 00 80なので128。

次は00 00 00 00 10なのでSETTINGS_HEADER_TABLE_SIZE。ヘッダ圧縮テーブルの最大サイズ。

04 00 01 00なので67,109,120。オクテット単位なので単位はバイトと思われる。オクテットのオクはオクトパスのOctと同じなのでタコの脚は八本と考えると覚えやすい。Octoberも旧暦の8月だからOct。

次は00 00 05なので、SETTINGS_MAX_FRAME_SIZE。

00 ff ff ff 00なので4,294,967,040。これも単位なので単位はバイトと思われる。

これで設定が終わり、またフレームに戻る。

00 0004 0800
0000 0000 7fff 0000 0000 0807 0000 0000
0000 0000 0000 0000 01

これが残り。

Length: 00 00 04 → 4 * 8 = 32bit
Type: 08 → WINDOW_UPDATE
Unused Flags: 00
Reserved+Stream: 00 00 00 00
Reserved+Window Size Increment: 7f ff 00 00 → 2,147,418,112

次の残り

0000 0807 0000 0000
0000 0000 0000 0000 01

Length: 00 00 08 → 64bit
Type: 07 → 帰れ
ここまでくれば尻だけ読めばいいので中間は読み飛ばす。
最後の32bitがエラーコードらしいので00 00 00 01が恐らくエラーコード。意味合い的にはPROTOCOL_ERROR。

要するにHTTP 2に対してHTTP 1.1で接続していたのでプロトコルエラーが返却され、しかしnginxは理解できなかったのでHTTP 0.9として解釈していたのだろう。

今回組んだ構成

今回nginxからnginxにリバースプロキシをしたわけだが、結果として上図のような構成にした。前段にはConoHa VPSを利用している。

これをした理由としては、以前フレッツ光クロスでフルポート使えるIPv4が取れないことが判明したため、クロスに移行出来るようにするためというのと、IPv4のためにDDNSし続けるのが地味に面倒なのと、宅内からIPv4を排除したかったところによる。

ただこれはこれでVPS側にもTLS証明書が必要になるため、DDNSが消えてもIPv4保守のための呪いはまだ残る。DDNSよりはマシだが…。

また、この構成では前後でnginxのバージョンが異なり前段がv1.26.3、後段がv1.24.0となっているため、前段ではhttp2 onにしないと警告が出るなど、バージョン差異による違いが微妙にある。

結果的にできた構成

今回の施策によって自宅サーバーからIPv4が失われても、AレコードをConoHa VPSに向けることでIPv4を受けることが可能な体制の検証をすることができた。これによってフレッツ光クロスに乗り換えたときのIPv4不在問題を解消できる状態となった。

実運用に移すためにはVPS側にもTLS証明が必要になるので自宅サーバーからSCPで送るか、VPS側でも取得する必要が出てくるので、まだまだ対策が必要だ。後者は同一ドメインに二重に証明書が存在する状態になるのでなんか嫌だし、恐らく前者でやるだろう。TCP パススルーなる技術も健闘したが、真のクライアントIP転送問題など、いろいろ厄介そうなのでやめた。

SCPで送る場合はパスフレーズ付きの鍵認証を突破させ、更にnginxをリロードさせないといけないからこちらもやや頭が痛い。パスフレーズ付きのSSH鍵を無人突破させるにはどこかに平文でパスフレーズを持つ必要がある。暗号化もできるがどんどん複雑に…。

或いはDNS-PERSIST-01を使うことで証明書更新を不要にするのも一つの選択肢かもしれないので、こちらも検討していいかもしれない。

しかしVPSがあることで監視対象が増えるなど、なかなか複雑化してしまうので、これを軌道に乗せるかどうかは現時点では不透明だ。ただConoHa VPSは最低スペックで36ヶ月契約であれば月額293円のため、36ヶ月換算でも10,548円にしかならず、IPv4を保持する手段としてはお手頃である。安いISPでもv4を買おうとすると月2～3,000円はするし、まともなところだと一万円以上するので、IPv4にサーバーがついてこの価格は破格と言える。

帯域は100Mbpsだが、100Mbpsあれば十分だろう。

おまけConoHa VPSで帯域実測

自宅サーバーとConoHa VPS間でiperf3をやってみた結果。自宅サーバーへの穴あけが面倒だったので自宅サーバー→ConoHaという逆経路でしか試していない。

• sender: 106 Mbits/sec
• receiver: 103 Mbits/sec

MantisBT標準のステータスはどうにも使いづらいので、独自のステータスを追加して置き換える方法。

確認環境

• MantisBT 2.27.1

やりたいこと

MantisBT標準のステータスを捨てて、一人用のチケット管理システムとして使えるようにする。要するにTODO管理の様なものにする。

ステータスの再定義

まずステータスを再定義する。

ステータスは標準でnew, feedback, acknowledged, confirmed, assigned, resolved, closedと七種類あるが、これをdraft, not started, in progress, pending, testing, completedの六つに変える。意味合いとしては下書き、未着手、仕掛中、保留、試験中、完了だ。

最後に解決状態も同様にopen, fixed, reopened, unable to duplicate , not fixable, duplicate, not a bug, suspended, wont fixと九つあるのを、in completed, duplicate , wont fix, completedの四つに再定義する。

このように状態を絞ることでTODO管理ツールとして機能させることが可能になり、更に状態管理も単純になってやりやすくなる。

やり方

1. config/config_inc.phpを開きステータスの定義を追加する

   # ステータスの定義
   # <優先度>:<キー名>として並べる。値はDBに登録される値として利用される。
   $g_status_enum_string = '10:draft,20:not started,30:in progress,40:pending,50:testing,100:completed';
   
   # 定義したキー名に対し課題一覧で表示される色を決める
   $g_status_colors['draft']       = '#fcbdbd';
   $g_status_colors['not_started'] = '#e3b7eb';
   $g_status_colors['in_progress'] = '#ffcd85';
   $g_status_colors['pending']     = '#c2dfff';
   $g_status_colors['testing']     = '#fff494';
   $g_status_colors['completed']   = '#d2f5b0';
   
   # チケットの解決状況の定義
   # <優先度>:<キー名>として並べる。値はDBに登録される値として利用される。
   $g_resolution_enum_string = '10:in completed,20:duplicate,30:wont fix,90:completed';
   

2. config/custom_strings_inc.phpを作成し、ここまでで作った状態を和訳する。

   <?php
   
   # ステータス表示名
   # 完了はフィルタで以上が付くので一番後ろに置いておくとよいと思う
   $s_status_enum_string = '10:起案,20:未着手,30:仕掛中,40:保留,50:試験中,100:完了';
   
   # ステータス変更画面のタイトル・ボタン・通知タイトル
   $s_draft_bug_title = 'ステータスを起案に変更';
   $s_draft_bug_button = '起案にする';
   $s_email_notification_title_for_status_bug_draft = '課題が起案されました。';
   
   $s_not_started_bug_title = 'ステータスを未着手に変更';
   $s_not_started_bug_button = '未着手にする';
   $s_email_notification_title_for_status_bug_not_started = '課題が未着手になりました。';
   
   $s_in_progress_bug_title = 'ステータスを仕掛中に変更';
   $s_in_progress_bug_button = '仕掛中にする';
   $s_email_notification_title_for_status_bug_in_progress = '課題が仕掛中になりました。';
   
   $s_pending_bug_title = 'ステータスを保留に変更';
   $s_pending_bug_button = '保留にする';
   $s_email_notification_title_for_status_bug_pending = '課題が保留になりました。';
   
   $s_testing_bug_title = 'ステータスを試験中に変更';
   $s_testing_bug_button = '試験中にする';
   $s_email_notification_title_for_status_bug_testing = '課題が試験中になりました。';
   
   $s_completed_bug_title = 'ステータスを完了に変更';
   $s_completed_bug_button = '完了にする';
   $s_email_notification_title_for_status_bug_completed = '課題が完了しました。';
   
   # 解決状況表示名
   $s_resolution_enum_string = '10:未解決,20:重複,30:対応不要,90:対応完了';
   

3. 既にMantisBTを利用している場合、既存のチケットの表示がバグるため、ステータスと解決状況が整合するようにDBを適当に整える。

   -- ステータスの置換
   UPDATE mantisbt.mantis_bug_table SET status = 20
   WHERE status != 10;
   
   -- 解決状況の置換
   UPDATE mantisbt.mantis_bug_table SET resolution = 100
   WHERE resolution = 20;
   

4. あとは管理画面に入りワークフローを組めば終わりである。個人で使うものなので制約はだいぶ緩めにしている。
   

   

あとがき

これで管理がだいぶ楽になりそうだ。MantisBTはバグ管理ツールなのでTODO管理をしようとすると標準ではしんどいが、カスタマイズを重ねることで大分マシになる。

Ubuntu 26からinit.dが非推奨になるが、systemdの設定が見つからなかったので試しに書いてみた。

確認環境

• Ubuntu 24.04.4 LTS
• nginx/1.24.0

手順

sudo mv /etc/init.d/nginx ~
sudo service stop nginx
cat <<'EOF' | sudo tee /etc/systemd/system/nginx.service
[Unit]
Description=nginx
Documentation=man:nginx(8)
After=network-online.target remote-fs.target nss-lookup.target
Wants=network-online.target

[Service]
Type=simple
ExecStartPre=/usr/sbin/nginx -t -q
ExecStart=/usr/sbin/nginx -g 'daemon off; master_process on;'
ExecReload=/bin/kill -HUP $MAINPID
ExecStop=/bin/kill -QUIT $MAINPID
TimeoutStopSec=5
KillMode=mixed

[Install]
WantedBy=multi-user.target
EOF

sudo systemctl daemon-reload
sudo systemctl enable nginx
sudo systemctl start nginx

参考記事

• nginxを起動するsystemdの設定について
• Type=simple / forking / oneshot の違い｜systemd Unit設定の落とし穴 | 【インフラマニュアル】
• Systemd入門(4) - serviceタイプUnitの設定ファイル

あとがき

nginxはマスタプロセスが上がったままなのでtype=simpleで問題なさそうだったが、正直よく分かってないので、何か問題が出たらまたその時に対処したい。

init.dにはまだ沢山転がってるので徐々に移行させていかないと…。

過去に何度かBOTなどを避けるためのアクセス制御を導入していたが、結果どれも微妙だった。しかしどうにかしたい、そうだ、nginxは高機能なのでできるんじゃないか？と思って実践してみたログ。

User-AgentはGEOIP2と何も関係ないが、ついでにやったので書いている。

確認環境

やったこと

互換性確保のためnginxのダウングレード

インストールされていたnginxが1.26.1-2~jammyで、libnginx-mod-http-geoip2との互換性がなかったためダウングレードすることにした。

まず次のコマンドで整合性を確認した。コマンド自体はGPT-5.5が作ってくれたものであるが、こうすることでダウングレードを許可した上での互換性チェックができるようだ。

コマンドの実行結果としては既に追加されているコンポーネント、ダウングレードされるコンポーネント、新たに追加されるコンポーネントの一覧が出てくる。

# ngx_http_geoip2_module.soが存在しないことを確認。既にある場合は本項の工程は飛ばせると思う
ls -la /usr/lib/nginx/modules

sudo apt install -s --allow-downgrades \
  nginx=1.24.0-2ubuntu7.13 \
  nginx-common=1.24.0-2ubuntu7.13 \
  libnginx-mod-stream=1.24.0-2ubuntu7.13 \
  libnginx-mod-http-geoip2

上記の構成でインストールできることが分かったので-sを外してnginx本体をダウングレードし、他をインストールする。

sudo apt install --allow-downgrades \
  nginx=1.24.0-2ubuntu7.13 \
  nginx-common=1.24.0-2ubuntu7.13 \
  libnginx-mod-stream=1.24.0-2ubuntu7.13 \
  libnginx-mod-http-geoip2

# ngx_http_geoip2_module.soが増えていることを確認
ls -la /usr/lib/nginx/modules
ngx_http_geoip2_module.so

GEOIP2データベースの入手と配置

MMDBなら何でも行けると思うので、Matomoで使ってる無料の奴を使う。理想的にはCRONで定期取得するのがいいと思うが、面倒なので今回はやってない。

sudo mkdir -p /usr/share/GeoIP
sudo wget https://download.db-ip.com/free/dbip-country-lite-2026-06.mmdb.gz -O /usr/share/GeoIP/dbip-country-lite.gz
gunzip /usr/share/GeoIP/dbip-country-lite.gz

nginxの設定でGEOIPの有効化を行う

/etc/nginx/nginx.confに以下の設定を追記すると、$geoip2_で始まる変数にMMDBの中身が入るようになる。

load_module modules/ngx_http_geoip2_module.so;

http {
    ...

    geoip2 /usr/share/GeoIP/dbip-country-lite {
      auto_reload 24h;
      $geoip2_metadata_country_build metadata build_epoch;
      $geoip2_country_code country iso_code;
      $geoip2_country_name country names en;
    }

    ...

nginxのJSONログに国コードを含める

JSONログにキーを追加してやればよい。

http {
  ...

  log_format main_json escape=json
  '{'
      ...
      '"country_code":"$geoip2_country_code"'
  '}';

国コードとUserAgentの判定フィルタの元ネタを作る

nginxのmap構文を使って判定用の元ネタを作る。

左側は~で始めると正規表現扱いになり、~*とすると大文字小文字の違いを無視してくれるようになるらしい。

http {
  # headlesschromeを2にしてるのは、これはちょっと毛色が違うと思ったため、便宜上分類分けしている。
  # 但し現時点でこの値を特別扱いしておらず、1と等価なので無駄ではある。
  map $http_user_agent $deny_ua {
    default                 0;
    "~*meta-externalagent"  1;
    "~*baidu"               1;
    "~*headlesschrome"      2;
    ""                      1;
  }

  map $geoip2_country_code $deny_ca {
    default 0;
    "CN"    1;
    "BR"    1;
    "IN"    1;
  }

  # nginxのif文にはandやorに相当する演算子がないのでmapで合成しておく
  map "$deny_ua:$deny_ca" $deny_client {
    default 1;
    "0:0"   0;
  }
  ....
}

雰囲気で読んでいるが構文の意味合いはこうだと思う。KeyValueで並べていくと入力値（$input_variable）のKey（input_value）に対するValue（output_value）が出力値（$output_variable）に入るのだと思う。

map $input_variable $output_variable {
    default <default_value>; # デフォルト値
    input_value output_value;
    ...
}

フィルタ用のsnippetsを作る

vhostに撒くように/etc/nginx/snippets/deny_client.confのようなsnippetsを作る。

前述のmapで判定をまとめているのでif文一つで制御できるようになっている。

if ($deny_client = 1) {
  return 403;
}

snippetsをvhostに撒く

反映したいvhostの設定にsnippetsを撒いていく。

server {
  ...

  include snippets/deny_client.conf;

  ...

動作検証

こんな感じで検証して弾かれてれることを確認した。国コードはどうにもならないが原理上問題ないはずなので大丈夫だろう。

curl -H "User-Agent:meta-externalagent/1.1" https://lycolia.info

あとは念のために国コードが出ているかどうかをnginxのログを見て出ていたらOK。

関連記事

• 自宅サーバーの一部がダウンしたが監視を入れていてよかった話
  • Facebook(Meta)のBOTのせいでサーバーが落ちた話
• Anubisを雑に設置したが、結果微妙だったので撤去した話
  • Anubisで防げないか試してみたが、Anubisのストレージや、アクセス解析との親和性などの関係でなかったことにしたやつ
• このブログにやってくる海外IPのBOTの挙動を軽く調べた
  • 取り敢えずどんな迷惑アクセスがあるか調べたときの奴
• CGIのラッパーCGIを作る方法
  • この記事ではadiaryに対するアクセス制御のラッパーを書いていた

あとがき

今回のアクセス制御の導入にあたり、運用面で課題のあるAnubisを回避しつつ、大量に存在するCGIにラッパーCGIを嚙ますなどの対応を回避できたのはよかった。

nginxは何とも高性能だ。そして自宅サーバーに全部乗せしたおかげで、レンタルサーバーでは決して手が届かないことができるのが良いと思った。

しかしググってもGEOIP無印の情報ばかりで、GEOIP2の情報が全然なかったので地味にハマってしまった。こういう時LLMに情報を漁ってもらうと取っ掛かりが得られて突破口を見つけられたりするので便利だと感じる。

パッケージを見ていて気になったこと

パッケージを見ていて気になったことは元のコードは保守されてないにもかかわらず、ディストリごとにコードが保守されているように見えたことだ。

今回導入したのはlibnginx-mod-http-geoip2だが、これは元を辿ればDebianのlibnginx-mod-http-geoip2のようで、更に元を辿るとleev/ngx_http_geoip2_module: Nginx GeoIP2 moduleに行きつく。

何故ならDebianのリポジトリがGitHubより新しく、READMEの中身が同じだからだ。設定方法もまるっきり同じに見える。

GitHubのリポジトリは2年以上放置されており「Support nginx 1.23.0」で時が止まっているが、Ubuntuでは「Rebuild against new nginx 1.30.1.」とあるため、だいぶ新しいところまでサポートが進んでいる。

よく考えるとパッケージのバージョンに-ubuntuみたいなのがついているのも良くあることなので、もしかしたらディストリごとにこういったアプリケーションを保守していたりするのだろうか？

そういえばPHPなんかも本家がサポート切れててもUbuntuではサポート内とか聞いたことがある。動作サポートなのかセキュリティサポートなのか、何のサポート課なのかまでは知らないが、星の数ほどあるパッケージをディストリごとに保守しているとしたら、これは凄いことだなと思ったし、他人が書いた得体のしれないパッケージをどう保守しているのかも気になった。

Linuxの世界は興味深い…。

nginxのダウングレードからのバージョンの復旧について

ダウングレードしても基本的に影響はないと思うが、元のバージョンに上げようとするとUbuntuそのもののバージョンアップが必要なことを知った。

しかし24.04.04 LTSから26.04への安全なアップグレードはまだ提供されていないようなのでいったん断念した。26.04.01が出ると上げられるようになるらしく、現状はお試し版みたいな感じらしい。

よくあるx.00は安定板だけど不具合がある、x.01で真の安定板になるみたいな話はUbuntuにもあるんだなと思った。

あとがき

昔nginx公式のどこかにnginxでifを使うなみたいなのがあったと思う。たぶん今はもう消えていて、GitHubに残ってる残骸に残るだけになっているようだ。

ここを見る限りifを使うとifの判定後、別のifにかかることで想定外の挙動をするから、使うならreturnやrewrite ... lastと組み合わせて、確実にリクエストを殺すようにしろということのように読めた。

公式リファレンスを見てもifそのものを使っている個所はngx_http_rewrite_moduleに存在するため、「If is Evil...」だから使ってはいけないというより、適切に使えればよいのだと思った。

あと思ったのだが、恐らくこの「If is Evil...」はnginx公式ではなく、nginx plusの方にあったドキュメントだった気がする。サイトのカラーが緑だった記憶があるからというのと、このリポジトリがそれっぽいからだ。