SSL을 사용하는 Nginx 역방향 프록시

개인 포트에서 웹 응용 프로그램을 실행중인 경우 (예 : 로컬 호스트 : 3000), 인터넷을 통해 직접 액세스 할 수 없습니다.해당 앱을 안전하게 노출시키는 가장 효과적인 방법 중 하나는 리버스 프록시를 앞에 놓는 것입니다.

Nginx는 Let 's Encrypt의 무료 SSL 인증서로 HTTPS를 처리하는 동시에 정확히이를 수행 할 수있는 가벼운 잘 알려진 도구입니다.

이 안내서에서는 다음 방법을 배웁니다.

• 내부 웹 서비스의 리버스 프록시로 nginx를 설정
  
• CertBot을 사용하여 SSL 인증서로 고정하십시오
  
• 구성의 각 부분을 이해하여 무엇을하고 있는지 알 수 있습니다.

웹 서버를 처음 접했습니까?우리의 설명을 확인하십시오 웹 서버 작동 방식.

리버스 프록시 란 무엇이며 왜 사용합니까?

ㅏ 역 프록시 사용자와 백엔드 서비스간에 위치한 서버입니다.Nginx는 포트에서 공개적으로 청취하는 대신 먼저 트래픽을 수신 한 다음 백그라운드에서 실행되는 앱으로 전달합니다.

이 접근법이 유용한 이유는 다음과 같습니다.

• 내부 포트 및 서비스를 숨 깁니다
  앱을 대중에게 직접 노출시킬 필요는 없습니다.이는 공격 표면을 줄이고 액세스를 제어하는 ​​데 도움이됩니다.
  
• 당신을 위해 HTTP를 처리합니다
  많은 웹 프레임 워크는 HTTPS를 직접 제공 할 수 있지만, 특히 Let 's Encrypt의 무료 SSL 인증서를 사용할 때 Nginx가 수행 할 수있는 것이 더 쉽고 신뢰할 수 있습니다.
  
• 하나의 서버에서 여러 서비스를 호스팅 할 수 있습니다
  다른 포트 (3000, 4000, 5000)에서 여러 앱을 실행하고 하나의 공개 IP 만 사용하여 도메인 또는 경로를 기반으로 트래픽을 라우팅 할 수 있습니다.
  
• 로깅 및 모니터링을 향상시킵니다
  Nginx는 중앙 집중식 액세스 및 오류 로그를 제공하므로 성능을 모니터링하거나 문제를 조사 할 수 있습니다.
  
• 옵션 캐싱,로드 밸런싱 및 속도 제한을 제공합니다
  NGINX 구성에서 몇 줄만으로 트래픽 흐름을 최적화하고 백엔드 서비스를 보호 할 수 있습니다.

앱이 이미 웹 트래픽을 처리 할 수 ​​있더라도 Nginx를 역전 프록시로 사용하면 종종 설정을 단순화하고 유연성을 향상 시키며 제어를 향상시킵니다.

전제 조건

시작하기 전에 필요한 모든 것을 갖추십시오.

• Ubuntu 20.04 이상을 실행하는 VPS 또는 클라우드 서버 : 이 자습서에 사용 된 대부분의 명령 및 패키지 버전은 데비안 기반 시스템을 가정합니다.NGINX 및 CERTBOT는 다른 배포판에서 작동하지만 설정 프로세스가 다를 수 있습니다.
• 루트 또는 sudo 액세스 : 패키지, 시스템 파일 편집 및 서비스 다시 시작 서비스를 설치하게됩니다.
• 등록 된 도메인 이름 : SSL 인증서를 요청하려면이 작업이 필요합니다.인증서를 발행하기 전에 도메인의 소유권을 검증하자.DNS가 서버를 가리키지 않으면 유효성 검사가 실패합니다.
• 서버의 공개 IP를 가리키는 DNS : 도메인의 DNS 레코드가 업데이트되었는지 확인하십시오.서버의 IP를 가리키는 간단한 레코드로 충분합니다.

A yourdomain.com → 123.123.123.123
A www.yourdomain.com → 123.123.123.123

전파는 몇 분에서 몇 시간이 걸릴 수 있습니다.

