Question 1

Ubuntu 20.04 FocalでGoAccess aptリポジトリの404 Not Foundエラーを修正するにはどうすればよいですか？

Accepted Answer

404 は、Ubuntu 20.04 Focal が 2025 年 5 月に標準サポートを終了した後、GoAccess リポジトリでサポートされなくなったために発生します。Ubuntu をサポート対象のリリース、たとえば 22.04 Jammy や 24.04 Noble にアップグレードしてから、リポジトリを再設定してください:

lsb_release -cs
echo "deb https://deb.goaccess.io/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/goaccess.list
wget -O - https://deb.goaccess.io/gnugpg.key | sudo gpg --dearmor -o /etc/apt/keyrings/goaccess.gpg
sudo apt update
sudo apt install goaccess

OS をアップグレードせずに focal をより新しいコードネームに単に置き換えないでください。依存関係の不一致を引き起こす可能性があります。deb.goaccess.io が全員に対して一時的に到達不能な場合は、短時間のメンテナンスかもしれないので、数分後に再試行してください。ただし、focal Release に対する 404 が継続する場合は、削除された/サポートされていないリリーススイートを示しています。

Question 2

GoAccess HTML レポートが初回ページ読み込み時に「TypeError: s.split is not a function」で空白になるのをどう修正すればよいですか？

Accepted Answer

これは、GoAccess 1.10.1 で、パネル項目の data 値が空の場合、たとえば Referer がない、User-Agent が不明、Host ヘッダーがない場合に影響します。JavaScript では "" は falsy であるため、hashCode(dataItem.data || dataItem) は dataItem オブジェクト全体を hashCode() に渡し、その結果 s.split('') で失敗します。 HTML レポートテンプレートの JavaScript にパッチを適用してから、レポートを再生成します: 1. hashCode 呼び出し箇所の falsy フォールバックを置き換えます: // Before hashCode(dataItem.data || dataItem) // After hashCode(dataItem.data != null ? String(dataItem.data) : JSON.stringify(dataItem)) 2. hashCode が空文字列と非文字列値を安全に受け入れるようにします: hashCode: function(s) { s = s == null ? '' : typeof s === 'string' ? s : JSON.stringify(s); return (s.split('').reduce(function(a, b) { a = ((a << 5) - a) + b.charCodeAt(0); return a & a; }, 0) >>> 0).toString(16); } 3. GoAccess HTML レポートを再生成するか、同じ変更を生成済みの report.html に直接適用して再読み込みします。一時的な回避策として、既存のレポートで Panel Option を変更すると再レンダリングがトリガーされますが、正しい初期レンダリングには JavaScript のパッチが必要です。

Question 3

Aptly のエラー「file already exists and is different」を、GoAccess の Debian リポジトリをミラーリングする際に修正するにはどうすればよいですか？

Accepted Answer

これは、GoAccess がパッケージバージョンを変更せずに bullseye/bookworm 向けの既存の 1.10.2 .deb ファイルを置き換えたときに発生し、そのため Aptly が同じファイル名に対して異なる内容を検出しました。これは、新しい Ubuntu ディストリビューションを追加する際の偶発的なリポジトリ再構築によって引き起こされたもので、想定されるパッケージ動作ではありません。回避策として、Aptly の置換オーバーライドを使用して更新/公開します。例: aptly publish update -force-replacements [[]]。これは、更新されたアップストリームパッケージを信頼できる場合にのみ使用してください。そうでない場合は、新しい GoAccess バージョンのリリースを待つか、アップストリームリポジトリが修正された後にミラーを再作成してください。

Question 4

NGINX 1.29.7 TLSリバースプロキシの背後でGoAccessのWebSocketが400 Bad Requestエラーになる、またはライブ更新が行われない問題を解決するにはどうすればよいですか?

Accepted Answer

NGINX で TLS を終端し、WebSocket のアップグレードを明示的にプロキシしてください。`proxy_pass http://` を使用している間は、GoAccess 自身の TLS を有効にしないでください。 1. `goaccess.conf` では、公開用の `wss://` URL はそのままにし、GoAccess 自体が直接 TLS を提供している場合を除き、内部の TLS 証明書オプションを削除してください： ```conf ws-url wss://stats.example.com/wss # NGINX から GoAccess への平文 HTTP 用に、以下は削除してください： # ssl-cert /docker-host/etc/ssl/goaccess/example.com.crt # ssl-key /docker-host/etc/ssl/goaccess/example.com.key ``` 2. NGINX を次のように設定してください： ```nginx location /wss { proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_set_header Host $host; proxy_set_header X-Forwarded-Proto $scheme; proxy_connect_timeout 7d; proxy_send_timeout 7d; proxy_read_timeout 7d; proxy_pass http://example-goaccess-1:7890; } ``` 不足している重要なディレクティブは `proxy_http_version 1.1`、`Upgrade`、`Connection: upgrade` です。`200 OK` レスポンスは接続がアップグレードされなかったことを意味します。WebSocket のハンドシェイクは `101 Switching Protocols` を返す必要があります。 3. GoAccess を再起動し、NGINX をリロードしてください： ```bash docker compose up -d --force-recreate docker exec nginx -t docker exec nginx -s reload ``` 4. ハンドシェイクを確認してください： ```bash curl -i -N \ -H 'Connection: Upgrade' \ -H 'Upgrade: websocket' \ -H 'Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==' \ -H 'Sec-WebSocket-Version: 13' \ https://stats.example.com/wss ``` `HTTP/1.1 101 Switching Protocols` が表示されるはずです。 `proxy_pass https://...` は、GoAccess で `ssl-cert` と `ssl-key` の設定を維持している場合にのみ使用してください。それ以外の場合、NGINX は TLS リスナーに平文の HTTP を送信することになり、`400 Bad Request` が発生する可能性があります。

Question 5

Apache mod_cache の HIT/MISS ステータスをアクセスログに記録する方法

Accepted Answer

Option 1: mod_cacheの組み込みcache-status環境変数を使用します。LogFormatディレクティブに`%{cache-status}e`を追加すると、`cache hit`、`cache miss: ...`、`conditional cache hit: ...`（再検証）、`cache invalidated ...`などの値がログに記録されます。Option 2: Apacheの設定で`CacheHeader on`を指定してCacheHeaderディレクティブを有効にします。これにより`X-Cache`レスポンスヘッダーが追加され、LogFormatで`%{X-Cache}o`を使ってログに記録すると、`HIT from hostname`や`MISS from hostname`のようなエントリーが生成されます。注意点：X-Cacheを使う方法はCacheHeaderが有効になっている間のみ機能し、その出力形式は将来のApacheバージョンで変更される可能性があるため（Apache bug 64648を参照）、`%{cache-status}e`の方がより安定した選択肢です。

GoAccess

主な機能

できないこと

使用例

タグ

はじめ方

類似プロジェクト