Nginx on KnightLiブログ

CVE-2026-42945 の確認方法：Nginx Rift の発動条件、バージョン確認、アップグレード方針

Fri, 15 May 2026 17:55:42 +0800

CVE-2026-42945 は NGINX Open Source と NGINX Plus に存在するセキュリティ脆弱性で、外部では Nginx Rift とも呼ばれています。問題は ngx_http_rewrite_module にあり、脆弱性の種類は heap-based buffer overflow です。

この種のニュースは、「18 年間潜伏」「パスワード不要でリモート制御」「サーバーの 30% が影響」といった見出しになりがちです。たしかに広まりやすい表現ですが、パッチ情報や NVD の説明を見るときは、リスクを分解して見るべきです。深刻な脆弱性であり、ログインも不要です。ただし、すべての Nginx インスタンスが自動的に乗っ取られるわけではなく、発動には特定の rewrite 設定とリクエスト条件が必要です。

まず公式説明を見る

NVD による CVE-2026-42945 の説明は、次のように整理できます。

NGINX Plus と NGINX Open Source に影響する。
脆弱性は ngx_http_rewrite_module にある。
rewrite ディレクティブの後に rewrite、if、または set ディレクティブが続き、$1 や $2 のような名前なし PCRE キャプチャグループを使い、さらに置換文字列に疑問符 ? が含まれる場合に問題が発動する可能性がある。
未認証の攻撃者が細工したリクエストを送ることで脆弱性を発動できる。
結果として NGINX worker プロセスで heap buffer overflow が発生し、再起動する可能性がある。
システムで ASLR が無効化されている場合、コード実行の可能性がある。

CNA である F5 の評価は次のとおりです。

CVSS v4.0：9.2、Critical。
CVSS v3.1：8.1、High。
CWE：CWE-122 Heap-based Buffer Overflow。

つまり、これは単なる「設定ミスで 404 になる」問題ではなく、Nginx 公式のセキュリティ修正対象となるメモリ安全性の脆弱性です。

落ち着いて読むべき表現

第一に、「パスワード不要」は基本的に未認証攻撃と理解できます。攻撃者は Nginx の管理画面にログインする必要も、SSH を取得する必要も、アプリケーションアカウントを持つ必要もありません。ただし、任意の公開 Nginx を簡単に乗っ取れる、という意味ではありません。

第二に、「直接リモート制御」は条件次第です。公式説明に沿ったより慎重な言い方は、worker プロセスの再起動を引き起こす可能性がある、そして ASLR が無効なシステムではコード実行が可能な結果になり得る、というものです。ASLR が有効で、ディストリビューションのビルド強化が適用され、実行権限が制限された環境では、リスク経路はより複雑になります。

第三に、「30% のサーバーが影響」という表現を「Nginx の市場シェア全体が攻撃面である」と同一視してはいけません。実際の露出は、バージョン、影響を受けるモジュールの有無、特定の rewrite 設定の有無、ディストリビューションがすでにバックポートしているか、そして Nginx 実行環境の強化状態によって決まります。

より正確な判断はこうです。本番環境で Nginx を動かしているなら、すぐ確認するべきです。ただし、見出しの割合だけで自分の環境が影響を受けるかどうかを判断しないでください。

影響範囲をどう判断するか

nginx.org のリリース情報によると、2026 年 5 月 13 日に公開された nginx-1.30.1 stable と nginx-1.31.0 mainline には複数のセキュリティ修正が含まれており、その中に CVE-2026-42945、つまり ngx_http_rewrite_module の buffer overflow 修正も含まれています。

公式 Nginx のソースコードや公式パッケージを使っている場合は、まず次を確認します。

NGINX Open Source stable：1.30.1 以降へアップグレード。
NGINX Open Source mainline：1.31.0 以降へアップグレード。
NGINX Plus：F5 が案内する対象ブランチの修正版を確認。

Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、Alpine、コンテナイメージ、Plesk、管理パネル、Ingress Controller、クラウド事業者の管理コンポーネントを使っている場合、nginx -v の上流バージョンだけを見て判断しないでください。多くのディストリビューションはセキュリティ修正を古いパッケージに backport します。バージョン番号が古く見えても、パッチが取り込まれている場合があります。

1 分で緊急度を判断する

まず次の質問で簡易的に優先度を分けます。

この Nginx はインターネットに直接公開されているか、API Gateway、リバースプロキシ、ロードバランサー、Ingress の入口層にあるか。
公式 Nginx パッケージ、ソースビルド、サードパーティ管理パネル、コンテナイメージを使っており、まだ CVE-2026-42945 の修正状態を確認していないか。
設定に複雑な rewrite ルールがあるか。特に連続した rewrite、if、set、および $1、$2 のような名前なしキャプチャを使っているか。
リクエストパス、クエリパラメータ、ユーザー制御入力を rewrite の出力先に含める場面があるか。
ASLR が無効、worker の権限が強すぎる、コンテナ権限が広すぎるなど、システム強化が弱いか。

