NGINX 가이드 · 12 min read · Jan 24, 2026
HTTP(S), SSH 및 MySQL/MariaDB를 위한 NGINX 리버스 프록시 실행 가이드
이 가이드는 여러 물리 서버, 가상 머신 또는 둘의 조합을 단일 공용 IP 주소 뒤에서 실행할 수 있도록 NGINX의 설치 및 구성을 안내합니다. 여러 웹 서버를 가상 머신에서 실행하고 이를 로컬에서 관리할 수도 있고, 정상 근무 시간 외에 로컬 접근이 불가능할 경우 각 호스트에 SSH와 같은 원격 접근 도구를 사용해야 할 수도 있습니다. 이 가이드는 두 가지 시나리오를 모두 지원합니다.
여기에서 보여주는 구성은 사용 가능한 공용 IP 주소에 제한이 있는 홈 실험실이나 소규모 비즈니스 네트워크에 가장 적합합니다. 호스팅 서비스에서 임대한 여러 서버나 가상 머신이 있는 경우, 각 서버나 호스트에 대해 공용 IP 주소가 할당되므로 이러한 구성을 실행할 이유는 거의 없습니다.
저는 NGINX를 설치하고 HTTP(S), SSH, FTP 및 MySQL/MariaDB의 리버스 프록시 역할을 할 수 있도록 구성하는 방법을 보여드리겠습니다. NGINX 호스트 서버에 대해 로컬 접근이 가능하고, Ubuntu 18.04의 새 설치가 있으며, Ubuntu 서버 설치 단계에서 SSH 서버 설치를 선택했다고 가정합니다.
이 구성은 저에게 잘 작동하지만, 이것이 여러분에게도 작동할 것이라고 보장할 수는 없음을 이해해 주시기 바랍니다. 물론, 문제가 있는 경우 수정할 수 있도록 알려주십시오. 시작하기 전에 전체 가이드를 읽어보시기 바랍니다. 관리 방법을 보여주는 두 가지 방법이 있는 한 부분(스트림)이 있습니다.
시작하기
이 가이드에서는 다음 호스트 이름과 IP 주소를 사용합니다.
rproxy.example.com 192.168.1.1
web1.example.com 192.168.1.2
db1.exmple.com 192.168.1.3표준 Ubuntu 18.04 서버 설치를 위해 설치 중에 생성한 비루트 사용자 계정이 있어야 합니다. NGINX를 설치할 서버에 해당 사용자로 로그인하여 시작합니다. 이는 대부분 로컬 서버일 가능성이 높으므로 SSH 서버를 구성하기 위해 처음에는 서버에 직접 로그인해야 할 수 있습니다. 이를 위해 서버에 키보드와 모니터가 연결되어 있어야 합니다.
참고: 저처럼 VMWare와 같은 가상화 소프트웨어를 사용하는 경우 브라우저 인터페이스가 포함되어 있으므로 해당 시스템 내에서 콘솔이 있어 이 단계를 “직접” 접근 없이 수행할 수 있습니다. 해당 콘솔 내에서 전체 구성을 시도할 수 있지만, 브라우저 기반 콘솔에서 복사 및 붙여넣기와 같은 일부 기능이 작동하지 않았습니다. 이는 브라우저에 따라 다를 수 있으므로 시도해 볼 가치가 있습니다.
호스트 서버 준비
콘솔 셸에서 (브라우저 또는 직접 연결)
sudo nano /etc/ssh/sshd_config주석을 제거하고 포트 번호를 23456과 같은 것으로 변경하고 ListenAddress를 0.0.0.0으로 변경합니다. nano에 익숙하지 않은 분들을 위해 CTRL + X를 누르고 y를 입력한 후 Enter를 누릅니다. 이렇게 하면 파일이 저장되고 닫힙니다. 파일에 변경 사항이 없으면 CTRL + X를 눌러 저장하라는 메시지 없이 파일을 닫을 수 있습니다. 명령 프롬프트로 돌아갑니다.
이 파일 내의 나머지 설정에 대해서는 깊이 들어가지 않겠습니다. 이미 상당히 긴 가이드이며, SSH 키 사용 및 루트 SSH 로그인 허용과 같은 여러 가지를 위해 변경해야 할 설정을 보여주는 많은 가이드가 있습니다. 이러한 가이드는 HowtoForge 웹사이트에서도 찾을 수 있습니다.
변경이 완료되면 ssh 서버를 재시작하여 변경 사항이 적용되도록 해야 합니다. 현재 로그인에는 이 재시작의 영향을 받지 않습니다.
systemctl restart ssh로컬 네트워크 내의 다른 컴퓨터의 터미널에서 SSH를 사용하여 로그인할 수 있는지 확인합니다.
ssh [email protected] -p23456SSH를 사용하여 성공적으로 로그인한 후 이 터미널을 열어 두고 콘솔/서버에서 로그아웃합니다. 이제 이 가이드를 진행하는 동안 더 이상 사용할 필요가 없습니다.
이 시점부터는 터미널에서 루트 수준의 명령을 실행하게 됩니다. 다음 명령은 이후 명령에 sudo를 추가할 필요를 없애줍니다.
sudo -sApt 패키지 데이터베이스를 업데이트하고 Ubuntu를 업그레이드하여 최신 패키지가 설치되도록 합니다.
apt update && apt -y upgrade업그레이드 중에 새 커널이 설치되었다는 보고가 표시되면 apt가 업그레이드를 마친 후 재부팅하여 완전히 업데이트된 시스템에서 작업하고 있는지 확인해야 합니다.
리버스 프록시 서버의 호스트 이름 설정
hostnamectl set-hostname rproxy.example.com가상 서버를 실행 중인 경우 여기에서 설정한 호스트 이름을 보존하기 위해 수정해야 하는 cloud.cfg라는 파일이 있을 수 있습니다. 다음 명령은 내용이 있는 파일을 보여주거나 빈 페이지를 보여줍니다. 빈 페이지가 표시되면 CTRL + X를 눌러 이 단계를 건너뛸 수 있습니다.
nano /etc/cloud/cloud.cfg보존 호스트 이름 줄을 true로 변경하고 파일을 닫고 저장합니다.
현재 시스템이 로컬 전용인 경우 이 서버에 다른 서버/가상 호스트가 어디에 있는지 보여줘야 합니다.nano /etc/hosts변경 후 hosts 파일은 다음과 비슷하게 보일 것이며, IP 주소와 호스트는 자신의 인프라에 맞아야 합니다.
127.0.0.1 localhost
127.0.1.1 rproxy.example.com
192.168.1.2 web1.example.com
192.168.1.3 db1.example.com
# IPv6 지원 호스트에 대해 바람직한 다음 줄
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allroutersNGINX 설치
apt install -y nginx설치 후 NGINX 버전을 확인해야 합니다. SSH 및 MySQL/MariaDB의 리버스 프록시를 허용하려면 1.9 이상의 버전이 필요합니다.
nginx -v보시다시피, 저는 Ubuntu 18.04에서 기본값인 NGINX 버전 1.14가 설치되어 있습니다. (2019년 10월 10일)
nginx version: nginx/1.14.0 (Ubuntu)NGINX를 리버스 프록시로 작동하도록 준비하기
이 구성에서는 리버스 프록시 호스트 서버에서 웹사이트를 직접 제공하지 않습니다. /etc/nginx/ 아래에 새로운 디렉토리 구조를 생성합니다. 이렇게 하면 나중에 이러한 변경을 되돌리거나 이 호스트에서 웹사이트를 직접 제공하기로 결정할 경우 기본 NGINX 구성을 보존할 수 있습니다. 기본 구성을 이러한 리버스 프록시 구성과 함께 실행할 수 있지만, Apache2가 동일한 서버에 있을 경우 수신 대기할 대체 포트가 필요하며, 이 Apache2 인스턴스가 제공하는 웹사이트를 여전히 리버스 프록시해야 합니다.
리버스 프록시 디렉토리 구조 구축
cd /etc/nginx && mkdir rproxy && cd rproxy && mkdir http http/available http/enabled stream stream/available stream/enabled구조가 마련되었으므로 구성 파일을 생성하는 작업을 진행할 수 있습니다. 저는 nano를 사용하지만 편한 편집기를 사용하셔도 됩니다. Nano는 저장 시 파일을 생성/업데이트합니다.
진행하기 전에 컴퓨터에서 빈 문서를 열거나 메모를 위해 펜과 종이를 준비하십시오.웹 서버 리버스 프록시 구성 (http)
웹사이트에 대한 http 구성 파일을 생성하고 적절히 조정합니다.
nano http/available/example.com.conf서버 블록을 터미널에서 nano로 연 페이지에 복사하고 적절히 조정합니다.
# 포트 80 및 443을 메모하십시오.
server {
server_name example.com www.example.com;
listen 80;
set $upstream 192.168.1.2;
location / {
proxy_pass_header Authorization;
proxy_pass http://$upstream;
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_http_version 1.1;
proxy_set_header Connection "";
proxy_buffering off;
client_max_body_size 0;
proxy_read_timeout 10000s;
proxy_redirect off;
}
}SSH, MySQL/MariaDB 리버스 프록시 구성 (스트림)
진행하기 전에 각 호스트 또는 서비스별로 사용할 것인지 결정하십시오. 호스트별로 각 호스트에 대한 구성을 생성하여 단일 호스트 설정을 빠르게 변경할 수 있습니다. 서비스별로는 모든 서버의 서비스 포트를 각 파일에 SSH, MySQL/MariaDB 및 FTP로 설정합니다.
서비스별 구성 사용
SSH 구성을 추가합니다.
nano stream/available/ssh.conf# 수신 대기 포트를 메모하십시오.
upstream web1-ssh {
server 192.168.1.2:22;
}
server {
listen 22002;
proxy_pass web1-ssh;
}
upstream db1-ssh {
server 192.168.1.3:22;
}
server {
listen 22003;
proxy_pass db1-ssh;
}
# 원격으로 접근하는 SSH 서버에 필요한 만큼 upstream 및 server 블록 쌍을 추가하십시오.MySQL/MariaDB 구성을 추가합니다.
nano stream/available/db.conf# 수신 대기 포트를 메모하십시오.
upsteam db1-mysql {
server 192.168.1.3:3306;
}
server {
listen 33063;
proxy_pass db1-mysql;
}
# 원격으로 접근하는 MySQL/MariaDB 서버에 필요한 만큼 upstream/server 블록 쌍을 이 파일에 추가하십시오.이제 FTP 리버스 프록시 구성을 생성합니다.
nano stream/available/ftp.confupstream web1-ftp {
server 192.168.1.3:21
}
server {
listen 21002;
proxy_pass web1-ftp;
}
# 원격으로 접근하는 FTP 서버에 필요한 만큼 upstream/server 블록 쌍을 추가하십시오.호스트별 구성 파일 사용
nano /etc/nginx/rproxy/stream/available/web1.example.com.conf# 수신 대기 포트를 메모하십시오.
upstream web1-ssh {
server 192.168.1.3:22;
}
server {
listen 22002;
proxy_pass web-ssh;
}
db1.example.com에 대한 호스트 파일 생성
nano /etc/nginx/rproxy/stream/available/db1.example.com.conf# 수신 대기 포트를 메모하십시오.
upsteam db1-mysql {
server 192.168.1.3:3306;
}
server {
listen 33063;
proxy_pass db1-mysql;
}
upstream db1-ssh {
server 192.168.1.3:22;
}
server {
listen 22003;
proxy_pass db1-ssh;
}
보시다시피, 약간 비정상적입니다. 공용 포트를 비표준 방식으로 사용하고 있으며, 필요한 포트를 선택한 다음 이를 NGINX에 지정하고 있습니다. 이는 정상적이지만, 이제 원격으로 접근하려는 각 서버의 각 서비스에 대해 다른 포트를 사용하고 있습니다. 예를 들어 SSH의 경우, 각 SSH 활성화 호스트에 대해 22, 222, 2222, 22222와 같은 서로 다른 포트 번호가 있으며, 이는 서로 다른 서버나 가상 머신의 포트 22를 가리킵니다.
NGINX가 웹사이트를 리버스 프록시하는 경우는 다릅니다. NGINX에 대해 웹사이트에 대한 서버 구성이 정의되어 있는 한, 포트 80 및 443만 전달되면 제대로 작동합니다.
이 시점에서 HTTP 단계를 사용하고 스트림 단계를 건너뛰고 여러 서비스를 적절한 서버/IP 주소로 여러 포트를 전달할 수 있다는 것을 깨달았을 것입니다. 실제로 그렇게 할 수 있습니다. 그러나 이는 복잡성을 추가하고 서버 수가 증가함에 따라 유지 관리가 어려워질 수 있습니다. 각 서버의 ssh, mysql 및 ftp에 대한 기본 포트를 변경해야 할 수도 있기 때문입니다. 이 구성은 이미 복잡하므로 원하신다면 그렇게 할 수 있습니다.
이러한 서비스를 리버스 프록시로 사용하는 방식은 이러한 구성 변경을 수행할 수 있는 단일 위치를 제공하여 전체 인프라에서 포트를 변경할 필요가 없으므로 복잡성을 크게 줄입니다.
이 구성의 추가 이점으로, 인프라의 다른 서버는 로컬 인터페이스 및 기본 포드에서 수신 대기하기만 하면 됩니다. 로컬에서 관리하는 경우, 필요한 서비스에 접근하기 위해 로컬 IP 주소 및 기본 서비스 포트를 사용할 수 있으므로 올바른 포트를 기억하기 위해 메모를 참조할 필요가 없습니다. IP 주소와 로그인 자격 증명만 알면 됩니다.
모든 것을 통합하기
NGINX 리버스 프록시 구성을 사용하려면 기본 구성 파일을 일부 수정해야 합니다. http 블록에서 현재 포함된 줄의 주석을 제거합니다(웹사이트를 NGINX에서 직접 제공하지 않는 경우).
cd /etc/nginx && nano nginx.conf변경해야 할 부분을 확인하기 위해 아래 강조된 부분을 주목하십시오.
user www-data;
worker_processes auto;
pid /run/nginx.pid;
include /etc/nginx/modules-enabled/*.conf;
events {
worker_connections 768;
# multi_accept on;
}
http {
##
# 기본 설정
##
sendfile on;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# server_tokens off;
# server_names_hash_bucket_size 64;
# server_name_in_redirect off;
include /etc/nginx/mime.types;
default_type application/octet-stream;
##
# SSL 설정
##
ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # SSLv3 드롭, 참조: POODLE
ssl_prefer_server_ciphers on;
##
# 로깅 설정
##
access_log /var/log/nginx/access.log;
error_log /var/log/nginx/error.log;
##
# Gzip 설정
##
gzip on;
gzip on;
# gzip_vary on;
# gzip_proxied any;
# gzip_comp_level 6;
# gzip_buffers 16 8k;
# gzip_http_version 1.1;
# gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascri$
##
# 가상 호스트 구성
##
include /etc/nginx/conf.d/*.conf;
# include /etc/nginx/sites-enabled/*;
# 리버스 프록시 http 구성 파일.
include /etc/nginx/rproxy/http/enabled/*.conf;
}
stream {
# 리버스 프록시 스트림 구성 파일.
include /etc/nginx/rproxy/streams/enabled/*.conf;
}
#mail {
# # 샘플 인증 스크립트 참조:
# # http://wiki.nginx.org/ImapAuthenticateWithApachePhpScript
#
# # auth_http localhost/auth.php;
# # pop3_capabilities "TOP" "USER";
# # imap_capabilities "IMAP4rev1" "UIDPLUS";
#
# server {
# listen localhost:110;
# protocol pop3;
# proxy on;
# }
#
# server {
# listen localhost:143;
# protocol imap;
# proxy on;
# }
#}
리버스 프록시 구성을 활성화합니다.
먼저 모든 http 구성을 활성화합니다.
ln -s /etc/nginx/rproxy/http/available/*.conf /etc/nginx/rproxy/http/enabled모든 스트림 구성을 활성화합니다.
ln -s /etc/nginx/rproxy/stream/available/*.conf /etc/nginx/rproxy/stream/enabledNGINX를 리버스 프록시로 올바르게 구성했는지 확인하기 위해 테스트를 수행합니다.
nginx -T출력에서 성공 메시지와 이전에 만든 모든 사용자 정의 구성을 확인할 수 있어야 합니다.
리버스 프록시 구성을 적용하기 위해 NGINX를 재시작합니다.
systemctl restart nginxNGINX가 모든 구성된 포트에서 수신 대기하고 있는지 확인합니다. 메모와 대조하여 모든 포트가 결과에 표시되는지 확인합니다.
netstat -tulpn | grep nginx출력은 다음과 비슷해야 합니다.
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:22002 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:22003 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:33062 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:33063 0.0.0.0:* LISTEN 4964/nginx: master
tcp 0 0 0.0.0.0:443 0.0.0.0:* LISTEN 4964/nginx: master 서버를 트래픽에 열기
이제 NGINX가 수신 대기 중이며 리버스 프록시로 작동할 준비가 되었으므로, 다음 단계를 진행하는 동안 UFW를 일시적으로 비활성화합니다. 제대로 작동하지 않을 경우 문제 해결이 더 쉬워집니다.
ufw disable포트 전달
불행히도, 여기에서 안내를 드릴 수 없습니다. 라우터의 매뉴얼을 참조하거나 온라인에서 라우터를 검색하여 방법을 알아보아야 합니다. 요약하자면, NGINX가 수신 대기하는 각 포트를 NGINX 호스트 머신으로 전달해야 합니다. 제 특정 라우터에서는 사용자 정의 “애플리케이션“을 설정할 수 있습니다.
이렇게 하면 할당되지 않은 포트나 포트 범위를 사용자 정의 애플리케이션에 할당할 수 있으며, 이후 LAN IP 주소나 호스트 이름으로 식별된 특정 연결된 장치에 할당됩니다. 즉, 이 사용자 정의 애플리케이션에 할당된 모든 포트를 네트워크의 어떤 호스트로든 전환할 수 있으며, 모든 포트를 삭제하고 다시 할당할 필요가 없습니다. 이는 훌륭한 옵션이며, 이를 지원하는 라우터를 선택할 것을 강력히 권장합니다.
라우터 방화벽의 이 작고도 매우 유용한 기능 덕분에 활성 리버스 프록시의 구성을 미러링하는 두 번째 리버스 프록시를 설치하게 되었습니다. 이를 꺼두고, 발견 후 3분 이내에 포트를 전환할 수 있습니다. 재해 복구를 위한 이 전환 시간을 충족하기 위해 고군분투할 전문 호스팅 회사들이 있을 것이라고 상상합니다. 이는 모두 홈 네트워크에서 여러 서버를 운영하고자 하는 욕구에서 비롯되었습니다.
리버스 프록시 서버를 위한 무료 Letsencrypt SSL
Certbot 및 Certbot NGINX 플러그인을 설치합니다. 이 단계는 인증서를 생성할 수 없기 때문에 모든 (서브)도메인 이름에 대해 기능적인 DNS가 있어야 하며, HTTP를 통해 도메인에 연결할 수 있어야 합니다. 포트를 리버스 프록시에 전달한 후 이를 완료하면 구성에 대한 추가 테스트 역할도 합니다. 도메인에 접근할 수 없어 인증서가 실패하면 출력에서 의미 있는 오류 메시지를 볼 수 있습니다.
최신 certbot 버전을 얻기 위해 설치 전에 certbot 저장소를 추가합니다. Ubuntu 저장소는 종종 소프트웨어 버전보다 하나 이상의 버전이 뒤쳐져 있으며, 가능한 한 모든 소프트웨어의 최신 안정 버전을 원합니다.
add-apt-repository ppa:certbot/certbot
apt install -y certbot python-certbot-plugincertbot 및 certbot nginx 플러그인이 설치되면 이제 NGINX에 대한 인증서를 생성할 수 있습니다.
이 명령은 SSL을 제공하려는 모든 도메인 및 서브도메인에 대해 반복해야 합니다. certbot을 처음 실행하는 경우, 약관에 동의해야 합니다.
certbot --nginx -d example.com -d www.example.com업스트림 호스트에 SSL이 작동하는 서버 설정이 있는 경우, 여기에서 선택한 옵션이 호스트 서버의 옵션과 일치하는지 확인해야 합니다. 특히, 업스트림 서버에서 https로 리디렉션하는 경우, 여기에서도 그렇게 해야 합니다.
명확히 하기 위해, example.com은 다른 서버에 존재하며, ISPConfig 내에서 http를 https로 리디렉션하도록 선택했으므로, 여기에서도 그렇게 선택합니다. 구성 파일이 업데이트되며 Certbot이 자체 구성을 추가한 것을 확인할 수 있습니다.
모든 것이 작동하는지 확인하기
이제 리버스 프록시로 트래픽이 흐를 수 있으므로 모든 것이 의도한 대로 작동하는지 확인해야 합니다. 웹사이트가 제대로 작동하는지 확인하고, SSH, FTP 및 MySQL/MariaDB 연결 및 작업을 수행합니다. 모든 것이 제대로 작동한다고 확신되면 UFW를 활성화하고 각 포트를 허용하는 규칙을 추가합니다.
리버스 프록시 서버 보안
ufw enable어디에서나 80 및 443을 허용하고, SSH, FTP 및 MySQL/MariaDB는 IP 주소나 호스트 이름으로 제한해야 합니다. 규칙에 주석을 달아 포트를 할당한 서비스/서버를 빠르게 식별할 수 있습니다.
ufw allow 80
ufw allow 443
ufw allow from 1.2.3.4 to any port 22002 comment 'web1 SSH'
ufw allow from somehost.domain.com to any port 33061 comment 'db1 MySQL/MariaDB'
ufw reload
ufw status numberedApache2 업데이트
리버스 프록시 뒤에서 실행할 때, Apache2 로그 파일은 웹사이트 방문자의 IP 주소 대신 리버스 프록시 서버의 IP 주소를 기록합니다. Apache2에 대한 정상 IP 주소 로깅을 복원하기 위해 이 동작을 수정하는 모듈이 있습니다.
Apache2 인스턴스가 설치된 각 웹 서버에서 다음 단계를 완료하십시오.
sudo apt install -y libapache2-mod-rpafApache2가 이제 올바른 IP 주소를 기록하도록 하려면 rpaf.conf 파일을 약간 수정해야 합니다. Ubuntu 18.04는 이미 파일을 생성했으며, 우리는 NGINX 리버스 프록시 호스트의 IP 주소로 강조된 IP 주소를 변경하기만 하면 됩니다.
nano /etc/apache2/mods-available/rpaf.conf
RPAFenable On
# 활성화되면, 수신 X-Host 헤더를 가져와
# 가상 호스트 설정을 accordingly:
RPAFsethostname On
# 올바른 X-Forwarded-For 헤더를 보내는 프론트엔드 프록시의 IP를 정의합니다:
RPAFproxy_ips 127.0.0.1 ::1
# 기본값에서 구문 분석할 헤더 이름을 변경합니다.
# X-Forwarded-For에서 선택한 것으로:
# RPAFheader X-Real-IP
최종 메모
동일한 호스트에서 NGINX 및 Apache2
서버나 가상 머신 내에서 두 서비스가 동일한 포트에서 수신 대기할 수 없습니다. NGINX가 Apache2 웹 서버와 동일한 서버나 가상 머신에 설치된 경우, Apache2가 수신 대기하는 포트를 변경해야 합니다. NGINX는 HTTP(S) 기능을 수행하기 위해 포트 80 및 443이 필요합니다. 이는 HTTP 및 HTTPS의 기본 포트입니다.
이 가이드의 http 섹션으로 돌아가서 이 Apache2 인스턴스에서 제공하는 웹사이트에 대한 리버스 프록시 구성을 다른 서버와 동일한 방식으로 추가하십시오.
Apache2 수신 대기 포트 변경
ISPConfig와 같은 서버 관리 시스템이 설치된 경우, 이 시스템은 Apache2 vhost 파일을 처리하므로 Apache2가 수신 대기하는 포트를 변경하는 방법을 조사해야 합니다. ISPConfig 포럼을 검색한 후 필요에 따라 조정하십시오. 그렇지 않으면 Ubuntu 포럼이나 Apache2 웹사이트에서 이러한 변경을 수행하는 방법을 찾아보십시오.
참고: 서버나 가상 머신에 설치된 유일한 웹 서버인 경우 Apache2 포트를 변경할 필요가 없습니다.새 게시물을 받은 편지함에서 받기
스팸은 없습니다. 언제든지 구독 해지 가능합니다.