[태그:] WordPress

  • 24시간 안에 봇이 온다 — 도메인 공개 전 보안 P0

    24시간 안에 봇이 온다 — 도메인 공개 전 보안 P0

    24시간 안에 봇이 온다 — 도메인 공개 전 보안 P0

    셀프호스팅 구축기 8편. 도메인 띄우기 전에 반드시 끝내야 하는 25분.


    TL;DR

    • WordPress 도메인 공개 = 24시간 안에 brute force 봇이 옴. 통계적 사실
    • 25분 작업으로 99% 차단: ① 사용자명 admin 회피 ② xmlrpc 차단 ③ wp-login 슬러그 변경
    • 이 셋이 보안 P0. 도메인 띄우기 전에 끝낸다
    • Wordfence·2FA는 P1 (도메인 띄운 후 추가)

    1. 첫 24시간의 진실

    WordPress 사이트가 인터넷에 노출되면 첫 24시간 안에:

    공격 빈도 대상
    /wp-login.php brute force 시간당 수천 회 관리자 비번
    /xmlrpc.php pingback amp 끊임없음 DDoS 증폭
    알려진 플러그인 취약점 스캔 끊임없음 옛 버전 플러그인
    SQL injection 시도 자동 봇 ?id=1 OR 1=1 URL
    User enum (?author=1) 자동 봇 사용자명 알아내기

    이걸 막을 게 아니라 표면 자체를 없애는 게 P0.


    2. P0 — 보안 3종 셋업

    

    3. ① 사용자명 admin 회피

    WordPress 설치 마법사가 첫 사용자 만들 때 admin이라고 입력하지 마세요. 봇 brute force 1순위 타겟.

    좋은 예: jamjam, sailor904, 본인 닉
    나쁜 예: admin, administrator, root, wpadmin
    

    이미 admin으로 만들었으면 wp-cli로 새 사용자 생성 후 admin 권한 박탈 또는 삭제:

    wp user create newname [email protected] --role=administrator --user_pass=$(openssl rand -base64 24) --allow-root
    wp user delete admin --reassign=newname --allow-root
    

    4. ② xmlrpc.php 차단 — mu-plugin

    /xmlrpc.php는 WordPress 옛 API. 거의 안 쓰임 (Jetpack 사용자만). 봇이 brute force amplification (한 번 요청으로 비번 1000개 시도)에 악용.

    /var/www/html/wp-content/mu-plugins/disable-xmlrpc.php:

    <?php
    /**
     * Plugin Name: Disable XML-RPC
     * Description: Block xmlrpc.php to reduce attack surface.
     */
    if (!defined('ABSPATH')) exit;
    
    add_filter('xmlrpc_enabled', '__return_false');
    add_filter('wp_headers', function ($headers) {
        unset($headers['X-Pingback']);
        return $headers;
    });
    add_filter('xmlrpc_methods', function ($methods) {
        unset($methods['pingback.ping']);
        unset($methods['pingback.extensions.getPingbacks']);
        return $methods;
    });
    add_action('init', function () {
        $uri = $_SERVER['REQUEST_URI'] ?? '';
        if (stripos($uri, '/xmlrpc.php') !== false) {
            status_header(403);
            exit('xmlrpc disabled');
        }
    });
    

    검증:

    curl -I http://localhost:8090/xmlrpc.php
    # HTTP/1.1 403  ← 성공
    

    5. ③ wp-login 슬러그 변경

    /wp-login.php는 모든 WordPress 사이트가 똑같이 갖는 로그인 URL. 봇이 처음 들어와서 자동으로 칠 URL. 이걸 다른 슬러그로 숨김.

    플러그인 wps-hide-login 설치:

    wp plugin install wps-hide-login --activate --allow-root
    wp option update whl_page starport --allow-root
    

    starport는 사장님이 정한 비밀 슬러그. 추측 어려운 단어 + 본인 기억하기 쉬운 거. 예: byeolgorae-gate, secret-door-2026, starport.

    검증:

    curl -I -L http://localhost:8090/wp-login.php
    # 301 redirect → 가짜 URL (봇 헛걸음)
    
    curl -I -L http://localhost:8090/wp-admin/
    # 404 (로그아웃 상태에선 admin 페이지 자체가 없는 척)
    
    curl -I -L http://localhost:8090/starport/
    # 200 (사장님만 아는 로그인 페이지)
    

    사장님이 슬러그 잊으면 본인도 못 들어옴. 즐겨찾기·메모 필수.


    6. 결과 — 봇 입장에서

    공격 차단 후 응답
    GET /wp-login.php 301 → 가짜 URL → 봇이 거기서 시도 → 영원히 실패
    POST /xmlrpc.php 403 즉시 차단. amplification 불가
    GET /wp-admin/ 404. 관리 페이지 자체가 없는 척
    사용자명 brute force admin 시도 → 우리 사이트엔 admin 없음
    ?author=1 user enum Rank Math가 자동 차단 (Disable Author Archives)

    봇이 들이는 자원 = 사장님 사이트에서 얻는 게 0.


    7. P0 vs P1 vs P2 — 우선순위

    단계 작업 시점
    P0 (필수, 도메인 공개 전) 사용자명·xmlrpc·wp-login 슬러그 이번 25분
    P1 (도메인 띄운 직후) Wordfence 위자드 + 2FA 사장님 GUI 작업
    P2 (월 1회) 플러그인 보안 업데이트 + WPA(취약점 스캔) 운영 단계

    P0 안 끝내고 도메인 띄우면 — 봇이 24시간 안에 와서 brute force 시작. 셋업 안 됐어도 어차피 못 뚫지만, 로그에 brute force 시도가 쌓이고 미니PC CPU 잡아먹음. 미리 막는 게 정신 위생.


    8. 함정

    함정 1. mu-plugin 자동 활성

    mu-plugins는 일반 플러그인 위에서 강제 실행 (mu = Must Use). 따라서 xmlrpc 차단처럼 절대 비활성되면 안 되는 보안 정책은 mu-plugin이 맞는 곳.

    함정 2. WPS Hide Login slug 잊기

    whl_page 옵션을 DB에 직접 박아두기 때문에, 사장님이 슬러그 잊으면 본인도 못 들어옴. 복구 방법: wp option get whl_page --allow-root (미니PC SSH로) 또는 mu-plugin 임시 비활성.

    함정 3. 인증 후 자동 우회

    WPS Hide Login은 슬러그를 모르는 사람만 차단. 로그인된 세션은 그대로 /wp-admin/ 사용. 사장님이 한 번 로그인하면 그 이후 30분 동안 admin 페이지 자유.

    함정 4. 로그아웃 시 새 슬러그로 진입

    사장님이 로그아웃하면 다음 로그인은 /starport로. 즐겨찾기 갱신 필수.


    FAQ

    Q. 이미 도메인 공개해버렸는데 P0 안 했으면?
    지금 즉시 cloudflared 끄거나 Tailscale Funnel 해제 → P0 셋업 → 다시 공개. 5분.

    Q. Wordfence 위자드(P1)는 왜 P0 아닌가?
    P0는 표면 자체를 없애는 것. Wordfence는 표면이 있는 상태에서 공격을 탐지·차단. 보완재.

    Q. 슬러그를 /admin 으로 바꿔도 되나?
    /admin도 봇이 시도하는 흔한 슬러그. 추천 X. 본인만 떠올릴 수 있는 + 추측 어려운 단어.

    Q. 2FA 없어도 P0면 충분한가?
    충분 + 충분. 2FA는 비번 노출됐을 때 마지막 방패. P0 + 2FA = 사실상 무적.

    Q. xmlrpc 차단하면 Jetpack 못 쓰나?
    Jetpack 일부 기능 X. Jetpack 자체가 없으면 무관. 우리 별고래는 Jetpack 안 씀.


    다음 편 예고

    9편 — 보이지 않는 다리: Cloudflare Tunnel. 드디어 도메인을 미니PC에 연결. 공유기 포트 안 열고, 미니PC IP 안 들키고, WAF·DDoS·CDN까지 무료로.


    한 줄 정리

    WordPress 도메인 공개 = 24시간 안에 봇이 옴. 25분 P0 셋업(사용자명·xmlrpc·wp-login 슬러그)으로 99% 차단. 도메인 띄우기 전에 끝낸다.

  • 보이지 않는 다리 — Cloudflare Tunnel로 우리집 블로그 외부 노출하기

    보이지 않는 다리 — Cloudflare Tunnel로 우리집 블로그 외부 노출하기

    보이지 않는 다리 — Cloudflare Tunnel로 우리집 블로그 외부 노출하기

    셀프호스팅 구축기 9편. 도메인 산 다음, 우리집 컴퓨터까지 트래픽을 어떻게 끌어오나.

    ← 이전 편: 8편 — 24시간 안에 봇이 온다 (보안 P0)
    → 다음 편: 10편 — 블로그에 뭘 쓰면 안 되나 (개인정보 검열)

    TL;DR (한 화면 요약)

    • 문제: 우리집 미니PC에 WordPress를 띄웠는데, 산 도메인(sticknstone.org)을 외부에서 어떻게 연결하나
    • 옛 방식: 공유기 포트 열기 → 공인 IP DNS 등록 → SSL 갱신. 5가지 골치
    • 새 방식: Cloudflare Tunnel — 미니PC가 Cloudflare에 outbound로 다리를 미리 놓는다. 공유기 구멍 X, IP 노출 X
    • 도구: cloudflared 데몬을 Docker로 가동. 5분
    • 공짜 보너스: WAF·DDoS·CDN·SSL·트래픽 통계 전부 무료
    • 비용: 0원 (도메인 갱신비 연 $10 별도)

    1. 풀고 싶은 문제

    블로그(WordPress)는 우리집 미니PC에 띄워뒀다. 도메인(sticknstone.org)도 샀다. 그런데 이 둘이 어떻게 만나야 하나?

    평범한 길 (포트포워딩) 5가지 골치

    골치
    공유기 구멍 443번 포트 외부에 열면 평생 봇 공격
    공유 IP 통신사가 매번 바꿈. 자동 갱신 스크립트 필요
    우리집 위치 노출 IP만 알면 대략적 동네 추정 가능
    SSL 갱신 매 90일마다 Let’s Encrypt 직접
    트래픽 폭주 DDoS 맞으면 우리집 인터넷 마비

    2. 다른 길: 다리를 놓는다

    발상의 전환: 외부에서 우리집으로 들어오는 연결을 받지 말자. 대신 우리집에서 외부 어딘가로 나가는 연결을 미리 만들어두자.

    flowchart LR
        subgraph oldway["옛 방식 — 포트포워딩"]
            A1[방문자] --> A2[공유기 포트 443 오픈]
            A2 --> A3[미니PC 공개 IP]
            A3 --> A4[WordPress]
            A5[해커] -.공격.-> A2
        end
        subgraph newway["새 방식 — Cloudflare Tunnel"]
            B1[방문자] --> B2[Cloudflare 서울 DC]
            B2 -. 미리 열린 outbound 채널 .-> B3[미니PC cloudflared]
            B3 --> B4[WordPress]
            B5[해커] -.차단.-> B2
        end
        style A5 fill:#fdd,stroke:#a00
        style B5 fill:#dfd,stroke:#0a0
        style A3 fill:#fdd
        style B3 fill:#dfd

    핵심: 미니PC가 먼저 손을 뻗는다. 외부 → 우리집 흐름이 아니라, 우리집 → Cloudflare로 outbound 연결을 늘 열어둔다. 방문자 요청은 Cloudflare가 이 채널로 미니PC에 던진다.

    호텔 비유

    호텔 손님(미니PC)이 친구를 만나고 싶을 때.

    • 평범한 길: 호텔 입구에 자기 방 번호를 크게 써붙임. 친구는 그 번호로 들어옴. 동시에 도둑도 옴.
    • 다리의 길: 호텔 프론트데스크(Cloudflare)에 미리 메모를 남긴다. 내 친구 찾는 사람 있으면 객실로 연결해달라고. 친구는 이름만 대고, 프론트데스크가 안내한다. 방 번호는 외부 노출 X. 의심스러운 사람은 1차로 거른다.

    3. 트래픽 흐름 — 방문자가 도메인 칠 때

    sequenceDiagram
        participant V as 방문자 브라우저
        participant CF as Cloudflare 서울 DC
        participant CD as cloudflared (미니PC)
        participant WP as WordPress 컨테이너
        V->>CF: GET https://sticknstone.org
        Note over CF: WAF·DDoS 1차 필터
        CF->>CD: 미리 열린 outbound 채널로 forward
        CD->>WP: http://localhost:8090
        WP-->>CD: HTML 응답
        CD-->>CF: outbound 채널 회신
        CF-->>V: SSL 종단·CDN 캐시 + 응답

    4단계: 방문자 → Cloudflare(필터) → 다리 → 미니PC → 역순. 미니PC IP는 어디에도 안 등장.


    4. 다리지기: cloudflared

    이 outbound 채널을 우리집에서 유지하는 작은 데몬이 cloudflared — Cloudflare 공식 오픈소스.

    왜 Docker로 띄우나

    미니PC에 이미 Docker가 돌고 있다. 다른 컨테이너들과 같은 호텔에 묵는 게 자연스럽다.

    flowchart TB
        subgraph minipc["미니PC (Ubuntu 24.04)"]
            subgraph docker["Docker 호스트"]
                CD[cloudflared / network_mode host]
                WP[wordpress-wordpress-1 :8090]
                DB[(wordpress-db-1 MariaDB)]
                RD[(wordpress-redis-1 Object Cache)]
                UM[umami_umami-1 :3001]
                UDB[(umami_db-1 Postgres)]
            end
            WP --> DB
            WP --> RD
            UM --> UDB
        end
        CF[Cloudflare 네트워크] -. outbound .-> CD
        CD --> WP
        CD --> UM
        style CD fill:#ffe4b5,stroke:#d97706
        style CF fill:#dbeafe,stroke:#1d4ed8

    cloudflarednetwork_mode: host로 띄워서 호스트의 localhost:8090(WP)와 localhost:3001(Umami)에 접근하게 한다.

    설치 5분 가이드

    폴더 + 설정 파일:

    /home/user/cloudflared/
    ├── .env                # TUNNEL_TOKEN=eyJh... (Cloudflare 대시보드에서 받은 토큰)
    └── docker-compose.yml

    docker-compose.yml:

    services:
      cloudflared:
        image: cloudflare/cloudflared:latest
        container_name: cloudflared
        restart: unless-stopped
        network_mode: host
        command: tunnel --no-autoupdate run --token ${TUNNEL_TOKEN}
        env_file: .env

    가동 + 로그 검증:

    cd /home/user/cloudflared
    sudo docker compose up -d
    sudo docker logs cloudflared --tail 20

    성공 로그에 다음 4줄이 보인다 (Cloudflare 서울 데이터센터 4곳 동시 연결):

    Registered tunnel connection ... location=icn06 protocol=quic
    Registered tunnel connection ... location=icn01 protocol=quic
    Registered tunnel connection ... location=icn05 protocol=quic
    Registered tunnel connection ... location=icn06 protocol=quic

    미니PC는 4중 백업 채널로 Cloudflare에 연결된다. 한 채널이 죽어도 나머지 3개가 살아있다.


    5. 토큰은 위험하다 — 어디 두나

    cloudflared가 Cloudflare에 자기를 증명할 때 쓰는 토큰. 발급 시 한 번 보여주고 끝.

    토큰 다루기 원칙

    • .env 파일에 평문 저장. 권한 chmod 600 (소유자만 읽기·쓰기)
    • 채팅·노트·git 커밋에 절대 평문 X
    • 토큰 노출 의심 시 즉시 Cloudflare 대시보드에서 revoke + 재발급

    정확한 명령

    sudo chown user:user /home/user/cloudflared/.env
    sudo chmod 600 /home/user/cloudflared/.env

    6. 공짜로 따라오는 것

    Cloudflare 무료 플랜으로 이 다리만 놓아도 따라오는 보너스:

    보너스 설명 평소 가격대
    WAF (웹 방화벽) SQL injection·XSS 알려진 공격 자동 차단 월 $20~
    DDoS 보호 트래픽 폭주 자동 흡수, 무제한 월 $200~
    CDN 정적 파일 전 세계 캐싱. 외국 방문자도 빠르게 월 $10~
    SSL 자동 Let’s Encrypt 갱신 신경 0 월 $5~
    트래픽 통계 Cloudflare 대시보드에서 그래프로 (분석 도구)

    총합 비용: 0원. 도메인 갱신비 연 $10만.


    7. 함정 — 우리가 실제로 만난 것

    함정 1. Operating System 선택 헷갈림

    Cloudflare 대시보드의 cloudflared 설치 명령 화면에서 OS를 골라야 한다. 처음에는 자기 윈도우 PC가 OS인 줄 알고 Windows를 골랐다. 틀렸다. cloudflared가 설치되는 곳은 미니PC(Ubuntu)지 내 윈도우가 아니다. Docker를 골랐어야 한다.

    함정 2. 토큰을 LLM 채팅에 그대로 붙여넣음

    복사한 토큰을 LLM 채팅에 보내면 그 채팅 내용은 외부 서버에 저장된다. 토큰은 카드 비밀번호급 민감 정보. 작업 끝나면 즉시 Cloudflare 대시보드에서 토큰 회수 권장.

    함정 3. cloudflared가 어떻게 다른 서비스에 forward하나

    cloudflared 컨테이너만 띄우면 Cloudflare와 연결은 되지만, 들어온 요청을 어디로 보낼지는 별도 설정이다. Public Hostname 설정이라고 한다. 다음 편(10편)에서 다룬다.


    8. 검증

    가동 직후 Cloudflare 대시보드의 Tunnel 페이지 하단 Connection Status를 본다.

    Before:  No connection detected yet
    After:   Connected (체크)

    이 한 줄이 바뀌면 다리가 놓인 것이다.


    FAQ

    Q. Tailscale Funnel과 무엇이 다른가?
    둘 다 NAT 우회 + 미니PC IP 비공개라는 점은 같다. Cloudflare Tunnel은 WAF·DDoS·CDN·자기 도메인 사용까지 무료로 묶어준다. Tailscale Funnel은 전용 도메인 강제 + 보호막 없음. 블로그용은 Cloudflare가 우위.

    Q. 미니PC가 꺼지면 어떻게 되나?
    다리가 끊긴다. 방문자는 Cloudflare에서 521(Web server is down) 에러를 본다. 미니PC가 다시 켜지면 cloudflared가 자동으로 다리를 재연결한다 (Docker restart: unless-stopped).

    Q. Cloudflare가 트래픽을 보나? 개인정보 우려?
    Cloudflare는 SSL을 자기가 종단한다 = 평문 트래픽을 본다. 신뢰 모델은 Cloudflare는 내 편이라는 가정. 신뢰 못 하면 적합 X (대안: 자체 reverse proxy + Let’s Encrypt + dynamic DNS).

    Q. 무료 플랜 한계는?
    대역폭 무제한, 사이트 수 무제한, Tunnel 수 무제한. 단 Cloudflare Workers·R2 같은 부가 서비스에 별도 한도. 블로그 1개 운영엔 무료 플랜이 평생 충분.

    Q. 도메인이 .org가 아니어도 되나?
    무관. .com / .net / .io / .dev 모두 동일하게 작동. 단 도메인이 Cloudflare DNS를 쓰는 게 가장 쉬움 (자동 DNS 등록).


    다음 편 예고

    10편에서는 Public Hostname을 설정해 sticknstone.org → WordPress로 매핑하고, 글에 무엇을 쓰면 안 되는지(개인정보 검열)를 다룬다.


    한 줄 정리

    집에 있는 컴퓨터에 블로그를 띄우려면 공유기에 구멍 뚫고 IP 노출하는 옛 방식 대신, 컴퓨터에서 Cloudflare로 outbound 채널을 미리 열어두는 Cloudflare Tunnel 방식이 깔끔하다. 그 채널을 유지하는 작은 데몬이 cloudflared. Docker로 띄우면 5분.


    참고

  • 한 평짜리 서버 — WordPress를 Docker로 띄우기

    한 평짜리 서버 — WordPress를 Docker로 띄우기

    한 평짜리 서버 — WordPress를 Docker로 띄우기

    셀프호스팅 구축기 2편. 인프라 골격 30분.


    TL;DR

    • WordPress + MariaDB + Redis 세 컨테이너를 docker-compose.yml 한 파일로
    • 호스트 포트 127.0.0.1:8090 만 노출. 외부는 Cloudflare Tunnel(9편)이 라우팅
    • Redis는 Object Cache로 DB 쿼리 캐싱. 무료 + 페이지 응답 30% 빨라짐
    • 함정 5개: 한글 파일명 SCP·healthcheck --connect·named volume 비밀번호 잔류·WP_REDIS_HOST=redis·WORDPRESS_CONFIG_EXTRA X-Forwarded-Proto

    1. 왜 Docker인가 — 호스트 직접 설치 vs 컨테이너

    비교 호스트 직접 (apt install) Docker Compose ⭐
    설치 단순함 apt install apache2 php mariadb-server docker compose up -d
    의존성 충돌 PHP 8.1 vs 8.3 같은 갈등 발생 컨테이너 격리
    미니PC OS 재설치 시 처음부터 다시 compose.yml + 데이터 백업이면 끝
    업데이트 시스템 패키지 매니저 (까다로움) docker compose pull && up -d
    다른 컨테이너 (WP·Umami·cloudflared) 공존 어려움 자연스러움

    미니PC가 이미 다른 서비스를 Docker로 돌리고 있다면 답은 Docker.


    2. 구조 한 장

    

    세 컨테이너가 같은 docker network 안에서 호스트네임(db, redis)으로 통신. 외부 노출은 호스트 127.0.0.1:8090만.


    3. docker-compose.yml 핵심

    services:
      wordpress:
        image: wordpress:php8.3-apache
        restart: unless-stopped
        depends_on:
          db:
            condition: service_healthy
        environment:
          WORDPRESS_DB_HOST: db
          WORDPRESS_DB_USER: wp
          WORDPRESS_DB_PASSWORD: ${DB_PASSWORD}
          WORDPRESS_DB_NAME: wp
          WORDPRESS_CONFIG_EXTRA: |
            if (!empty($$_SERVER['HTTP_X_FORWARDED_PROTO']) && $$_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
              $$_SERVER['HTTPS'] = 'on';
            }
        volumes:
          - wordpress_data:/var/www/html
        ports:
          - "127.0.0.1:8090:80"
    
      db:
        image: mariadb:11
        restart: unless-stopped
        environment:
          MARIADB_DATABASE: wp
          MARIADB_USER: wp
          MARIADB_PASSWORD: ${DB_PASSWORD}
          MARIADB_ROOT_PASSWORD: ${DB_ROOT_PASSWORD}
        volumes:
          - wordpress_db_data:/var/lib/mysql
        healthcheck:
          test: ["CMD", "healthcheck.sh", "--connect"]
          interval: 10s
          timeout: 5s
          retries: 6
          start_period: 30s
    
      redis:
        image: redis:7-alpine
        restart: unless-stopped
        volumes:
          - wordpress_redis_data:/data
    
    volumes:
      wordpress_data:
      wordpress_db_data:
      wordpress_redis_data:
    

    .env 분리:

    DB_PASSWORD=<openssl rand -hex 24>
    DB_ROOT_PASSWORD=<openssl rand -hex 24>
    

    chmod 600 .env. git에 절대 X.


    4. 가동 + 검증

    cd /home/user/wordpress
    docker compose up -d
    docker compose ps
    curl -I http://localhost:8090
    

    응답이 HTTP/1.1 302 (WordPress가 초기 설치 페이지로 리디렉트) 면 성공.

    브라우저로 http://localhost:8090 접속 → 5분 위자드 → 관리자 계정 생성 (이름은 admin 말고 본인 단어. brute force 1차 회피).


    5. Redis Object Cache 활성

    플러그인 redis-cache 설치 후:

    wp config set WP_REDIS_HOST redis --allow-root
    wp config set WP_REDIS_PORT 6379 --allow-root
    wp config set WP_REDIS_PREFIX byeolgorae: --allow-root
    wp config set WP_CACHE true --raw --allow-root
    wp redis enable --allow-root
    

    WP_REDIS_HOST=redis 이게 핵심. Docker 호스트네임. 127.0.0.1이면 자기 컨테이너 안만 봐서 실패.


    6. 함정 — 우리가 실제로 만난 것

    함정 1. 한글·박스 문자 파일 SCP

    docker-compose.ymlminipc_write_file로 작성하다가 한글 주석 + 특수문자 조합에서 SSH escape 깨짐 (bash: -c: 줄 1: '...' 찾는 도중 예상치 못한 파일의 끝).

    → Windows에서 c:\tmp\에 평문 작성 → scp → 미니PC /tmp/sudo cp 경로로 우회.

    함정 2. mariadb healthcheck --innodb-initialized 미지원

    웹 가이드 따라 ["CMD", "healthcheck.sh", "--connect", "--innodb-initialized"] 박았더니 unknown option 에러.

    --connect 만 사용 + start_period: 30s 길게.

    함정 3. .env 비밀번호 바꾼 후 “Database Error”

    DB 비밀번호 한 번 바꾸고 docker compose up -d 했더니 500. 이유: named volume에 옛날 비밀번호가 저장된 MariaDB DB 파일이 살아있음. 새 비밀번호로는 인증 실패.

    docker compose down -v (-v가 volume 같이 제거) → 다시 up -d. 운영 데이터 있으면 절대 안 됨, 초기 셋업 단계에서만.

    함정 4. Redis Connection refused 127.0.0.1:6379

    WP_REDIS_HOST=127.0.0.1 박았다가 컨테이너 안에서 자기 자신 보는 꼴. Redis는 다른 컨테이너.

    WP_REDIS_HOST=redis (Docker network 호스트네임).

    함정 5. HTTPS 리버스 프록시 무한 리다이렉트

    Cloudflare Tunnel이 앞에 서서 HTTPS 종단 후 미니PC엔 HTTP로 forward. WordPress가 자기를 HTTP로 인식 → “HTTPS로 가야 함” 리다이렉트 → 무한 루프.

    WORDPRESS_CONFIG_EXTRA에 X-Forwarded-Proto 처리 (위 yml 참고).


    FAQ

    Q. 메모리 얼마나 쓰나?
    WP(php-fpm 또는 apache) ~200MB, MariaDB ~150MB, Redis ~30MB. 합 ~400MB. 미니PC 8GB RAM이면 여유 충분.

    Q. 디스크 용량은?
    이미지 합 ~1GB. DB는 콘텐츠에 따라 (글 100편 + 이미지 = ~500MB).

    Q. PHP 8.3 말고 8.2면 안 되나?
    WordPress 6.x는 8.2·8.3 둘 다 지원. 8.3이 더 빠름 (JIT 안정화). 최신 권장.

    Q. mariadb 말고 mysql 쓰면?
    mariadb는 mysql 호환 + 라이센스 자유 + Oracle 의존 X. 둘 다 작동. 1인 운영엔 mariadb 추천.

    Q. 백업은 어떻게?
    4편(백업·캐시·이미지)에서 자세히. 매일 03:00 cron으로 mariadb-dump → gzip → Obsidian Vault.


    다음 편 예고

    3편 — AI도 읽으라고: robots.txt와 llms.txt. 봇 차별 대신 AI 크롤러 14종 명시 허용. GEO 시대 콘텐츠 노출 전략.


    한 줄 정리

    WordPress·MariaDB·Redis 세 컨테이너를 docker-compose.yml 한 파일로 묶어 30분에 가동. 호스트 127.0.0.1:8090만 노출, 외부 라우팅은 Cloudflare Tunnel에 위임. 함정은 한글 SCP·healthcheck·volume 잔류·Redis host·X-Forwarded-Proto.