⚠ 이 컴퓨터의 443 포트가 호스트명 metabolism.logophilia.eu로 접근할 수 없는 것 같습니다 ----

Hi, 초기 설정 중 " 포트 80과 443이 사용 가능합니다"라는 메시지를 받은 후 제목에 나와 있는 오류(아래 참조)가 발생합니다. DNS는 설정되어 있고, SSL도 구성했으며, 외부에서 웹사이트에 접근할 수 있습니다(직접 테스트해 보세요). curl 출력(일부 생략)을 아래에 첨부했으며, 이는 해당 서버 자체에서도 접근 가능하다는 것을 의미합니다. 무엇이 부족한지 아이디어가 없습니다. 조언해 주시면 감사하겠습니다.

P.S. AlmaLinux 10.2 - 6.12.0-211.7.4.el10_2.x86_64

# ./discourse-setup  
→ 설정 마법사 이미지 업데이트 확인 중... 
→ Discourse 설정 마법사 시작 중... 
 
 
 ___  _ 
|   \(_)___ __ ___ _  _ _ _ ___ ___ 
| |) | (_-</ _/ _ \ || | '_(_-</ -_) 
|___/|_/__/\__\___/\_,_|_| /__/\___| 
                       Setup Wizard 
 
 
→ 이 마법사는 Discourse 설치 구성을 도와드립니다. 
→ 언제든지 Ctrl+C를 눌러 취소할 수 있습니다. 
 
── 시스템 검사 ── 
 
[1/5] 시스템 요구 사항 확인 중 
✓ root 권한으로 실행 중 
✓ Docker 사용 가능 
✓ 메모리: 8GB, CPU: 4코어 
 
── 구성 ── 
 
[2/5] 구성 준비 중 
✓ 포트 80과 443이 사용 가능합니다 
→ 새 구성 생성 중... 
→ 템플릿에서 새 구성 생성 중... 
 
── 사이트 설정 ── 
 
[3/5] 사이트 정보 입력 
 
관리자 계정 이메일 주소? 
eduard.pech@logophilia.eu▌ 
 
Discourse에 사용할 도메인 이름이 있으신가요? 
▸ 예      아니오 
 
Discourse의 호스트 이름은? 
metabolism.logophilia.eu▌ 
 
이메일 전송을 위한 SMTP 구성? (SMTP 자격 증명 필요) 
  예    ▸ 아니오 
 
 
── 구성 검토 ── 
 
 
╭────────────────────────────────────────────╮ 
│                                            │ 
│  호스트 이름     metabolism.logophilia.eu   │ 
│  관리자 이메일   eduard.pech@logophilia.eu  │ 
│  SMTP           (구성되지 않음)           │ 
│  Let's Encrypt  활성화됨                    │ 
│                                            │ 
╰────────────────────────────────────────────╯ 
 
 
이것이 올바른가요? 
▸ 예      아니오 
→ 8GB의 메모리와 4개의 CPU 코어 감지 
→ db_shared_buffers = 2048MB 설정 중 
→ UNICORN_WORKERS = 8 설정 중 
 
── 네트워크 검증 ── 
 
[4/5] 도메인 구성 확인 중 
→ 도메인 이름 확인 중... 
⚠ 이 컴퓨터의 포트 443은 호스트 이름 metabolism.logophilia.eu를 사용하여 접근할 수 없는 것으로 보입니다. 
⚠ http://metabolism.logophilia.eu (포트 80)에 대한 연결도 실패합니다. 
 
이는 metabolism.logophilia.eu가 이 Discourse를 설치 중인 이 머신에 도달하지 않는 어떤 IP 주소로 해석되고 있음을 시사합니다. 
 
가장 먼저 해야 할 일은 metabolism.logophilia.eu가 이 서버의 IP 주소로 해석되는지 확인하는 것입니다. 
보통 도메인을 구매한 곳에서 이렇게 확인합니다. 
 
IP 주소가 올바르게 해석된다고 확신한다면, 방화벽 문제일 수 있습니다. 
"YOUR CLOUD SERVICE 포트 열기"로 웹 검색을 해보면 도움이 될 수 있습니다. 
 
이 도구는 가장 표준적인 설치에만 설계되어 있습니다. 위의 문제를 해결할 수 없다면 
containers/app.yml 파일을 직접 편집한 후 다음을 입력해야 합니다: 
 
    ./launcher rebuild app 
 
 
✗ metabolism.logophilia.eu의 DNS 검증 실패 
[root@logophilia discourse]# dig metabolism.logophilia.eu 
 
; <<>> DiG 9.18.33 <<>> metabolism.logophilia.eu 
;; global options: +cmd 
;; Got answer: 
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 36726 
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 
 
;; OPT PSEUDOSECTION: 
; EDNS: version: 0, flags:; udp: 512 
;; QUESTION SECTION: 
;metabolism.logophilia.eu.      IN      A 
 
;; ANSWER SECTION: 
metabolism.logophilia.eu. 300   IN      A       75.119.134.68 
 
;; Query time: 8 msec 
;; SERVER: 213.136.95.10#53(213.136.95.10) (UDP) 
;; WHEN: Sat Jun 06 04:52:23 CEST 2026 
;; MSG SIZE  rcvd: 69 
 
[root@logophilia discourse]# curl -v https://metabolism.logophilia.eu 
* Host metabolism.logophilia.eu:443 was resolved. 
* IPv6: (none) 
* IPv4: 75.119.134.68 
*   Trying 75.119.134.68:443... 
* ALPN: curl offers h2,http/1.1 
* TLSv1.3 (OUT), TLS handshake, Client hello (1): 
*  CAfile: /etc/pki/tls/certs/ca-bundle.crt 
*  CApath: none 
* TLSv1.3 (IN), TLS handshake, Server hello (2): 
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1): 
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): 
* TLSv1.3 (IN), TLS handshake, Certificate (11): 
* TLSv1.3 (IN), TLS handshake, CERT verify (15): 
* TLSv1.3 (IN), TLS handshake, Finished (20): 
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): 
* TLSv1.3 (OUT), TLS handshake, Finished (20): 
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / x25519 / RSASSA-PSS 
* ALPN: server accepted http/1.1 
* Server certificate: 
*  subject: CN=metabolism.logophilia.eu 
*  start date: Jun  6 00:26:43 2026 GMT 
*  expire date: Sep  4 00:26:42 2026 GMT 
*  subjectAltName: host "metabolism.logophilia.eu" matched cert's "metabolism.logophilia.eu" 
*  issuer: C=US; O=Let's Encrypt; CN=YR2 
*  SSL certificate verify ok. 
*   Certificate level 0: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption 
*   Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption 
*   Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption 
*   Certificate level 3: Public key type RSA (4096/152 Bits/secBits), signed using sha256WithRSAEncryption 
* Connected to metabolism.logophilia.eu (75.119.134.68) port 443 
* using HTTP/1.x 
> GET / HTTP/1.1 
> Host: metabolism.logophilia.eu 
> User-Agent: curl/8.12.1 
> Accept: */* 
>  
* Request completely sent off 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): 
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): 
< HTTP/1.1 200 OK 
< Date: Sat, 06 Jun 2026 02:52:36 GMT 
< Server: Apache 
< Last-Modified: Sat, 06 Jun 2026 01:25:19 GMT 
< ETag: "1325f-6538ba67ff892" 
< Accept-Ranges: bytes 
< Content-Length: 78431 
< Content-Type: text/html; charset=UTF-8 
<  
<!doctype html> 
<html lang="en" data-bs-theme="auto"> 
<head> 
  <title> 
    metabolism.logophilia.eu &mdash;  Domain welcome page for  </title> 
  <meta charset="utf-8">
……


안녕하세요,

저희 웹사이트를 직접 확인해 보았습니다. 호스팅 제공업체가 이 환영 페이지를 표시하기 위해 포트 443을 점유하고 있는 것으로 보입니다. Discourse가 이 포트를 제어할 수 있도록 포트 443/80을 완전히 해제하는 방법을 알아내야 합니다.

이미 그렇게 했습니다. VPS는 Virtualmin으로 관리되고 있고, 체크박스 하나만 클릭하면 됩니다. 불행히도 ‘웹사이트 활성화’ 체크를 해제하면 호스트에서 443/80 포트를 curl로 접근할 수 없으며, Discourse 설치 과정에서도 동일한 오류가 계속 발생합니다. 그래서 적어도 SSL 핸드셰이크가 정상적으로 작동한다는 것을 보여주기 위해 다시 웹사이트를 활성화했습니다.

또한 제 첫 번째 게시글에서 보실 수 있듯이, Discourse 설치 과정은 (처음에는) 443 포트가 사용 가능하다고 실제로 주장합니다. 제 첫 설치인 점을 고려하면, 이를 '모든 것이 정상(그린)'으로 해석하고 싶습니다. 그런데 왜 설치 과정이 ‘의견을 바꾸는’ 것일까요?

다시 말하지만, 모든 세부 사항을 이해할 필요는 없습니다. 그냥 말씀드리고 싶은 것은: 서브도메인에서 Apache를 비활성화해도 Discourse 설치 결과는 동일하다는 것입니다.

시간 내어 답변해 주셔서 감사합니다. 설명에 도움이 될 다른 정보가 필요하시면, (거의) 무엇이든 제공하겠습니다.

저도 같은 문제를 겪었습니다(제 집에서 직접 운영 중인 서버에서):

DNS가 정확하고 포트가 정상적으로 작동한다고 100% 확신이 있다면, 아래 명령을 실행하는 것이 해결책이라고 생각합니다.

./install-discourse --skip-connection-test

감사합니다, 그거면 되는 것 같습니다! :purple_heart:

스크립트는 이제 5/5를 넘어서서, 많은 추가 항목을 업로드/설치하는 것 같습니다. SSL 인증서가 지금은 잘못되어 있는데, TTL 타임아웃을 기다리는 중이거나, 설치가 끝나면 정상적으로 될 것 같습니다.

솔직히 Discourse나 Docker, 심지어 Ruby에 대해서는 전혀 모르지만… DNS 부분은 항상 문제가 되지 않습니다 :slight_smile: 다시 한번 감사합니다!

이미 해결책으로 표시되어 있는 것을 확인했습니다. 하지만 허락하신다면 한 가지 더 질문이 있습니다.

Postgres가 필요하다는 것은 알고 있지만, 아래 문서에는 언급되어 있지 않습니다.

https://github.com/discourse/discourse/blob/main/docs/INSTALL-cloud.md

그래서 Docker 이미지에 Postgres가 설치되어 있는 것으로 생각했습니다. VPS에 Postgres를 설치해야 하는지 명확히 해 주실 수 있을까요? 설치 지침에 해당 사항이 언급되어 있지 않아서요.

… 아니면 Docker에 Postgres가 포함되어 있지만 스크립트가 어딘가에서 실패한 것일까요? 마지막에 종료되거든요:

........
I, [2026-06-06T04:23:49.114769 #1]  INFO -- : File > /etc/runit/1.d/install-ssl  chmod: +x  chown: 
I, [2026-06-06T04:23:49.114999 #1]  INFO -- : Replacing # after ssl with if [ -z "$DISABLE_LETSENCRYPT" ] || [ -n "$ENABLE_LETSENCRYPT" ]; then
  /usr/local/bin/configure-ssl
  exec /usr/local/bin/configure-letsencrypt
fi
# after ssl in /etc/runit/1.d/install-ssl
I, [2026-06-06T04:23:49.125964 #1]  INFO -- : File > /usr/local/bin/configure-ssl  chmod: +x  chown: 
I, [2026-06-06T04:23:49.127031 #1]  INFO -- : > curl https://raw.githubusercontent.com/acmesh-official/acme.sh/3.0.6/acme.sh > /opt/acme.sh
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100  215k  100  215k    0     0   635k      0 --:--:-- --:--:-- --:--:--  637k
I, [2026-06-06T04:23:49.514883 #1]  INFO -- : > chmod +x /opt/acme.sh
I, [2026-06-06T04:23:49.554670 #1]  INFO -- : File > /usr/local/bin/configure-letsencrypt  chmod: +x  chown: 
I, [2026-06-06T04:23:49.596808 #1]  INFO -- : File > /usr/local/bin/letsencrypt  chmod: +x  chown: 
I, [2026-06-06T04:23:49.598926 #1]  INFO -- : > echo "Beginning of custom commands"
Beginning of custom commands
I, [2026-06-06T04:23:49.605809 #1]  INFO -- : > echo "End of custom commands"
End of custom commands
I, [2026-06-06T04:23:49.608842 #1]  INFO -- : Terminating async processes
I, [2026-06-06T04:23:49.609015 #1]  INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/15/bin/postmaster -D /etc/postgresql/15/main pid: 44
I, [2026-06-06T04:23:49.609157 #1]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 111
2026-06-06 04:23:49.609 UTC [44] LOG:  received fast shutdown request
111:signal-handler (1780719829) Received SIGTERM scheduling shutdown...
2026-06-06 04:23:49.612 UTC [44] LOG:  aborting any active transactions
2026-06-06 04:23:49.619 UTC [44] LOG:  background worker "logical replication launcher" (PID 58) exited with exit code 1
2026-06-06 04:23:49.623 UTC [53] LOG:  shutting down
2026-06-06 04:23:49.634 UTC [53] LOG:  checkpoint starting: shutdown immediate
111:M 06 Jun 2026 04:23:49.683 * User requested shutdown...
111:M 06 Jun 2026 04:23:49.683 * Saving the final RDB snapshot before exiting.
111:M 06 Jun 2026 04:23:49.698 * DB saved on disk
111:M 06 Jun 2026 04:23:49.700 # Redis is now ready to exit, bye bye...
2026-06-06 04:23:49.711 UTC [53] LOG:  checkpoint complete: wrote 87 buffers (0.0%); 0 WAL file(s) added, 0 removed, 0 recycled; write=0.041 s, sync=0.022 s, total=0.088 s; sync files=52, longest=0.008 s, average=0.001 s; distance=86 kB, estimate=86 kB
2026-06-06 04:23:49.735 UTC [44] LOG:  database system is shut down

Postgres를 설치하지 마세요.

그건 당연합니다. 웹 서버로 사용할 Discourse를 설치하지 않았기 때문이죠.

그렇다면 (거의 확실하게) VM의 포트가 인터넷에 노출되어 있지 않은 문제가 여전히 남아 있는 것입니다.

그렇지 않습니다. Discourse가 해당 포트에 접근할 수 없다고 명확히 명시하고 있습니다. 당신의 curl 명령어는 443 포트가 다른 것에 의해 제어되고 있음을 보여줍니다.

컨테이너가 성공적으로 빌드되었지만, 443 포트가 다른 것에 의해 사용되고 있어 시작할 수 없거나, 443 포트가 다른 곳으로 라우팅되어 아무것도 하지 않는 것 같습니다.

다음과 같이 시도해 볼 수 있습니다.

docker ps

실행 중인 컨테이너가 있는지 확인하고,

docker logs app

Docker를 통해 Discourse가 기록한 로그를 확인할 수 있습니다.

피드백 주셔서 감사합니다, 시간을 내어 주셔서 정말 감사드립니다. 좀 아는 척하는 것처럼 보이지 않으려면:

[2/5] Preparing configuration 
✓ Ports 80 and 443 are free for use 

처음에는 "free for use"라고 실제로 표시됩니다. 하지만 Gemini의 도움(주로 docker 사용법 관련, ㅋㅋ) 덕분에 이제 제 인스턴스를 정상적으로 구동 중입니다. Virtualmin 사용자들을 위해 제 "런북"을 공유하고 싶습니다. 왜냐하면 "443 포트를 비우라"는 이 문제의 해결책이 아니기 때문입니다. 나머지 게시글 내용은 이 런북이 될 텐데, 다른 곳(예: 새로운 스레드)에 게시하는 것이 더 적절하다면 어디로 가야 하는지 알려주세요. 제 환경과 비슷한 구성을 가진 사람이 저 혼자만은 아닐 테고, 다른 분들에게도 유용할 수 있다고 생각합니다. 다시 한번 감사합니다!

그러면, 설치가 다음 명령어로 완료된 후

cd /var/discourse
./discourse-setup --skip-connection-test

(c/o @darkpixlz :purple_heart:)

… Webmin과 Virtualmin으로 관리되는 VPS에서 서브도메인을 사용하는 경우 다음 단계를 수행합니다.

확정적인 Virtualmin + Discourse 런북 *

  • (1) 잔여물 정리 (재시도하는 경우, 저처럼):

    rm -rf /var/discourse/shared/standalone/ssl/*

    rm -rf /var/discourse/shared/standalone/letsencrypt

    rm -rf /var/discourse/shared/standalone/state

  • (2) 템플릿 삭제:

    app.yml에서 templates/web.ssl.template.ymltemplates/web.letsencrypt.ssl.template.yml 줄을 완전히 삭제해야 합니다. 커스텀 런처 파서는 # 접두사가 있어도 이를 평가합니다.

  • (3) 이메일 설정 및 변수:

    DISCOURSE_SKIP_EMAIL_SETUP'1'에서 '0'으로 변경하세요. 그렇지 않으면 Discourse가 연결되어 DiscordID를 확인할 수 없기 때문입니다.

    백엔드가 보안 URL을 생성하도록 DISCOURSE_FORCE_HTTPS: true를 추가하세요.

    친근한 알림: DISCOURSE_SMTP_USER_NAME이 전체 이메일 주소(예: 'logophilia@logophilia.eu')가 아니라 원본 메일박스 계정 이름(예: 'logophilia')으로 설정되어 있는지 확인하고, 잠재적인 YAML 문자 파싱 버그를 우회하기 위해 자격 증명을 단일 따옴표(')로 감싸세요.

  • (4) Expose 블록 구성:

    app.ymlexpose: 블록에 HTTP 매핑이 포함되어 있는지 확인하세요. Virtualmin이 SSL 로직을 종료한 후 전달하기 때문에 443=>8443 매핑은 선택 사항/불필요합니다:

    expose:
      - 8080:80
    

    이제 재구축을 시작할 수 있습니다:

    cd /var/discourse
    ./launcher rebuild app
    
  • (5) 서브도메인 및 프록시 경로 설정:

    • Virtualmin에서 평소처럼 서브도메인을 생성하고 Let’s Encrypt SSL 인증서로 보호하세요(자동으로 수행되지만, 아무런 관련 없는 이유로 오류가 발생하지 않도록 확인하세요).
    • Proxy Paths(Virtualmin → 서브도메인 → Web Configuration → Proxy Paths)로 이동하여 /에서 http://localhost:8080/으로의 새 매핑을 생성하고, "serve locally"는 체크하지 않은 채 Proxy WebSocketYes로 전환하여 실시간 업데이트 및 알림 스트림을 허용하세요.
  • (6) CSRF 헤더 지시문:

    • Webmin ➔ Servers ➔ Apache Webserver ➔ [여기서 서브도메인 구성을 찾아 443 구성을 클릭] ➔ Edit Directives에서 CSRF 토큰 전달을 용이하게 하기 위해 다음 줄을 Virtualmin의 자체 Let’s Encrypt 프록시 블록(보통 “ProxyPass /.well-known !”) 위쪽에 배치하세요:
    ProxyPreserveHost On
    RequestHeader set X-Forwarded-Proto "https"
    RequestHeader set X-Forwarded-For %{REMOTE_ADDR}s
    

    ProxyPreserveHost On: Discourse에 “localhost” 대신 실제 도메인 이름을 알려줍니다.
    RequestHeader set X-Forwarded-Proto "https": 사용자가 보안 연결을 사용한다는 것을 Discourse에 명시적으로 알려주며, 이는 DISCOURSE_FORCE_HTTPS: true 설정과 일치합니다.
    RequestHeader set X-Forwarded-For: 보안 로그가 작동하도록 방문자의 실제 IP 주소를 컨테이너로 전달합니다.

  • (7) 깨끗한 컨테이너 핸드셰이크:

    긴(미안하지만 … 사실입니다;-) 재구축 프로세스가 완료되는 동안, 잠재적으로 막힌 컨테이너 청사진이 docker rm -f app으로 지워졌는지 확인하여 ./launcher start app을 실행할 때 포트 8080에 바인딩된 완전히 새로운 인스턴스가 시작되도록 하세요. docker ps에서 “ports” 아래에 다음과 유사한 것이 표시되는지 확인하세요:

    # docker ps
    CONTAINER ID   IMAGE                 COMMAND        CREATED          STATUS          PORTS                                                                                NAMES
    d21772a21e36   local_discourse/app   "/sbin/boot"   45 minutes ago   Up 45 minutes   0.0.0.0:8080->80/tcp, [::]:8080->80/tcp, 0.0.0.0:8443->443/tcp, [::]:8443->443/tcp   app
    

    (보시다시피, 저는 app.yml에 443=>8443 지시문을 남겨두었는데, 어느 쪽으로든 작동합니다.)

  • (8) 모니터링 및 시작:

    데이터베이스 마이그레이션이 완료되고 워커가 요청을 처리하기 시작할 때까지 docker logs -f app으로 부팅 스트림을 테일링하세요. 기본적으로 “INFO” 줄이 연속으로 많이 출력됩니다.

  • (9) 마무리:

    브라우저에서 서브도메인을 로드하고 Register를 클릭한 후 시스템이 메일박스로 인증 이메일을 보내도록 하세요.

*) 반박될 때까지 :wink:

설치 전에 Nginx 서버를 꺼야 했어요. 이 테스트를 건너뛸 수 있는 플래그가 있다는 건 좋은 점이에요 :slight_smile: