귀하의 애플리케이션은 127.0.0.1:3000에서 듣고 있습니다. 로컬에서는 응답하지만, 공용 도메인에서는 아직 제대로 노출되지 않았습니다.
Caddy는 이 웹 서비스 앞에 리버스 프록시로 작동할 수 있으며, 자동 TLS 인증서로 HTTPS를 관리할 수 있습니다. Debian 또는 Ubuntu VPS에서 백엔드를 확인하고, 공용 포트를 해제하고, 최소 Caddyfile을 설정한 후 외부에서 HTTPS 응답을 확인하십시오.

도메인, 백엔드 및 포트 확인
Caddy를 시작하기 전에 도메인 이름이 이 서버에 도착해야 합니다. IPv6 레코드도 확인하십시오: 이전 AAAA 레코드가 다른 머신을 가리키고 있다면 인증서 발급이 차단됩니다.
방화벽이나 이미 설정된 프록시에 손을 대기 전에 SSH 세션을 열어두십시오.
dig +short A app.exemple.net
dig +short AAAA app.exemple.net
curl -I http://127.0.0.1:3000/
sudo ss -lntp '( sport = :80 or sport = :443 )'
app.exemple.net을 귀하의 이름으로 변경하십시오. A 레코드와 AAAA 레코드는 VPS의 공용 주소를 가리켜야 합니다. curl -I는 애플리케이션이 예상하는 코드를 반환해야 하며, 보통 200 또는 302입니다.
백엔드가 로컬 루프에서 응답하지 않는다면, 먼저 애플리케이션을 수정하십시오. Caddy는 중단된 서비스나 잘못된 내부 URL을 수정하지 않습니다.
ss는 이미 포트 80과 443에 연결된 프로세스를 나열합니다. Nginx나 Apache를 단순한 반사적 이유로 종료하지 마십시오: 먼저 이 포트를 유지하는 프록시를 선택하고, 필요하다면 깔끔하게 마이그레이션하십시오.
리버스 프록시 Caddyfile 만들기
배포판에 맞는 패키지에서 Caddy를 설치한 후, /etc/caddy/Caddyfile을 여십시오. 로컬 HTTP 서비스의 경우, 이 블록이면 충분합니다:
app.exemple.net {
reverse_proxy 127.0.0.1:3000
}
첫 번째 줄은 공용 이름입니다. reverse_proxy는 127.0.0.1:3000에서 듣고 있는 애플리케이션에 요청을 전달합니다.
실제 도메인을 사용하면 Caddy는 공적으로 인정된 인증서를 요청하고 자동으로 갱신합니다. 애플리케이션은 프록시 뒤에서 작동하며 인터넷에서 들을 필요가 없습니다.
같은 VPS에서 백엔드에 대해 127.0.0.1를 유지하십시오. 이렇게 하면 네트워크에서 애플리케이션 포트를 열지 않을 수 있습니다.
백엔드가 다른 VM이나 다른 호스트에 있다면, 명시적인 사설 주소를 사용하고 머신 간의 트래픽을 필터링하십시오.
리로드 전에 Caddyfile 검증하기
수정된 Caddyfile을 맹목적으로 리로드하지 마십시오. 구문을 검증하고, 서비스를 리로드한 후 상태와 로그를 확인하십시오.
sudo caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile
sudo systemctl reload caddy
sudo systemctl status caddy --no-pager
sudo journalctl -u caddy -n 50 --no-pager
caddy validate는 오류 없이 완료되어야 합니다. systemctl reload caddy는 데몬의 전체 재시작 없이 구성을 적용하며, 서비스가 리로드를 허용할 때 적용됩니다.
리로드 후 systemctl status는 active를 표시해야 합니다. 인증서가 발급되지 않거나 백엔드가 연결을 거부하면 journalctl이 유용한 오류를 가리킵니다: DNS, 사용 중인 포트, 방화벽 또는 로컬 서비스가 없습니다.
다른 머신에서 HTTPS 테스트하기
VPS의 로컬 테스트만으로는 충분하지 않습니다. 인터넷을 통해 요청을 전송하거나 외부 테스트에서 실행하십시오.
curl -I https://app.exemple.net/
curl -v https://app.exemple.net/ -o /dev/null
curl는 예상 HTTP 코드를 표시해야 합니다. -v를 사용하여 인증서의 이름, TLS 협상 및 가능한 리디렉션을 확인하십시오.
HTTP 응답을 진단하기 위해, 가이드는 리눅스에서의 Curl가 헤더를 읽는 데 도움을 줍니다. 열린 포트 확인은 듣기 충돌을 감지하는 데 유용합니다. systemd 서비스 확인는 재시작 전 데몬을 점검하는 데도 유용합니다.
Caddy 리버스 프록시는 브라우저와 서버 간의 트래픽을 암호화하지만, 애플리케이션의 인증을 대체하지는 않습니다. 관리 대시보드를 노출하기 전에 보호를 추가하거나 IP, VPN 또는 애플리케이션 규칙에 의해 액세스를 제한하십시오.