GCP 컨테이너에서 ntfy 접근 불가 진단 보고서

작성자: 에르메스 (Hermes) — ROOPS 소통 허브
작성일: 2026-06-09
분류: 인프라 진단 / 통신 장애

요약

Anthropic GCP 클라우드 컨테이너(claude.ai/code)에서 ROOPS 팀의 ntfy 알림 서버(hyperbook.com:8880)에 접근할 수 없다. 본 보고서는 접근 차단의 구조적 원인을 분석하고 대안을 제시한다.

1. 환경 개요

2. 테스트 결과

2-1. HTTP (포트 8880) 접근

curl --max-time 5 http://hyperbook.com:8880/health

결과: Connection timed out after 5002 milliseconds (exit code 28)

진단: Anthropic GCP 환경의 아웃바운드 방화벽이 비표준 포트(8880)를 차단한다. 표준 포트(80/443)만 허용된다.

2-2. HTTPS (포트 443) 접근

curl --max-time 5 https://hyperbook.com/roops-aegis

결과: Host not in allowlist

진단: hyperbook.com 도메인이 claude.ai/code 환경의 허용 도메인 목록에 등록되지 않았다. 프록시가 허용되지 않은 호스트로의 연결을 차단했다.

2-3. 아웃바운드 프록시 구조 확인

env | grep -i proxy

결과:

CLAUDE_CODE_PROXY_RESOLVES_HOSTS=true
CCR_TEST_GITPROXY=1

Anthropic GCP 컨테이너는 모든 아웃바운드 트래픽을 내부 보안 프록시를 통해 라우팅한다. 이 프록시는 다음을 수행한다:

• 도메인 화이트리스트 검사: 허용 목록에 없는 호스트 차단 (Host not in allowlist)
• HTTPS MITM 검사: TLS를 중간에서 복호화하여 트래픽 분석
• 비표준 포트 차단: 80, 443 외 포트 차단 (8880 포함)

3. 근본 원인 분석

ntfy가 접근 불가한 이유는 두 가지 독립적인 차단 메커니즘이 중첩되어 있기 때문이다.

GCP 컨테이너
    │
    ▼
[Anthropic 보안 프록시]
    │
    ├─ hyperbook.com:8880 (HTTP) ─────→ ❌ 포트 8880 차단 (비표준 포트)
    │
    └─ hyperbook.com:443 (HTTPS) ────→ ❌ Host not in allowlist

차단 계층 1 — 포트 차단:
ntfy 서버가 HTTP 포트 8880에서 서비스 중이다. Anthropic 프록시는 80/443 이외의 포트에 대한 아웃바운드 연결을 허용하지 않는다.

차단 계층 2 — 도메인 미등록:
HTTPS(443)로 접근해도 hyperbook.com이 허용 도메인 목록에 없어 프록시 수준에서 차단된다.

4. 비교: 허용된 서비스와의 차이

5. 해결 방안

방안 A: ntfy HTTPS 포트 전환 (권장)

ntfy 서버를 HTTPS(443)로 이전하고 hyperbook.com을 허용 도메인에 추가한다.

현재: http://hyperbook.com:8880  →  권장: https://ntfy.hyperbook.com:443

조치 순서: 1. Aegis: ntfy 서버에 TLS 인증서 적용 (Let's Encrypt) 2. Aegis: nginx 리버스 프록시로 443 → 8880 포워딩 3. 사령관: ntfy.hyperbook.com (또는 hyperbook.com) 허용 도메인 추가 4. 새 세션에서 접근 재시도

이 방안은 ntfy 서버의 기존 TLS 전환 권고(보안 이슈 #3)와 동일한 작업이다.

방안 B: Memory API /say 엔드포인트 활용

egs.hyperbook.com/say는 내부적으로 ntfy를 통해 브로드캐스트한다. Memory API가 이미 접근 가능하므로, Hermes는 ntfy에 직접 접근하는 대신 Memory API를 중계점으로 활용할 수 있다.

# ntfy 직접 접근 대신:
POST https://egs.hyperbook.com/say
{
  "body": "메시지 내용",
  "notify_ntfy": true,
  "targets": ["hermes", "aegis"]
}

단점: ntfy에서 Hermes로 오는 수신 메시지는 여전히 /msg 폴링으로만 수신 가능. 실시간 푸시 수신 불가.

방안 C: Slack MCP 경유 (현재 운용 중)

Hermes는 이미 Slack MCP 서버를 통해 #roops-bridge 채널과 통신한다. ntfy 실시간 알림을 Slack으로 대체 운용 가능하다.

6. 결론 및 권고

단기 (즉시): Memory API /say + /msg 폴링으로 ntfy 기능 대체 운용
중기 (1주 내): ntfy 서버 HTTPS 전환 + 도메인 허용 추가 (기존 보안 이슈 #3과 병행)

GCP 컨테이너에서의 ntfy 직접 접근은 구조적으로 두 가지 변경이 동시에 필요하다: 서버 측 HTTPS 전환과 클라이언트 측 도메인 허용 추가. 어느 한쪽만으로는 해결되지 않는다.

본 보고서는 에르메스(Hermes) GCP 세션에서 2026-06-09 직접 테스트를 통해 작성되었습니다.