Lycolog

検索条件

タグで絞り込み Webサービス(2) Webサービス::ConoHa(1) Webサービス::Value-Domain(1) ジャンル(2) ジャンル::インターネット(1) ジャンル::自宅サーバー(2) ソフトウェア(2) ソフトウェア::HTTPD(1) ソフトウェア::HTTPD::nginx(1) ソフトウェア::OpenWrt(1) ネットワーク::DNS(1) ネットワーク::IPv6(2)

日付で絞り込み 2月(1) 6月(1) 7月(1)

全3件 (1/1ページ) 記事本文を表示

2026/07/06(月)nginxのリバースプロキシが上手くいかない問題を解消した

更新日：2026/07/08
投稿日：2026/07/06

ソフトウェア::HTTPD::nginxネットワーク::IPv4ネットワーク::IPv6Webサービス::ConoHaジャンル::自宅サーバー

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という逆経路でしか試していない。

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

コメント（0件）

2026/06/01(月)フレッツ光クロスでフルポート使えるIPv4が取れるか調べた

更新日：2026/07/04
投稿日：2026/06/01

ジャンル::自宅サーバージャンル::インターネットネットワーク::IPv4ネットワーク::IPv6

フレッツ光クロスとフレッツ光ネクスト隼のコスト比較をしてみたの続きのような記事。

結論から言うと、現実的は難しい。金があれば取れる。

フレッツ光クロス x OCNでの対応状況

取り敢えず私はOCNユーザーなので、まずはOCNの対応状況から調べてみることにした。

OCN IPv6インターネット接続｜光回線 | OCNお客さまサポートによると次のようにあり、使えないことが分かった。

（OCN 光 with フレッツクロス / OCN インターネット 10ギガはPPPoE接続できません。）

またOCNサポートに問い合わせたところ、OCNインターネット10ギガはIPoEのみ対応で、方式はMAP-E、OCNバーチャルコネクトとのことだった。そしてPPPoEは使えず、方式上フルポート使えるIPv4の提供はないと言う話だった。

兵庫県下におけるフレッツ光クロスで従来型IPv4の提供があるISPについて

フレッツ光対応プロバイダー検索｜NTT西日本公式に一覧があるが、対応しているのはIIJのみ。

IIJ IPv6 FiberAccess/F サービスタイプIPoEであればIPv4アドレスの固定割り当てが取れるそうだが、月額14,000円～ということで、到底支払える値段ではない。

IIJのフレッツ光ネクストはIPv6 IPoE、動的IPv4アドレスの場合は2,200円とのことなので、恐らくフレッツ光クロスにするとIPv4が高くなるのだと思う。

あとがき

今回の調査では、前段に外部のリバースプロキシやそれに類するものを置かず自宅サーバーを運用する場合にIPv4を切る必要が出てくることが判明した。

前回の調査ではフレッツ光クロスにすると年3万円コスト増になることが分かっているため、これと合わせるとクロスに移行する場合、年3万の負担増とIPv4でのサーバーサービスを終了しないとならないことが分かった。

中々悩ましい結果だが、回線が逼迫しているわけではないので、OpenWrtのメトリクスなどをもっとちゃんととって、必要が出たあたりで移行できたらいいなとは思う。今でも偶に不審な速度になることはあるので、それの裏が取れたら移行してもいいだろうとは思った。

コメント（0件）

2026/02/22(日)OpenWrtからValue-Domainに複数サブドメインのDDNSを行うツールを作った

投稿日：2026/02/22

ソフトウェア::OpenWrtWebサービス::Value-Domainネットワーク::DNSネットワーク::IPv4

Value-DomainのダイナミックDNSエンドポイントは60秒以内に叩くとエラーが返ってくるので、これを回避するためのDDNSの仕組みを作った話。

やったこと

まず、Value-DomainのDNS APIに対し、既存のaレコードをバルクで差し替えるためのツールとしてvd-ddns_v4.plを作った。

そしてhotplug.dにPPPoEインターフェースのIPが変わったときに、このスクリプトを蹴る処理を書いた。

この記事の前提構成

OpenWrtにIPv4用のPPPoEインターフェースがある。

やったこと

今回利用するのに必要なPerl周りをセットアップする。ストレージの空きが3.2MBほど必要
value-domain-dns-utilを/root配下とか適当な場所に放り込む
- opkg install openssh-sftp-serverでSFTPを導入しておくとファイル移動に便利

vi /etc/hotplug.d/iface/40-pppoeとかして、OpenWrtのインターフェースが変化したときのHookを作る

 #!/bin/sh
 # デバイスが存在しなければ終了
 [ -n "$DEVICE" ] || exit 0
 # リンクアップでなければ終了
 [ "$ACTION" = ifup ] || exit 0
 # インターフェース名がPPPoEのものでなければ終了
 [ "$INTERFACE" = wanppp ] || exit 0
 # pppoe-wanpppのIPv4アドレスを取得
 pppoeaddr=$(ip -4 addr show pppoe-wanppp | head -2 | tail -1 | awk '{print $2}')
 # ログに吐く
 logger -t "DDNS - PPPoE IP" $pppoeaddr
 # DDNSもどきを叩く
 /root/vd-dns-util/vd-ddns_v4.pl 'XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX' example.com $pppoeaddr hoge fuga piyo
 # 結果をログに吐きたいが何故か動いていない
 if [ $? -eq 0 ]; then
 logger -t "DDNS - UPDATE SUCCEED"
 else
 logger -t "DDNS - UPDATE FAIL"
 fi

PPPoEインターフェスをRestart
Value-Domainのコンパネで指定したドメインのaレコードが更新されていることを確認

備考

一般的にDNSレコードの浸透時間は更新前に浸透していたTTLに依存し、Value DomainのAPI経由で普段から操作している場合は120秒以下にならないため、最大120秒のダウンタイムが発生するが、理論上は公式のDDNS機能と大差ないはずと思われる。

aレコードのみの対応にしているのは私の環境だとIPv6は変動しないが、v4はそれなりの頻度で変わるためだ。

運用しているMastodonのv4が変わったのに気づかないまま疎通できないインスタンスが出てくることがしばしばあり、手動で対応するのが手間なのと、毎回一日くらい気づくのに遅れるので今回自動化に踏み切った。前々からやり勝ったのだが、中々腰が重く進んでいなかった。

そもそもこの手のものは監視システムで検知できて然るべきなので、おいおい監視システムの構築もしていきたいところだ。

コメント（0件）