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 12040000 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 = 32bit08 → WINDOW_UPDATE0000 00 00 007f ff 00 00 → 2,147,418,112
次の残り
0000 0807 0000 0000
0000 0000 0000 0000 01
Length: 00 00 08 → 64bit07 → 帰れ 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間でiperf3をやってみた結果。自宅サーバーへの穴あけが面倒だったので自宅サーバー→ConoHaという逆経路でしか試していない。
Interval
Transfer
Bitrate
Retr
Cwnd
0.00-1.00 sec
24.4 MBytes
204 Mbits/sec
0
1.42 MBytes
1.00-2.00 sec
10.9 MBytes
91.2 Mbits/sec
0
1.43 MBytes
2.00-3.00 sec
12.2 MBytes
103 Mbits/sec
0
1.43 MBytes
3.00-4.00 sec
11.0 MBytes
92.3 Mbits/sec
0
1.43 MBytes
4.00-5.00 sec
10.9 MBytes
91.2 Mbits/sec
0
1.43 MBytes
5.00-6.00 sec
12.2 MBytes
103 Mbits/sec
0
1.43 MBytes
6.00-7.00 sec
11.0 MBytes
92.3 Mbits/sec
11
1.26 MBytes
7.00-8.00 sec
11.0 MBytes
92.3 Mbits/sec
169
762 KBytes
8.00-9.00 sec
11.0 MBytes
92.3 Mbits/sec
0
807 KBytes
9.00-10.00 sec
12.2 MBytes
103 Mbits/sec
0
838 KBytes
sender: 106 Mbits/sec
receiver: 103 Mbits/sec
