Question 1

Ubuntu 20.04 Focal에서 GoAccess apt repository 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

초기 페이지 로드 시 "TypeError: s.split is not a function" 오류와 함께 GoAccess HTML 보고서가 비어 있는 문제를 어떻게 수정하나요?

Accepted Answer

이것은 패널 항목에 빈 data 값이 있을 때 GoAccess 1.10.1에 영향을 미칩니다. 예를 들어 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

GoAccess Debian 리포지토리를 미러링할 때 Aptly 오류 "file already exists and is different"를 어떻게 해결하나요?

Accepted Answer

이것은 GoAccess가 패키지 버전을 변경하지 않고 bullseye/bookworm용 기존 1.10.2 .deb 파일을 교체했을 때 발생하며, 그래서 Aptly가 동일한 파일 이름에 대해 다른 콘텐츠를 감지했습니다. 이는 새로운 Ubuntu 배포판을 추가하는 동안 우발적인 저장소 재빌드로 인해 발생했으며 예상된 패키지 동작이 아닙니다. 해결 방법으로, Aptly의 replacement override를 사용하여 업데이트/게시하십시오. 예: 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 # Remove these for plain HTTP from NGINX to GoAccess: # 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`가 표시되어야 합니다. GoAccess에 `ssl-cert`와 `ssl-key`가 구성된 상태를 유지하는 경우에만 `proxy_pass https://...`를 사용하십시오. 그렇지 않으면 NGINX가 TLS 리스너에 일반 HTTP를 전송하게 되어 `400 Bad Request`가 발생할 수 있습니다.

Question 5

Apache mod_cache HIT/MISS 상태를 액세스 로그에 기록하는 방법

Accepted Answer

옵션 1: mod_cache의 내장 cache-status 환경 변수를 사용합니다. LogFormat 지시어에 `%{cache-status}e`를 추가하면 `cache hit`, `cache miss: ...`, `conditional cache hit: ...`(재검증), `cache invalidated ...`와 같은 값이 로깅됩니다. 옵션 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

주요 기능

할 수 없는 것

사용 사례

태그

시작하기

유사한 프로젝트