안녕하세요. 몇 시간 전 ./launcher rebuild app 명령을 사용하여 Discourse Image와 Discourse를 업데이트했습니다. 이 과정에서 발생한 몇 가지 오류는 app.yml에서 비추천되는 플러그인 설치 줄을 제거함으로써 해결했습니다. 그 외 설정 변경 사항은 없습니다. 현재 Docker 컨테이너가 80과 443 TCP 포트에서 리스닝 중이지만, 컨테이너 내의 nginx가 SSL/TLS 연결을 거부하고 있습니다. 컨테이너 내부의 error.log에는 오류가 표시되지 않고, access.log에는 요청 기록이 없으며, 443 포트에 대한 telnet 연결 시 연결 거부가 나타납니다. TCP 포트 80을 통한 HTTP 접근은 정상적으로 작동하지만, SSO 인증 문제(아마도 secure-only 쿠키 관련 문제일 것 같습니다)가 발생하고 있습니다. Launcher 재시작과 discourse-doctor 실행, 그리고 컨테이너 내부 nginx 재시작으로도 문제가 해결되지 않습니다. 이제 어디를 살펴보고 어떻게 해야 할까요?
ufw가 활성화되어 있고 https 포트 443에 대한 연결이 허용되도록 설정되지 않은 경우 이러한 현상이 발생할 수 있습니다.
수정: #mail-receiver가 정상적으로 작동하려면 이 포트가 열려 있어야 합니다
ufw, iptables 등의 설정을 변경하지 않았습니다. 업데이트 전에도 해당 포트가 정확히 열려 있던 상태였습니다. Discourse 업데이트 과정에서 설정이 변경되었을 수 있을까요?
절대 그럴 수 있습니다. Discourse 도커 컨테이너는 ufw 앞에 위치해야 합니다. 하지만 포트 443을 열지 않으면 서로 다른 컨테이너 간의 통신에 문제가 발생하거나 telnet 사용에 문제가 생길 수 있습니다.
.\launcher logs app 명령을 실행하면 어떤 결과가 반환되나요? (도메인 이름 등을 MS Word를 사용하여 편집할 수 있습니다)
PuTTy 또는 다른 SSH 클라이언트를 통해 서버에 접근하고 있나요? 포트 22를 열고 있나요?
최근 재빌드 이후 셀프호스트 인스턴스에서도 이 문제를 겪고 있습니다. 재빌드 자체를 제외하고는 구성 변경 사항이 없습니다. SSH를 통해 서버에 접근할 수 있으며, ./launcher logs app 명령의 출력 결과는 다음과 같습니다.
run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/01-cleanup-web-pids
run-parts: executing /etc/runit/1.d/anacron
run-parts: executing /etc/runit/1.d/cleanup-pids
Cleaning stale PID files
run-parts: executing /etc/runit/1.d/copy-env
run-parts: executing /etc/runit/1.d/install-ssl
Started runsvdir, PID is 45
ok: run: redis: (pid 55) 0s
supervisor pid: 53 unicorn pid: 76
docker ps 출력을 통해 Docker 컨테이너가 실행 중임을 확인할 수 있습니다. (컨테이너 ID는 생략함)
local_discourse/app “/sbin/boot” 16 minutes ago Up 16 minutes 0.0.0.0:80->80/tcp, [::]:80->80/tcp, 0.0.0.0:443->443/tcp, [::]:443->443/tcp, 0.0.0.0:5432->5432/tcp, [::]:5432->5432/tcp app
강조하고 싶은 중요한 점은, 특정 발급 기관이 필요하기 때문에 인증서에 LetsEncrypt를 사용하지 않는다는 것입니다. 그러나 이 인증서는 변경된 적이 없으며, 재빌드 전에는 정상적으로 작동하고 있었습니다 (이 방식으로 발급된 인증서는 우리의 인스턴스에서 수년간 정상적으로 작동해 왔습니다).
nginx가 기대하는 IP(로컬 IP 127.0.0.1)와 컨테이너에 할당된 IP 사이에 불일치가 있는 것으로 보입니다. 컨테이너가 브리지 모드로 실행되고 있는 것 같습니다. 다음은 컨테이너의 네트워크 설정입니다. (참고로 이 로그는 금요일에 이 문제를 처음 발견하고 조사를 시작했을 때의 것입니다)
"Labels": {
"org.opencontainers.image.created": "2025-07-25T21:40:36+00:00"
},
"NetworkSettings": {
"Bridge": "",
"SandboxID": "[REDACTED]",
"SandboxKey": "[REDACTED]",
"Ports": {
"443/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "443"
},
{
"HostIp": "::",
"HostPort": "443"
}
],
"5432/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "5432"
},
{
"HostIp": "::",
"HostPort": "5432"
}
],
"80/tcp": [
{
"HostIp": "0.0.0.0",
"HostPort": "80"
},
{
"HostIp": "::",
"HostPort": "80"
}
]
},
"HairpinMode": false,
"LinkLocalIPv6Address": "",
"LinkLocalIPv6PrefixLen": 0,
"SecondaryIPAddresses": null,
"SecondaryIPv6Addresses": null,
"EndpointID": "[REDACTED]",
"Gateway": "172.17.0.1",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"IPAddress": "172.17.0.2",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"MacAddress": "[REDACTED]",
"Networks": {
"bridge": {
"IPAMConfig": null,
"Links": null,
"Aliases": null,
"MacAddress": "[REDACTED]",
"DriverOpts": null,
"GwPriority": 0,
"NetworkID": "[REDACTED]",
"EndpointID": "[REDACTED]",
"Gateway": "172.17.0.1",
"IPAddress": "172.17.0.2",
"IPPrefixLen": 16,
"IPv6Gateway": "",
"GlobalIPv6Address": "",
"GlobalIPv6PrefixLen": 0,
"DNSNames": null
}
}
}
최근 병합된 PR에서 app.yml에 새로운 변수 요구 사항이 도입된 것으로 보입니다. 아직 문서화되지는 않았지만, app.yml 파일에 ENABLE_SSL: true를 추가해야 합니다.
이것은 버그인 것 같습니다. SSL은 몇 년 전부터 기본적으로 활성화되어 있었습니다. 해당 커밋에 대한 링크를 공유해 주시겠습니까?
ssl 템플릿 코드에서 확인됩니다. 저는 현재 스마트폰으로 접속 중이고 GitHub에 문제가 있어서 무언가를 놓치고 있을 수도 있지만, 모든 셀프호스팅 사이트가 깨지는 것처럼 보입니다.
이건 분명히 ssl-on-boot 설정을 병합하면서 생긴 의도치 않은 버그입니다:
여기서 ENABLE_SSL을 기본적으로 1로 업데이트했습니다:
@tanya_byrne 님, 지적해 주셔서 감사합니다.
잘 막았어, 제프! 고마워!
수고하셨어요 @featheredtoast
고마워요, 여러분. 우리도 문제를 해결했어요.