最初の 2 項目に該当し、rewrite 設定の確認がまだなら、高優先度として扱うべきです。公開入口、共有環境、Kubernetes Ingress、エッジプロキシ、ログインや API トラフィックを扱う Nginx は、修正済みと確認できるパッケージへ優先的に更新または置き換えます。

Debian / Ubuntu / RHEL / Alpine で修正を確認する方法

ディストリビューション利用者は nginx -v だけを見ないでください。Debian、Ubuntu、RHEL、AlmaLinux、Rocky Linux、Alpine などは、セキュリティパッチを安定ブランチへ backport することが多く、見かけのバージョンが nginx.org の 1.30.1 や 1.31.0 より低い場合があります。

Debian / Ubuntu では、セキュリティアドバイザリ、パッケージ changelog、アップグレード候補を確認します。

nginx -v
nginx -V
apt list --upgradable | grep nginx
apt changelog nginx | grep -i "CVE-2026-42945"

RHEL / AlmaLinux / Rocky Linux では、セキュリティ更新とパッケージ変更履歴を確認します。

1
2

yum updateinfo list security | grep -i nginx
rpm -q --changelog nginx | grep -i "CVE-2026-42945"

Alpine では、現在のパッケージバージョンとセキュリティブランチの更新状況を確認します。

1
2

apk info -v nginx
apk version -v nginx

パッケージマネージャー、ディストリビューションのセキュリティアドバイザリ、またはベンダー advisory が CVE-2026-42945 の修正済みを明記しているなら、上流バージョン番号が新しく見えなくても「バックポート済み」と扱えます。逆に、バージョン番号が高くても出所が不明なら、ビルド日とパッチの出所を確認してください。

コンテナイメージと Ingress Controller の確認方法

コンテナ環境では、ホストではなくイメージ内の Nginx を確認します。まず実際に組み込まれているバージョンを確認します。

1
2

docker run --rm your-nginx-image nginx -v
docker run --rm your-nginx-image nginx -V

ベースイメージが更新されているかも確認してください。イメージが Debian、Ubuntu、Alpine、またはディストリビューションパッケージを元に構築されている場合は、該当ディストリビューションのセキュリティアドバイザリとパッケージ changelog に戻って判断します。古いイメージを再起動するだけでは意味がありません。イメージ自体の再ビルドまたは置き換えが必要です。

Kubernetes Ingress では、次の 3 点を同時に確認します。

Ingress Controller プロジェクトが CVE-2026-42945 に関する advisory または修正版を公開しているか。
現在クラスタで実行されている controller イメージの digest が実際に更新されているか。tag だけの変更では不十分です。
controller 内蔵の Nginx バージョン、ビルドパラメータ、テンプレート設定に高リスクの rewrite ルールが残っていないか。

まず実行中のイメージを確認します。

1
2

kubectl -n ingress-nginx get pods -o wide
kubectl -n ingress-nginx describe pod <pod-name> | grep -i image

クラウド事業者のマネージド Ingress やゲートウェイを使っている場合は、該当クラウドサービスのアドバイザリも確認してください。マネージドコンポーネントは通常、ユーザーが自分で apt upgrade して修正できるものではありません。事業者の修正を待つか、修正済みバージョンへ切り替える必要があります。

重点的に確認すべき rewrite 設定

この脆弱性は rewrite 設定に関係します。まず Nginx 設定を検索します。

1
2

grep -R "rewrite" /etc/nginx -n
grep -R "\\$[0-9]" /etc/nginx -n

次のようなパターンに注意します。

`1`	`rewrite ^/old/(.*)$ /new/$1? permanent;`

ここでの $1、$2 のような名前なしキャプチャと、置換先に含まれる ? は、公式説明にある重要な条件の一部です。特に次のような書き方を確認します。

ある rewrite の後に別の rewrite、if、または set が続く。
正規表現で (.*) や (.+) のような広いキャプチャを使い、出力先で $1 や $2 を使っている。
rewrite の出力先に ? があり、クエリパラメータの追加または破棄に使っている。
rewrite の入力が公開パス、Host、URI、パラメータ、または上流が制御できる値に由来する。
管理パネル、ゲートウェイ、Ingress annotation、テンプレートが自動生成した rewrite ルール。

短時間でアップグレードできない場合は、一時的な緩和策を取ります。

複雑な rewrite ルールを減らす。
名前なしキャプチャを、より明確な名前付きキャプチャへ変更する。
置換文字列内で不要な ? を連結しない。
高リスク入口に WAF またはリバースプロキシルールを追加する。
ASLR が有効であることを確認する。
Nginx worker の実行権限を下げ、systemd sandbox、SELinux/AppArmor などの強化状態を確認する。

これらは緩和策であり、パッチの代替ではありません。

修正の優先順位

露出面に応じて優先順位を付けます。