DNS를 구성하는 방법을 모르십니까?여기에 있습니다 레코드를 추가하는 방법 대부분의 도메인 호스트가 있습니다.

• LocalHost에서 실행되는 응용 프로그램 (예 : http://localhost:3000): 이것은 당신이 프록시 할 앱입니다.Node.js, Python Flask, Ruby on Rails 등이있을 수 있습니다. 로컬 포트에서 듣는 한 프록시 할 수 있습니다.

노트 : 앱이 아직 실행되지 않으면 괜찮습니다. 여전히 설정을 거쳐 나중에 테스트 할 수 있습니다.

• Nginx 설치 : Nginx는 공개 서버 역할을합니다.아직 설치되지 않은 경우 :

sudo apt update
sudo apt install nginx

그런 다음 실행 중인지 확인하십시오.

sudo systemctl status nginx

"Active (Running)"가 표시됩니다.

• Nginx 플러그인으로 설치된 CertBot : Certbot은 Let 's Encrypt에서 SSL 인증서를 얻고 갱신하는 프로세스를 자동화합니다.다음과 같이 설치하십시오.

sudo apt install certbot python3-certbot-nginx

이 플러그인을 사용하면 Certbot을 사용하면 인증서를 요청할 때 기본 설정에 수동 편집이 필요하지 않습니다.

다른 운영 체제가 있습니까?이 안내서를 따르십시오 설치 방법하자 암호화 페도라와 데비안에서

1 단계 : Nginx 리버스 프록시를 설정하십시오

시스템이 준비되었으므로 첫 번째 실제 단계는 NGINX를 도메인의 트래픽을 듣고 내부 응용 프로그램으로 전달하도록 구성하는 것입니다. 이것이 NGINX가 역전 프록시 역할을하는 것입니다.

이것이 중요한 이유

이 설정이 없으면 웹 사이트를 방문하려는 사용자는 빈 페이지 나 기본 NGINX 환영 화면에 도달합니다.nginx를 명시 적으로 말해야합니다.

• 응답 해야하는 도메인
  
• 들어오는 요청으로해야 할 일
  
• 무대 뒤에서 트래픽을 보내는 곳

새 서버 블록을 만듭니다

Nginx 사이트에서 사용할 수있는 디렉토리에서 도메인에 대한 구성 파일을 작성합니다.이를 통해 구성을 정리하고 개별 사이트를 쉽게 활성화하거나 비활성화 할 수 있습니다.

sudo nano /etc/nginx/sites-available/yourdomain.com

필요에 따라 도메인 및 앱 포트를 조정하여 다음 블록에 붙여 넣습니다.

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;

    location / {
        proxy_pass http://localhost:3000;
        proxy_http_version 1.1;

        # Pass important headers to the backend
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

이 구성이하는 일

• 80;
  Nginx는 포트 80에서 HTTP 트래픽을 듣도록 지시합니다.
  
• server_name yourdomain.com www.yourdomain.com;
  이 블록을 도메인에 대한 요청과 일치시킵니다.필요에 따라 하위 도메인을 추가하거나 제거 할 수 있습니다.
  
• 위치 /
  모든 요청을 루트로 가져 와서 앱으로 전달합니다.
  
• proxy_pass http : // localhost : 3000;
  이것은 리버스 프록시의 핵심입니다. 포트 3000에서 실행되는 백엔드 앱에 요청을 보냅니다.
  
• proxy_set_header 라인
  이들은 원래 클라이언트 요청에서 다음과 같은 세부 정보를 보존합니다.
  
  • 사용자의 IP 주소 (x- 비틀는 IP)
    
  • 원래 프로토콜 (HTTP 또는 HTTPS)
    
  • 원본 호스트 이름
    
• 이 정보는 로깅, 분석 또는 앱이 방문자의 경험과 일치하는 URL을 생성 해야하는 경우에 유용합니다.

구성을 활성화합니다

Nginx는 상징적 링크를 사용합니다 사이트가 가능합니다 사이트를 활성화하기위한 디렉토리.이제 링크를 만들고 nginx를 다시로드 할 것입니다.

sudo ln -s /etc/nginx/sites-available/yourdomain.com /etc/nginx/sites-enabled/
sudo nginx -t

구문 오류를 확인하십시오.모든 것이 좋아 보인다면 :

sudo systemctl reload nginx

리버스 프록시는 이제 라이브입니다 - 요청 http://yourdomain.com 포트 3000의 앱으로 전달됩니다.

2 단계 : Let 's Encrypt 및 Certbot과 함께 SSL을 추가하십시오

HTTP에서 리버스 프록시가 작동하면 다음 단계는 HTTPS로 고정하는 것입니다.이렇게하면 사용자와 서버 간의 모든 통신에 암호화가 추가됩니다 (로그인 자격 증명, API 요청, 개인 데이터 등).

무료 인증 기관인 Let 's Encrypt 및 프로세스를 자동화하는 Certbot을 사용합니다.

HTTP가 중요한 이유

• 트래픽을 암호화합니다 따라서 아무도 그것을 가로 채거나 변조 할 수 없습니다
  
• SEO를 향상시킵니다 - 검색 엔진은 안전한 사이트를 선호합니다
  
• 신뢰를 구축합니다 - 사용자는 자물쇠 아이콘을 볼 것으로 예상됩니다
  
• 많은 API, 로그인 및 지불 시스템에 필요합니다

인증서를 요청하십시오

도메인을 실제 값으로 바꾸고이 명령을 실행하십시오.

sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com

이것이하는 일 :

• Certbot에 Nginx 플러그인을 사용하도록 지시합니다
  
• 인증서를 요청하는 도메인을 지정합니다

Certbot은 다음과 같습니다.

• nginx config에서 임시 파일을 작성하여 도메인 유효성 검사 수행
  
• 도메인 소유권을 확인하려면 암호화하자
  
• SSL 인증서 및 개인 키를 다운로드하십시오
  
• HTTPS를 사용하려면 nginx 구성을 수정하십시오
  
• 선택적으로 모든 HTTP 트래픽을 HTTP로 리디렉션합니다

팁: DNS가 완전히 전파되지 않았거나 서버 방화벽이 포트 80을 차단하면 유효성 검사가 실패합니다.다음과 같이 테스트 할 수 있습니다.

curl -I http://yourdomain.com

포트를 더 잘 이해하려면 가이드를 확인하십시오 웹 서버 포트의 작동 방식.

변경 사항을 확인하십시오

CertBot이 완료되면 NGINX 구성이 다음과 같은 내용을 포함해야합니다.

listen 443 ssl;
ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;

이제 https://yourdomain.com을 방문하여 유효한 SSL 인증서가있는 사이트를 볼 수 있어야합니다.

선택 사항 : 강제 HTTPS

Certbot 설정 중에 리디렉션 옵션을 선택하지 않은 경우 수동으로 추가 할 수 있습니다.

server {
    listen 80;
    server_name yourdomain.com www.yourdomain.com;
    return 301 https://$host$request_uri;
}

이로 인해 모든 HTTP 트래픽이 HTTP로 리디렉션되므로 사용자는 실수로 안전하지 않은 사이트의 사이트를 사용하지 않도록합니다.

3 단계 : SSL 설정 개선 (생산 권장)

SSL 인증서가 설치되면 Nginx를 미세 조정하여 보안 및 호환성을 향상시킬 수 있습니다.이러한 설정은 HTTPS 서버 블록 내부에 들어갑니다.

개선 된 예는 다음과 같습니다.

ssl_protocols TLSv1.2 TLSv1.3;
ssl_prefer_server_ciphers on;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 10m;
ssl_session_tickets off;

이 설정이하는 일

• ssl_protocols TLSv1.2 TLSv1.3
  TLS 1.0 및 1.1과 같은 더 오래되고 덜 안전한 프로토콜을 비활성화합니다.
  
• ssl_prefer_server_ciphers on
  서버가 브라우저를 연기하지 않고 암호화 알고리즘을 결정할 수 있습니다. 이는 약한 암호 공격에 대한 노출을 줄일 수 있습니다.
  
• SSL_CIPHERS HIGH :! anull :! md5
  강력한 암호 스위트를 지정하고 약하거나 부러진 제품 (MD5 및 Null 암호)을 제외합니다.
  
• ssl_session_cache 및 ssl_session_timeout
  SSL 세션 재사용을 제어하여 보안을 손상시키지 않고 성능을 약간 향상시킬 수 있습니다.
  
• ssl_session_tickets off
  정기적으로 회전하지 않으면 보안 문제가 될 수있는 세션 티켓을 비활성화합니다.

이러한 변화는 SSL 보안 점수를 향상시키고 다운 그레이드 공격 또는 불안한 암호화 선택으로부터 방문자를 보호합니다.

선택 과목: SSL 실험실로 사이트를 테스트하여 구성 수행 방법을 확인하고 구체적인 개선 제안을 얻을 수 있습니다.

4 단계 : (선택 사항) Diffie-Hellman 매개 변수를 추가하십시오

더 강한 암호화를 위해서는 사용자 정의 Diffie-Hellman (DH) 키를 생성 할 수 있습니다.이 단계는 선택 사항이지만 생산 환경에 종종 권장됩니다.

이 명령을 실행하여 2048 비트 DH 그룹을 생성하십시오.

sudo openssl dhparam -out /etc/ssl/certs/dhparam.pem 2048

그런 다음 SSL 서버 블록에 다음 줄을 추가하십시오.

ssl_dhparam /etc/ssl/certs/dhparam.pem;

왜 이것을 추가합니까?

Diffie-Hellman 매개 변수가 강화됩니다 전진 비밀, 개인 키가 미래에 어떻게 든 타협하더라도 과거의 암호화 된 세션은 여전히 ​​안전합니다.

DH 그룹을 생성하는 데 몇 분이 걸리지 만 일회성 단계이며 더 나은 보안 자세를 위해 할 가치가 있습니다.

5 단계 : SSL 인증서에 대한 자동 갱신 설정

인증서를 암호화하자 90 일마다 만료됩니다.다행스럽게도 Certbot은 만료되어 인증서가 자동으로 갱신되어 인증서를 하루에 두 번 확인하는 시스템 타이머를 설치합니다.

타이머가 활성화되어 있는지 확인할 수 있습니다.

sudo systemctl list-timers | grep certbot

당신은 다음과 같은 것을보아야합니다.

NEXT                         LEFT    LAST                         PASSED  UNIT           ACTIVATES
2025-06-19 04:00:00 UTC      12h     2025-06-18 04:00:00 UTC       11h ago certbot.timer  certbot.service

갱신 프로세스를 수동으로 테스트하려면 (변경하지 않고) 실행하십시오.

sudo certbot renew --dry-run

이는 전체 갱신 프로세스를 시뮬레이션하고 시스템이 자동으로 처리 할 준비가되었음을 확인합니다.

오류가 없으면 앞으로 백그라운드에서 인증서가 조용히 갱신됩니다.

최종 단계와 좋은 습관

리버스 프록시가 SSL로 설정되어 고정되었으므로 몇 가지 실용적인 점검과 모범 사례를 마무리하는 것이 좋습니다.

이러한 간단한 습관은 문제를 예방하고 구성을보다 쉽게 ​​유지할 수 있도록하는 데 도움이되며 모든 것이 기대하는 방식으로 계속 실행되도록 할 수 있습니다.

모든 것이 작동하는 것처럼 보이더라도 여기에서 몇 분을 더 소비하면 나중에 시간과 문제를 줄 수 있습니다.

변경 사항을 자동으로 감지하지 않으면 앱을 다시 시작하십시오
프록시 뒤에서 올바르게 작동하려면 일부 앱을 다시 시작해야합니다.

로그를 확인하십시오
오류 또는 비정상적인 트래픽에 대한 Nginx 로그를 모니터링 할 수 있습니다.

sudo tail -f /var/log/nginx/access.log
sudo tail -f /var/log/nginx/error.log

nginx 및 certbot을 업데이트하십시오
sudo apt update && sudo apt 업그레이드를 정기적으로 사용하십시오.업데이트 된 패키지는 버그를 수정하고, 호환성을 향상시키고, 패치 보안 문제를 해결합니다.

SSL을 사용한 NGINX 리버스 프록시의 고급 사용 사례

안전한 리버스 프록시를 설정하는 기본 사항을 마스터하면 구성을 확장하여보다 복잡한 요구를 지원할 수 있습니다.다음은 서버에서 더 많은 것을 얻는 데 도움이되는 몇 가지 일반적인 시나리오입니다.

하나의 서버에서 여러 응용 프로그램을 호스팅합니다

다른 포트에서 여러 웹 앱을 실행하는 경우 Nginx는 도메인 또는 URL 경로를 기반으로 각 앱에 요청을 라우팅 할 수 있습니다.

예 : 다른 도메인

server {
    listen 80;
    server_name app1.example.com;

    location / {
        proxy_pass http://localhost:3001;
        # proxy headers here
    }
}

server {
    listen 80;
    server_name app2.example.com;

    location / {
        proxy_pass http://localhost:3002;
        # proxy headers here
    }
}

이 설정을 사용하면 표준 포트의 NGINX를 통해 별도의 하위 도메인을 사용하여 여러 앱을 제공 할 수 있습니다.

Docker 사용?배우다 Nginx로 여러 Docker 앱을 프록시하는 방법.

경로 기반 프록시

또는 URL 경로를 기반으로 프록시를 할 수 있습니다. 단일 도메인에서 모든 앱을 원하는 경우 유용합니다.

server {
    listen 80;
    server_name example.com;

    location /app1/ {
        proxy_pass http://localhost:3001/;
        # proxy headers here
    }

    location /app2/ {
        proxy_pass http://localhost:3002/;
        # proxy headers here
    }
}

노트 : 경로 기반 프록시를 사용하는 경우, 후행 슬래시 및 URL 재 작성이 까다로워 질 수 있습니다. 백엔드 앱이 하위 경로 아래에서 제공되는 것을 처리 할 수 ​​있는지 확인하십시오.

앱을 보호하기 위해 속도 제한 추가

고객이 주어진 시간 내에 작성할 수있는 요청 수를 제한하여 백엔드가 남용 또는 우발적 인 과부하로부터 보호를 보호합니다.

/etc/nginx/nginx.conf의 http 블록에 이것을 추가하십시오.

limit_req_zone $binary_remote_addr zone=mylimit:10m rate=10r/s;

그런 다음 서버 또는 위치 블록에서 :

limit_req zone=mylimit burst=20 nodelay;

이 구성은 최대 20 개의 요청 버스트로 초당 10 번의 요청을 허용하여 앱을 압도하지 않도록 초과 요청을 삭제합니다.

여러 백엔드 서버에서로드 밸런싱

앱 실행 중 여러 인스턴스 (예 : 여러 컨테이너 또는 VPS)가있는 경우 Nginx는 트래픽을 배포 할 수 있습니다.

upstream backend {
    server 192.168.1.10:3000;
    server 192.168.1.11:3000;
}

server {
    listen 80;
    server_name example.com;

    location / {
        proxy_pass http://backend;
        # proxy headers here
    }
}

Nginx는 기본적으로 라운드 로빈을 요청하지만 최소 연결 또는 IP 해시와 같은 다른 방법에 대해 구성 할 수 있습니다.

자세한 내용은 가이드를 확인하십시오 DNS로드 밸런싱.

로깅 및 디버깅

문제 해결 또는 분석을위한 중요한 프록시 정보를 포함하도록 로깅을 사용자 정의 할 수 있습니다.

log_format proxy '$remote_addr - $remote_user [$time_local] '
                 '"$request" $status $body_bytes_sent '
                 '"$http_referer" "$http_user_agent" '
                 'upstream_response_time $upstream_response_time '
                 'request_time $request_time';

access_log /var/log/nginx/proxy_access.log proxy;

이로 인해 업스트림 응답 시간과 총 요청 시간이 기록되어 느린 백엔드 응답을 식별하는 데 도움이됩니다.

맞춤형 헤더 및 보안 향상

보안 또는 기능을 위해 HTTP 헤더를 추가하거나 수정할 수 있습니다.

add_header X-Frame-Options SAMEORIGIN;
add_header X-Content-Type-Options nosniff;
add_header Referrer-Policy no-referrer-when-downgrade;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

이 헤더는 클릭 재킹, 마임 스니핑 및 HTTPS 사용을 시행하지 않도록 보호합니다.