公開入口の Nginx。
リバースプロキシ、API Gateway、エッジゲートウェイ。
マルチテナント環境の Nginx。
Kubernetes Ingress Controller。
Plesk、管理パネル、クラウドマーケットプレイスのイメージなど、Nginx を同梱するコンポーネント。
内部ネットワーク上でも重要業務を担う Nginx。

アップグレード後の確認：nginx -t、reload、worker 状態

更新後は、パッケージマネージャーの成功表示だけで終わらせないでください。設定、プロセス、実際のバイナリがすべて切り替わっていることを確認します。まず設定を検証します。

`1`	`nginx -t`

エラーがなければ、滑らかに reload します。

`1`	`systemctl reload nginx`

パッケージ更新でバイナリが置き換わった場合は、古い worker が終了していることを確認します。

`1`	`ps aux \| grep nginx`

master プロセスの起動時刻やバイナリパスも確認し、実行中のサービスが古いプロセスのまま残っていないことを見ます。必要ならメンテナンス時間を設けてサービスを再起動し、古い worker や古いコンテナがリクエストを処理し続けないようにします。

コンテナと Ingress 環境では、新しいイメージのロールアウトが実際に完了していることも確認します。

1
2

kubectl -n ingress-nginx rollout status deployment/<deployment-name>
kubectl -n ingress-nginx get pods -o wide

確認の要点は「コマンドを実行したか」ではなく、「修正を含む Nginx プロセスが本番トラフィックを処理しているか」です。

同じ Nginx 修正バッチを無視しない

nginx.org が同日に公開した 1.30.1 と 1.31.0 は、CVE-2026-42945 だけを修正したわけではありません。リリース情報には HTTP/2 request injection、SCGI/uWSGI buffer overread、charset module buffer overread、HTTP/3 address spoofing、OCSP resolver use-after-free なども挙げられています。

つまり、本番環境では単一 CVE に対する一時ルールだけで済ませるべきではありません。この Nginx のセキュリティ更新全体を、まとめてアップグレード対象として扱うべきです。

まとめ

CVE-2026-42945 の要点は、「すべての Nginx が即座に乗っ取られる」という話ではありません。rewrite モジュールに長期間存在していたメモリ安全性の脆弱性であり、特定の設定では未認証リクエストから発動できます。最も直接的な結果は worker のクラッシュと再起動です。ASLR が無効な環境など、弱い環境ではコード実行リスクが高くなります。

運用側の対応順序はシンプルです。

Nginx の入手元とバージョンを確認する。
ディストリビューション、F5、nginx.org、クラウド事業者のアドバイザリを見る。
修正を含むバージョンまたはディストリビューションのセキュリティパッケージへできるだけ早く更新する。
複雑な rewrite 設定、特に $1、$2、? の組み合わせを確認する。
ASLR、権限分離、サービス reload 状態を確認する。

見出しは怖くても、修正は冷静に進めるべきです。まず露出面を確認し、次にアップグレードし、その後で高リスクな rewrite ルールを整理します。

参考リンク

Nginx のレート制限設定：高頻度の 404・400 スキャンリクエストに rate limit をかける

Fri, 01 May 2026 05:41:31 +0800

Web サイトのログに突然大量の 404 や 400 が出る場合、原因は通常ユーザーがリンクを押し間違えたことではなく、自動スキャナーが .env、.git、wp-admin、phpmyadmin、xmlrpc.php といったパスを探っていることが多いです。

この種のリクエストには、いくつか問題があります。

access log が急速に大きくなる
error log が意味の薄い記録で埋まる
静的サイトやリバースプロキシの接続が無効なリクエストに使われる
本当に見るべき問題がスキャンノイズに埋もれる

Nginx では limit_req と limit_conn を使って制限できます。ただし先に一点だけ重要です。Nginx は「レスポンスステータスが 404 または 400 だったら制限する」という処理を標準機能だけで直接行うことはできません。レート制限はレスポンス生成前に行われるためです。

実際には、404 / 400 を生みやすいスキャンパス、異常なアクセス元、サイト全体の高頻度アクセスを事前に制限します。

基本方針

まずは三層に分けるのがおすすめです。

サイト全体にゆるいレート制限をかけ、単一 IP による高頻度アクセスを抑える。
よくあるスキャンパスには厳しめの制限をかけ、直接 404 を返す。
IP ごとの同時接続数を制限する。

より安全な導入順は、まずスキャンパスのルールと access_log off を入れて 1 日観察することです。それでもランダムパスの 404 が多い場合に、サイト全体の limit_req を追加します。

まず http でレート制限用 zone を定義する

limit_req_zone と limit_conn_zone は必ず http {} の中に置きます。個別サイトの server {} には置けません。

/etc/nginx/nginx.conf の http {} に直接書けます。

http {
    # 按客户端 IP 限速，普通页面请求
    limit_req_zone $binary_remote_addr zone=perip_general:20m rate=5r/s;

    # 更严格：疑似扫描路径
    limit_req_zone $binary_remote_addr zone=perip_scan:20m rate=1r/s;

    # 并发连接限制
    limit_conn_zone $binary_remote_addr zone=addr_conn:20m;

    include /etc/nginx/conf.d/*.conf;
    include /etc/nginx/sites-enabled/*;
}

別ファイルを作っても構いません。

`1`	`sudo nano /etc/nginx/conf.d/limit-zones.conf`

内容は次の通りです。

1
2
3

limit_req_zone $binary_remote_addr zone=perip_general:20m rate=5r/s;
limit_req_zone $binary_remote_addr zone=perip_scan:20m rate=1r/s;
limit_conn_zone $binary_remote_addr zone=addr_conn:20m;

前提として、nginx.conf の http {} 内で次が include されている必要があります。

`1`	`include /etc/nginx/conf.d/*.conf;`

次に server で zone を使う

サイト設定ファイルは通常 /etc/nginx/sites-enabled/www.example.com のような場所にあり、中身はたいてい server {} です。ここには limit_req_zone を書かず、前段で定義した zone だけを使います。

例：

server {
    root /srv/www/example.com;
    index index.html;
    server_name example.com www.example.com;
    access_log /var/log/nginx/example.com.access.log;
    error_log /var/log/nginx/example.com.error.log;

    # 全站温和限速：允许短时突发，降低误伤正常用户的概率
    limit_req zone=perip_general burst=30 nodelay;
    limit_conn addr_conn 20;

    # 对常见扫描路径严格限速，并关闭访问日志
    location ~* ^/(\.env|\.git|\.svn|wp-|wp/|adminer|phpmyadmin|pma|vendor|backup|config|server-status|cgi-bin|xmlrpc\.php) {
        access_log off;
        limit_req zone=perip_scan burst=5 nodelay;
        return 404;
    }

    # 你原来的 location /、listen ssl 等配置继续放这里
}

サイト全体のレート制限で通常アクセスを巻き込むのが心配なら、最初はスキャンパスだけにしてもよいです。

location ~* ^/(\.env|\.git|\.svn|wp-|wp/|adminer|phpmyadmin|pma|vendor|backup|config|server-status|cgi-bin|xmlrpc\.php) {
    access_log off;
    limit_req zone=perip_scan burst=5 nodelay;
    return 404;
}

各パラメータの意味

この行：

`1`	`limit_req_zone $binary_remote_addr zone=perip_general:20m rate=5r/s;`

意味は次の通りです。

limit_req_zone：リクエストのレート制限に使うカウント用 zone を定義する。
$binary_remote_addr：クライアント IP を制限キーにする。$remote_addr よりメモリ効率がよい。
zone=perip_general:20m：perip_general という名前の共有メモリ領域を 20m のサイズで作る。
rate=5r/s：IP ごとに平均で毎秒 5 リクエストまで許可する。

この行：

`1`	`limit_req_zone $binary_remote_addr zone=perip_scan:20m rate=1r/s;`

基本は同じですが、より厳しい設定です。

perip_scan：疑わしいスキャンパス専用。
rate=1r/s：IP ごとに毎秒 1 リクエストだけ許可する。

この行：

`1`	`limit_conn_zone $binary_remote_addr zone=addr_conn:20m;`

意味は次の通りです。

limit_conn_zone：同時接続数制限に使うカウント用 zone を定義する。
$binary_remote_addr：ここでもクライアント IP ごとに集計する。
zone=addr_conn:20m：addr_conn という名前の接続数カウント用共有メモリ領域を作る。

実際に同時接続数を制限するのは次です。

`1`	`limit_conn addr_conn 20;`

これは、各 IP の同時接続を最大 20 本にする、という意味です。

burst と nodelay の考え方

例えば：

`1`	`limit_req zone=perip_general burst=30 nodelay;`

次のように理解できます。

rate=5r/s：長期的な平均レートは毎秒 5 リクエスト。
burst=30：短時間の突発分として 30 リクエストまで許容する。
nodelay：平均レートを超えても burst 内なら待たせず処理し、burst を超えたら拒否する。

nodelay がない場合、Nginx は一部リクエストを遅延させてキューに入れようとします。通常の Web ページでは nodelay のほうが挙動を理解しやすいことが多いです。API や特に敏感なエンドポイントでは、実際の挙動に合わせて調整します。

よくあるエラー：limit_req_zone の配置場所が違う

次のようなエラーが出た場合：

`1`	`2026/04/30 21:33:48 [emerg] 2290771#2290771: "limit_req_zone" directive is not allowed here in /etc/nginx/sites-enabled/example.com:9`

これは、limit_req_zone を許可されていない場所に書いたという意味です。

よくある誤りは、server {} の中に置いてしまうことです。

server {
    root /srv/www/example.com;
    index index.html;
    server_name example.com www.example.com;

    limit_req_zone $binary_remote_addr zone=perip_general:20m rate=5r/s;
    limit_req_zone $binary_remote_addr zone=perip_scan:20m rate=1r/s;
    limit_conn_zone $binary_remote_addr zone=addr_conn:20m;
}

これは動きません。

覚え方はシンプルです。

limit_req_zone は「プールを定義する」ものなので http {} に置く。
limit_req は「プールを使う」ものなので server {} または location {} に置く。
limit_conn_zone は「接続プールを定義する」ものなので http {} に置く。
limit_conn は「接続プールを使う」ものなので server {} または location {} に置く。

明らかに異常な IP を一時的に拒否する

ログから、特定の IP が継続的にスキャンしていると確認できている場合は、一時的に拒否してもよいです。

deny 45.95.42.164;
deny 185.177.72.51;
deny 185.177.72.5;
deny 185.177.72.56;
deny 185.177.72.58;

この種の deny は server {} にも、特定の location {} にも置けます。長期的に残すかどうかは、誤検知リスクとアクセス元を見て判断します。

チェックしてリロードする

変更後はまず設定を確認します。

`1`	`sudo nginx -t`

問題がなければリロードします。

`1`	`sudo systemctl reload nginx`

いきなりサービスを再起動しないほうがよいです。reload なら Nginx が新しい設定を滑らかに読み込むため、リスクが低くなります。

推奨パラメータ

個人サイトや静的サイトなら、まずは次の値から始めるとよいです。

通常ページ：rate=5r/s から 10r/s
スキャンパス：rate=1r/s
スキャンパスの burst=5
サイト全体の burst=30
IP ごとの同時接続：10 から 20

通常ユーザーのアクセスが少ないサイトなら、さらに厳しくできます。画像、スクリプト、API リクエストが多いサイトでは、通常ページの制限を少し緩めて、本物のアクセスを巻き込まないようにします。

一番安全なのは段階的に入れる方法です。

まずスキャンパスに access_log off + return 404 を入れる。
次に perip_scan の厳しいレート制限を加える。
1 日ログを見る。
ランダムパスの 404 がまだ多い場合、サイト全体のゆるいレート制限を有効にする。

GoAccess最新版の自前ビルドと利用メモ: ソース導入からリアルタイムHTMLレポートまで

Wed, 29 Apr 2026 00:08:00 +0800

整理時点は 2026-04-29 です。
現時点で公式 README に載っている最新安定版は 1.10.2 です。

1. まずビルド依存を入れる

1
2
3

sudo apt-get update
sudo apt-get install -y build-essential wget tar \
  libncurses-dev libmaxminddb-dev libssl-dev zlib1g-dev

2. 最新ソースパッケージを取得する

cd /usr/local/src
sudo wget https://tar.goaccess.io/goaccess-1.10.2.tar.gz
sudo tar -xzvf goaccess-1.10.2.tar.gz
cd goaccess-1.10.2

3. ビルドオプションを設定する

`1`	`sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib`

リアルタイムHTMLレポートで TLS も使いたいなら、こちらでもよいです。

`1`	`sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib --with-openssl`

4. ビルドしてインストールする

1
2

sudo make
sudo make install

5. バージョンを確認する

1
2

goaccess --version
which goaccess

6. 端末でそのままレポートを見る

Nginx や Apache の一般的な combined ログなら、まずはこれでよいです。

`1`	`goaccess /var/log/nginx/access.log --log-format=COMBINED`

Apache のログパスならこちらです。

`1`	`goaccess /var/log/apache2/access.log --log-format=COMBINED`

7. 静的な HTML レポートを生成する

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html

カレントディレクトリに出しても構いません。

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o report.html

8. リアルタイム HTML レポートを生成する

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html

ポートを変えるなら:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html \
  --port=7891

ローカルホストだけにバインドするなら:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html \
  --addr=127.0.0.1

9. ログを追い続ける

`1`	`tail -f /var/log/nginx/access.log \| goaccess --log-format=COMBINED -`

ファイル先頭から読んで、そのままリアルタイムで追うなら:

tail -f -n +0 /var/log/nginx/access.log | goaccess \
  --log-format=COMBINED \
  -o report.html \
  --real-time-html -

10. 特定のリクエストだけを見る

たとえば firefox を含むリクエストだけ:

1
2

tail -f /var/log/nginx/access.log | grep -i --line-buffered 'firefox' | goaccess \
  --log-format=COMBINED -

たとえば 5xx と 3xx だけ:

1
2
3

tail -f -n +0 /var/log/nginx/access.log | awk '$9~/3[0-9]{2}|5[0-9]{2}/' | goaccess \
  --log-format=COMBINED \
  -o out.html -

11. 複数ログをまとめて解析する

`1`	`goaccess /var/log/nginx/access.log /var/log/nginx/access.log.1 --log-format=COMBINED`

圧縮済みと未圧縮をまとめて読むなら:

`1`	`zcat --force /var/log/nginx/access.log* \| goaccess --log-format=COMBINED -`

12. マルチスレッドを使う

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -o report.html \
  -j 4

chunk を大きくするなら:

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -o report.html \
  -j 4 \
  --chunk-size=8192

13. 増分処理

まず古いログを永続化しておく:

`1`	`goaccess /var/log/nginx/access.log.1 --log-format=COMBINED --persist`

次に現在のログを追加する:

`1`	`goaccess /var/log/nginx/access.log --log-format=COMBINED --restore --persist`

永続化済みデータだけを読む:

`1`	`goaccess --restore`

14. 自分なら最初に流すコマンド

sudo apt-get update
sudo apt-get install -y build-essential wget tar \
  libncurses-dev libmaxminddb-dev libssl-dev zlib1g-dev

cd /usr/local/src
sudo wget https://tar.goaccess.io/goaccess-1.10.2.tar.gz
sudo tar -xzvf goaccess-1.10.2.tar.gz
cd goaccess-1.10.2
sudo ./configure --enable-utf8 --enable-geoip=mmdb --with-zlib --with-openssl
sudo make
sudo make install

goaccess --version

goaccess /var/log/nginx/access.log \
  --log-format=COMBINED \
  -a \
  -o /usr/share/nginx/html/goaccess-report.html \
  --real-time-html

だいたいこれで十分です。
やることが明確なら、最新版をソースから入れて、まず --log-format=COMBINED と --real-time-html を通すところまで進めれば、あとはログパス、出力先、ポートを調整していくくらいです。

Ubuntu で Let's Encrypt 証明書を自動的に更新する (Certbot + Nginx)

Thu, 02 Apr 2026 00:00:00 +0000

Let’s Encrypt 証明書の有効期限は 90 日間のみです。オンラインサイトでは、証明書の有効期限切れによる HTTPS エラーを回避するために自動更新を構成する必要があります。

crontabを手動で追加する(推奨例)

更新タスクを自分で明示的に管理したい場合は、root ユーザーとして追加します。

`1`	`sudo crontab -e`

次の行を追加します (毎日午前 3 時に 1 回実行)。

`1`	`0 3 * * * certbot renew --pre-hook "systemctl stop nginx" --post-hook "systemctl start nginx" >> /tmp/certbot-renew.log 2>&1`

このコマンドの意味は次のとおりです。

0 3 * * *: 毎日 03:00 に実行
certbot renew: 有効期限が近づいている証明書を確認して更新します (実際には毎日更新されるわけではありません)。
--pre-hook: 80/443 ポートの競合を避けるために、更新前に Nginx を停止します (スタンドアロンモードで一般的)
--post-hook: 更新後のNginxの起動
>> /tmp/certbot-renew.log 2>&1: トラブルシューティングを容易にするためにログをファイルに追加します

最初に更新のシミュレーションを行うことをお勧めします

スケジュールされたタスクを追加した後、まずプロセスが利用可能かどうかを手動で確認します。

`1`	`sudo certbot renew --pre-hook "systemctl stop nginx" --post-hook "systemctl start nginx" --dry-run`

シミュレーションが正常に更新されたことを確認した後、長期実行のためにスケジュールされたタスクに渡されます。

共通の注意点

webroot または nginx プラグインを使用している場合、多くのシナリオで Nginx を停止する必要はありません。代わりに、更新後に構成をリロードすることもできます。

`1`	`certbot renew --deploy-hook "systemctl reload nginx"`

certbot renew は、証明書の有効期限が近づいた場合にのみ実際の更新を実行するため、1 日に 1 回実行するのが通常の一般的な方法です。
長期的な運用とメンテナンスを容易にするために、ログディレクトリを長期的に追跡可能な場所 (/var/log/letsencrypt/ など) に変更することをお勧めします。

Ubuntu および Nginx に GoAccess をインストールして Web サイトのステータスをリアルタイムで監視する方法

Thu, 14 Apr 2022 00:00:00 +0000

インストール後の様子

インストールGoAccess

システムに付属のものを使用してください。バージョンが古い場合があります。

`1`	`apt-get install goaccess`

deb.goaccess.io 公式最新安定版を使用してください

$ wget -O - https://deb.goaccess.io/gnugpg.key | gpg --dearmor | sudo tee /usr/share/keyrings/goaccess.gpg >/dev/null
$ echo "deb [signed-by=/usr/share/keyrings/goaccess.gpg] https://deb.goaccess.io/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/goaccess.list
$ sudo apt-get update
$ sudo apt-get install goaccess

update.sh ファイルを作成する

`1`	`goaccess /var/log/nginx/www.knightli.com.access.log -o /www/www.knightli.com/r.html --log-format=COMBINED`

/var/log/nginx/www.knightli.com.access.log は、http サーバーのアクセスログファイルのディレクトリです。
/www/www.knightli.com/r.html は、http サーバーの静的 Web ページのルートディレクトリとファイル名です。

crontabに追加し、アクセスログに従って1分ごとに生成する

crontab -e

# m h  dom mon dow   command
* * * * * ~/update.sh

ファイルにアクセスする

ブラウザ経由でhttp://www.knightli.com/r.htmlにアクセス

Certbot を使用して、無料で自動的に更新される Nginx 用の HTTPS 証明書を Ubuntu20.04 にインストールする方法

Tue, 02 Nov 2021 00:00:00 +0000

最終効果

インストールが完了すると、次の結果が得られます。

Nginx Web サービスの無料証明書をインストールする
証明書の有効期限が切れると、証明書を自動的に更新してインストールできます。更新プロセス中に手動介入は必要ありません。

インストールプロセス

ファイアウォールの設定

ファイアウォールがインストールされていない場合は、次のコマンドを使用してファイアウォールをインストールします。

1
2

sudo apt update
sudo apt install ufw

ファイアウォールは、ssh (ポート 22)、http (ポート 80)、https (ポート 443) のポート通信を開きます。

1
2
3

sudo ufw allow ssh
sudo ufw allow http
sudo ufw allow https

ファイアウォールを有効にする

`1`	`sudo ufw enable`

ファイアウォールのステータスを表示するには、次のコマンドを使用します。

`1`	`sudo ufw status`

Certbot をインストールする

まず snapd をインストールし、次に snapd を使用して Certbot をインストールします

sudo apt update
sudo apt install snapd
sudo snap install core
sudo snap refresh core
sudo apt remove certbot
sudo snap install --classic certbot

リンクの作成

`1`	`sudo ln -s /snap/bin/certbot /usr/bin/certbot`

Certbot を使用して証明書を取得し、インストールします

Certbot を実行して証明書を取得します
- 証明書を取得し、Nginx に自動的にインストールします (推奨) これが推奨される方法です。証明書を取得すると、Nginx 構成ファイルが自動的に変更され、証明書がインストールされます。設定は 1 つの簡単なステップで完了
1

sudo certbot --nginx
- 証明書を取得しますが、Nginx にインストールされませんこの方法では証明書のみを取得します。その後、証明書のインストールプロセスを完了するには、Nginx 構成ファイルを手動で変更する必要があります。
1

sudo certbot certonly --nginx

2.メールアドレスを入力 3. 利用規約に同意する 4. メーリングリストに登録することを選択できます 5. ドメイン名を入力します 6. 次に、Certbot は Let’s Encrypt と通信して証明書を要求します。

操作が成功すると、Certbot は証明書が有効であることを確認します。また、証明書とキーチェーンが保存されているディレクトリと有効期限に関する情報も表示されます。証明書は通常、90 日後に期限切れになります。

Requesting a certificate for www.example.com
Performing the following challenges:
http-01 challenge for www.example.com
Waiting for verification...
Cleaning up challenges
Deploying Certificate to VirtualHost /etc/nginx/sites-enabled/default
Redirecting all traffic on port 80 to ssl in /etc/nginx/sites-enabled/default

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Congratulations! You have successfully enabled https://www.example.com
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
...
- Congratulations! Your certificate and chain have been saved at:
/etc/letsencrypt/live/www.example.com/fullchain.pem
Your key file has been saved at:
/etc/letsencrypt/live/www.example.com/privkey.pem
our certificate will expire on 2021-05-29.

Certbot を使用して TLS/SSL 証明書を更新する

インストール後、Certbot は証明書を自動的に更新するように構成されます。更新された証明書を手動で要求したり、Certbot を再度実行したりする必要はありません。 Certbot はすべての証明書を自動的に更新します。

Nginx njs スクリプト、API サービスのシンプルな実装

Thu, 03 Dec 2020 00:00:00 +0000

NJS スクリプトとは何ですか?

njs は、nginx の機能を拡張できる JavaScript 言語のサブセットです。 njs は、ECMAScript 5.1 (厳密モード) および特定の ECMAScript 6 以降の拡張機能に準拠するように作成されました。コンプライアンスは依然として進化しています。簡単に言うと、JavaScriptを使ってnginxで簡単なサーバープログラムを書くことです。

njs スクリプトを使用する理由

njs スクリプトの利点

jsを使用して開発されているため、開発が簡単です。迅速な開発を促進します
導入は簡単で、nginx さえあれば、他のものを導入する必要がなく、サーバーのパフォーマンス要件が非常に低く、他のサービスと共存するのが簡単です。
API レベルで安定した状態を維持でき、将来フロントエンドに影響を与えることなく他の実装に変換できます。

njs スクリプトは、プロジェクトの初期段階でサーバー側の機能が必要だが、迅速に開発および展開できる単純な実装のみを希望し、他の側面に対する要件が必要ない人に適しています。しかし、私は API が安定したままであることを望みますし、将来サーバーがアップグレードされたときにフロントエンドを変更する必要がないことを望みます。

njs スクリプトの例

簡単な例を通じて njs スクリプトを体験してください。この例の API は次のとおりです。 http://xxx.xxx.xxx/fetch_data?offset=?&limit=? サーバーからデータを取得する場合、offset は開始位置、limit は一度に取得する量です。リストページやウォーターフォールページでの表示には、同様の API が必要になることがよくあります。一般的な実装では、データをデータベースに置き、SQL を通じてデータを取得し、それを表示のためにフロントエンドに送信します。一般に、これを行うにはアプリケーションサーバーとデータベースが必要ですが、一部のプロジェクトでは必要なく、開発と展開が複雑すぎます。

環境インストール構成

apt-getを使用して直接ubuntuにインストールしました。

Add the following line to /etc/apt/sources.list:
deb https://nginx.org/packages/ubuntu/ focal nginx
Install GPG key of the repository:

# wget https://nginx.org/keys/nginx_signing.key
# sudo apt-key add nginx_signing.key
Update the package index:
# sudo apt-get update
Install nginx-module-njs deb package:
# sudo apt-get install nginx-module-njs

nginxの設定ファイルは以下の通りです

js_import /path/to/jsfile.js;   //你的JS文件的路径
server {
    server_name xxxx.com;
    access_log /var/log/nginx/xxxx.com.access.log;
    error_log /var/log/nginx/xxxx.com.error.log info; //使用 info 级别 可以打出log，便于开发中的调试
    root /path/to/your/html;

    location /xxxxx {
        add_header  Content-Type 'application/json';
        js_content jsfile.your_func_name;
    }
}

JSファイル

function your_func_name(r) {
  var offset = 0; //default offset
  var limit = 20; //default limit

  // r.log('r.args.offset=' + r.args.offset);
  if(Number.isInteger(+r.args.offset)) {
    offset = parseInt(r.args.offset);
  }
  r.log('offset=' + offset);

  // r.log('r.args.limit=' + r.args.limit);
  if(Number.isInteger(+r.args.limit)) {
    limit = parseInt(r.args.limit);
  }
  r.log('limit=' + limit);

  var fs = require('fs').promises;
  fs.readFile("/path/data.json").
    then((data) => {
      var json = JSON.parse(data.toString());
      var output = [];
      for (var i = offset; (i < json.length) && (i < offset + limit); i++) {
        r.log('i=' + i);
        output.push(json[i]);
      }
      r.return(200, JSON.stringify(output));
    }).catch((error) => r.return(400, error));
}

export default { your_func_name };

r.args はリクエスト内のパラメータを取得できます。たとえば、r.args.offset はリクエスト (http://xxx.com/api_name?offset=1) のオフセットパラメーターの値を取得できます。
r.logはログを出力することができ、nginxで設定したファイルにログが出力されます。ログレベルに注意してください。 error_log /var/log/nginx/xxxx.com.error.log 情報; //情報レベルを使用してログを記録します。これは開発中のデバッグに便利です
r.return は結果を返すことができます
インスタンス内のデータは json ファイルに保存され、API はオフセットと制限を通じてその一部を出力します。
JS ファイルを変更した後、それを有効にするために nginx を再起動する必要があります。

data.json

    [
        {
            "a": "v1",
            "b": "v2",
            "c": "v3"
        },
        {
            "a": "v1",
            "b": "v2",
            "c": "v3"
        },
        {
            "a": "v1",
            "b": "v2",
            "c": "v3"
        }
    ]

Ubuntu 20.04 に Nginx、PHP、Maridb、Wordpress をインストールする

Thu, 08 Oct 2020 00:00:00 +0000

Nginx、PHP、MariaDB をインストールする

1
2
3

  $ sudo apt update
  $ sudo apt install nginx mariadb-server mariadb-client php-fpm php-mysql
  $ sudo apt-get install php-gd //如果不安装，在裁剪图像时会出错。

MariaDB を構成する

$ sudo mysql
MariaDB [(none)]> CREATE DATABASE wordpress_db;
MariaDB [(none)]> CREATE USER 'wordpress_user'@'localhost' IDENTIFIED BY 'my_password';
MariaDB [(none)]> GRANT ALL PRIVILEGES ON wordpress_db.* to wordpress_user@'localhost';
MariaDB [(none)]> FLUSH PRIVILEGES;
MariaDB [(none)]> exit

nginxの設定

`1`	`$ sudo nano /etc/nginx/sites-available/wordpress`

設定ファイルのテンプレート:

server {
    listen 80;
    listen [::]:80;
    root /var/www/wordpress;
    index index.php;
    server_name 127.0.0.1;   //这里修改成你的域名
    location / {
          try_files $uri $uri/ =404;
    }
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;  //使用 php --version 确定你的php版本
    }
}

1
2
3

$ sudo rm /etc/nginx/sites-enabled/default
$ sudo ln -s /etc/nginx/sites-available/wordpress /etc/nginx/sites-enabled/wordpress
$ sudo systemctl restart nginx

WordPress をダウンロードしてインストールします

1
2
3

$ wget -O /tmp/wordpress.tar.gz https://wordpress.org/latest.tar.gz
$ sudo tar -xzvf /tmp/wordpress.tar.gz -C /var/www
$ sudo chown -R www-data.www-data /var/www/wordpress

ブラウザのページ構成

ブラウザ http://127.0.0.1 を開き、ページ構成に従います。