CentOS 7 Light Package no included in fuser library package. 


# yum -y install psmisc
# fuser -k 80/tcp

fuser 로 Nginx 에서 기본적으로 잡고있던 80과 443을 다 죽이고 난 후에 

nginx 를 restart 하면 trouble shooting 완료




[emerg]: bind() to failed (98: Address already in use)


If you get following error, when you try to start nginx…

[emerg]: bind() to failed (98: Address already in use)

Then it means nginx or some other process is already using port 80.


You can kill it using:


sudo fuser -k 80/tcp


And then try restarting nginx again:


service nginx start

블로그 이미지



댓글을 달아 주세요



Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.


Want to improve this question? Update the question so it's on-topic for Stack Overflow.

Closed 6 years ago.

Improve this question

I am having trouble copying files from a remote server using SSH. Using PuTTY I log in to the server using SSH. Once I find the file I would like to copy over to my computer, I use the command:

scp username@host.com:/dir/of/file.txt \local\dir\

It looks like it was successful, but it only ends up creating a new folder labeled 'localdir' in the remote directory /dir/of/.

How can I copy the file to my local computer over SSH?



Improve this question


edited Oct 5 '18 at 18:04


17k20 gold badges95 silver badges175 bronze badges

asked May 31 '15 at 3:07


1,0432 gold badges8 silver badges6 bronze badges

Add a comment

5 Answers




It depends on what your local OS is.

If your local OS is Unix-like, then try:

scp username@remoteHost:/remote/dir/file.txt /local/dir/

If your local OS is Windows ,then you should use pscp.exe utility. For example, below command will download file.txt from remote to D: disk of local machine.

pscp.exe username@remoteHost:/remote/dir/file.txt d:\

It seems your Local OS is Unix, so try the former one.

For those who don't know what pscp.exe is and don't know where it is, you can always go to putty official website to download it. And then open a CMD prompt, go to the pscp.exe directory where you put it. Then execute the command as provided above


Improve this answer


edited May 31 '15 at 4:15


answered May 31 '15 at 3:23


15.8k11 gold badges43 silver badges63 bronze badges

  • My local OS is Windows. I downloaded the pscp.exe from the putty website. I tried opening it up and nothing came up. Also, I tried the command you listed above and was given: pscp.exe comman not found. Also tried it without the .exe and resulted in the same error. – Vincent May 31 '15 at 3:57 
  • 2
  • Open a CMD prompt, and go to the pscp.exe directory where you put it. Then execute the command as provided above. – mainframer May 31 '15 at 4:01 
  • 1
  • using scp on a mac has to be provided ./ parameter to signify that the file has to be downloaded in the current folder on mac machine. – Sarang Manjrekar Jul 2 '18 at 11:11
  • 2
  • With Windows Subsystem for Linux (WSL, basically Ubuntu on Windows) you can now also open up Bash if your Local OS is Windows, and just use scp. Pro-tip: you can access your Windows file system from WSL. It's under /mnt/c. So you can do something like this: scp username@remoteHost:/remote/dir/file.txt /mnt/c – gijswijs Apr 25 '19 at 3:42 
  • 3
  • As of the 2018 Autumn update, Windows 10 now comes with OpenSSH and is on PATH. This means you can use the scp command on Windows 10, too. – jaunt Sep 23 '19 at 20:45

Show 1 more comment

블로그 이미지



댓글을 달아 주세요

Many businesses use proxy servers to route and secure traffic between networks. There’s often confusion, however, on how this differs from a reverse proxy. In this post, we’ll dissect the two concepts and explain how administrators can use a reverse proxy for easy access management control.

What is a proxy server?

A proxy server, sometimes referred to as a forward proxy, is a server that routes traffic between client(s) and another system, usually external to the network. By doing so, it can regulate traffic according to preset policies, convert and mask client IP addresses, enforce security protocols, and block unknown traffic.

Systems with shared networks, such as business organizations or data centers, often use proxy servers. Proxy servers expose a single interface with which clients interact without having to enforce all of the policies and route management logic within the clients themselves.

What is a reverse proxy?

A reverse proxy is a type of proxy server.  Unlike a traditional proxy server, which is used to protect clients, a reverse proxy is used to protect servers. A reverse proxy is a server that accepts a request from a client, forwards the request to another one of many other servers, and returns the results from the server that actually processed the request to the client as if the proxy server had processed the request itself. The client only communicates directly with the reverse proxy server and it does not know that some other server actually processed its request.

A traditional forward proxy server allows multiple clients to route traffic to an external network. For instance, a business may have a proxy that routes and filters employee traffic to the public Internet. A reverse proxy, on the other hand, routes traffic on behalf of multiple servers. 

A reverse proxy effectively serves as a gateway between clients, users, and application servers. It handles all the access policy management and traffic routing, and it protects the identity of the server that actually processes the request.

Reverse proxy configuration

By routing client traffic through a reverse proxy, admins can simplify security administration. They can configure backend servers to only accept traffic directly from the proxy and then configure the granular access control configurations on the proxy itself.

For example, admins can configure the reverse proxy’s firewall to whitelist or blacklist specific IP addresses. All existing servers behind the proxy will be protected accordingly, and whenever admins add a new backend server to the network that is configured to only accept requests from the proxy server, the new backend server is protected according to the proxy configuration.

Using a reverse proxy can also allow administrators to easily swap backend servers in and out without disrupting traffic. Because clients interact directly with the proxy, they only need to know its host name and don't need to worry about changes to the backend network topology. In addition to simplifying client configuration, an admin can configure a reverse proxy to load-balance traffic so that requests can be more evenly distributed to the backend servers and improve overall performance.

Use case: onboarding and off-boarding

When onboarding a new user to a network, administrators must configure access control and firewalls to ensure the user can access the appropriate resources. Traditionally, an admin has to configure each server for which users need access. In a large organization with many servers, this can be a time-consuming and error-prone process.

However, with a reverse proxy, administrators can configure the access rights directly on the proxy server and have the user route all traffic through it. As such, the backend servers only need to trust and communicate with the proxy directly. This greatly simplifies the configuration process and helps ensure access is granted and revoked correctly by doing so through a single source.

Setting up a reverse proxy for access management

While a reverse proxy can greatly simplify the process of managing access to a network, setting it up and configuring it properly can get complicated. It requires provisioning the host with appropriate specifications, configuring the operating system and firewall, deciding on which proxy software to use (such as NGINX or HAProxy), enumerating and configuring the downstream servers in the proxy configuration files, setting up audit logging, and configuring the firewalls in all the downstream servers.

An administrator will need to optimize the proxy software to adjust for performance and availability requirements. For example, when a downstream server fails, the admin should configure the proxy server to quickly reroute traffic to avoid downtime.

At scale, the out-of-the-box configurations are rarely sufficient, so testing becomes important. Whenever the configurations change, you’ll need a way to run sufficient load against a representative test environment and closely monitor the impact on both performance and availability to verify that configurations will meet the needs of the production environment.

Building a reverse proxy by hand vs. buying software

Given all the steps involved in implementing, testing, and optimizing a reverse proxy, you may choose to buy software that can provide this functionality without all the custom work. Access management software can provide all of this functionality while also managing the ongoing maintenance and user management.

In addition to providing standard reverse proxy capabilities, access management software affords a number of unique benefits:

1) Flexibility with user access. By abstracting away the complexity of firewalls and access control, access management software can provide higher-level concepts like user groups. This functionality makes it easy for admins to assign and remove users from various predefined groups and allows the software to automatically implement the access policies.

2) Designed to boost reliability. In distributed systems, servers can fail and network interruptions may occur. Access management software easily detects failed servers and reroutes traffic to working ones to avoid any noticeable downtime for users.

3) Load balancing capabilities. Single servers may struggle when hit with a large amount of traffic, which degrades performance and increases request latency. Access management software can help to manage traffic and balance the load across all servers, making sure it’s evenly distributed.

Managing access with strongDM

The strongDM control plane is a proxy-based solution that simplifies authentication and authorization for admins. It routes all database and server connections through its protocol-aware proxy over a TLS 1.2 secure TCP connection, and it handles load balancing and automatic failover to provide high availability. The proxy validates user sessions and permissions and then intelligently routes the session to the target database or server through the most efficient path, logging all traffic along the way.

strongDM extends the single sign-on capabilities of your identity provider, allowing you to authenticate users to any server or database. From the Admin UI, you can view connected resources and manage role-based access control for your users. See for yourself with a free, 14-day trial.

블로그 이미지



댓글을 달아 주세요

홈페이지 제작 또는 관리를 할 때 파일질라 같은 ftp 프로그램을 이용하여 코드를 수정한 후 업로드를 합니다. ftp에서 파일을 다운받아 코드 편집기로 수정 후 다시 ftp로 올려야 하는 작업이 여간 번거롭습니다. 비쥬얼 스튜디오 코드에서 확장 프로그램을 이용해 ftp로 연결하여 바로 코드 편집할 수 있도록 환경을 셋팅해 보도록 하겠습니다.


먼저 파일질라 ftp 프로그램 설치 및 사용방법은 아래 링크로 걸어두었습니다.




VS Code 프로그램을 실행하여 좌측 하단 아이콘을 누른 후 ftp-simple을 검색하여 설치를 합니다.



F1키를 누른 후 ftp로 검색을 하여 ftp-simple : Config - FTP connection setting를 클릭합니다.



ftp 정보들을 입력하여 줍니다.



F1키를 눌러 이번에는 ftp-simple : Remote directory open to workspace를 클릭하여 줍니다.



등록했던 서버를 클릭합니다.



그누보드 WWW로 들어갑니다.



예시는 그누보드 디렉토리 구조인데, 자신의 티렉토리에 맞게 접속하시면 됩니다.



접속을 하면 위와 같은 안내문구가 우측 하단에 표시됩니다.



이때 폴더를 클릭하면 하위 폴더들이 아직 준비가 되지 않아 이미지처럼 표시가 되고, 클릭해도 열리지 않습니다.



기다리면 다운로드에 성공했다는 메시지가 생깁니다.



메시지를 확인 후 다시 폴더를 열어보면 정상적으로 로딩이 완료된 것을 확인할 수 있습니다.



소스를 수정 후 저장을 하면 덮어쓰기 할지 물어봅니다. OK를 누르면 FTP에 업로드가 됩니다.



저장을 할 때마다 업로드할 건지 물어보므로 confirm 설정을 false로 바꿔주면 물어보지 않고 업로드됩니다.

블로그 이미지



댓글을 달아 주세요

TCP 프록시 부하 분산은 인터넷에서 들어오는 TCP 트래픽을 Google Cloud VPC 네트워크의 가상 머신(VM) 인스턴스로 배포하는 역방향 프록시 부하 분산기입니다. TCP 프록시 부하 분산을 사용하면 TCP 연결을 통해 들어오는 트래픽이 부하 분산 레이어에서 종료된 후 TCP 또는 SSL을 통해 사용 가능한 가장 가까운 백엔드로 전달됩니다.

TCP 프록시 부하 분산을 사용하면 전 세계 모든 사용자의 단일 IP 주소를 사용할 수 있습니다. TCP 프록시 부하 분산기는 자동으로 트래픽을 사용자와 가장 가까운 백엔드로 라우팅합니다.

프리미엄 등급에서 TCP 프록시 부하 분산을 전역 부하 분산 서비스로 구성할 수 있습니다. 표준 등급을 사용하면 TCP 프록시 부하 분산기가 리전별 부하 분산을 처리합니다. 자세한 내용은 네트워크 서비스 등급의 부하 분산기 동작을 참조하세요.

이 예시에서 서울 및 보스턴에 있는 사용자의 트래픽 연결은 부하 분산 레이어에서 종료됩니다. 이러한 연결은 1a  2a로 표시되어 있습니다. 부하 분산기에서 선택한 백엔드 인스턴스로 별도의 연결이 설정됩니다. 이러한 연결은 1b  2b로 표시되어 있습니다.

TCP 종료를 사용하는 Cloud Load Balancing(확대하려면 클릭)

TCP 프록시 부하 분산은 SMTP(Simple Mail Transfer Protocol)의 포트 25와 같이 잘 알려진 특정 포트의 TCP 트래픽용입니다. 자세한 내용은 포트 사양을 참조하세요. 동일한 포트에서 암호화되는 클라이언트 트래픽의 경우 SSL 프록시 부하 분산을 사용합니다.

Google Cloud 부하 분산기의 차이점에 대한 자세한 내용은 다음 문서를 참조하세요.


다음은 TCP 프록시 부하 분산기의 몇 가지 이점입니다.

  • IPv6 종료. TCP 프록시 부하 분산은 클라이언트 트래픽의 IPv4 주소 및 IPv6 주소를 모두 지원합니다. 클라이언트 IPv6 요청은 부하 분산 레이어에서 종료된 후 IPv4를 통해 백엔드로 프록시 처리됩니다.
  • 지능형 라우팅. 부하 분산기는 용량이 있는 백엔드 위치로 요청을 라우팅할 수 있습니다. 반대로 L3/L4 부하 분산기는 용량에 관계없이 리전 백엔드로 라우팅해야 합니다. 더 스마트한 라우팅을 사용하면 x*N이 아니라 N+1 또는 N+2에서 프로비저닝할 수 있습니다.
  • 보안 패치 적용. TCP 스택에 취약점이 발생하면 Cloud Load Balancing은 백엔드가 안전하게 유지되도록 자동으로 부하 분산기에 패치를 적용합니다.
  • 가장 많이 사용되는 TCP 포트 지원: 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, 3389, 5222, 5432, 5671, 5672, 5900, 5901, 6379, 8085, 8099, 9092, 9200, 9300.

참고: TCP 프록시 부하 분산은 TCP 포트 80 또는 8080을 지원하지 않습니다. HTTP 트래픽의 경우 외부 HTTP(S) 부하 분산을 사용합니다.

네트워크 서비스 등급의 부하 분산기 동작

TCP 프록시 부하 분산을 프리미엄 등급의 전역 부하 분산 서비스와 표준 등급의 리전 서비스로 구성할 수 있습니다.

프리미엄 등급

백엔드 서비스 하나만 가질 수 있으며 백엔드 서비스는 여러 리전에서 백엔드를 가질 수 있습니다. 전역 부하 분산의 경우 백엔드를 여러 리전에 배포하면 부하 분산기에서 자동으로 트래픽을 사용자와 가장 가까운 리전에 전달합니다. 트래픽 집중 리전의 경우 부하 분산기가 자동으로 새 연결을 사용 가능한 용량이 있는 다른 리전에 전달합니다. 기존 사용자 연결은 현재 리전에 계속 유지됩니다.

트래픽은 다음과 같이 백엔드에 할당됩니다.

  1. 클라이언트가 요청을 전송하면 부하 분산 서비스는 소스 IP 주소에서 요청의 대략적인 출처를 확인합니다.
  2. 부하 분산 서비스는 백엔드 서비스가 소유한 백엔드의 위치, 백엔드의 전체 용량, 현재 총 사용량을 확인합니다.
  3. 사용자에게 가장 가까운 백엔드 인스턴스에 이용 가능한 용량이 있으면 요청은 가장 가까운 백엔드 집합으로 전달됩니다.
  4. 한 리전에 수신되는 요청은 해당 리전의 이용 가능한 모든 백엔드 인스턴스에 균등하게 분산됩니다. 하지만 부하가 아주 적은 경우에는 분산이 균등하지 않게 나타날 수 있습니다.
  5. 지정한 리전에 이용 가능한 용량이 있는 정상 백엔드 인스턴스가 없는 경우 부하 분산기는 이용 가능한 용량이 있는 가장 가까운 다음 리전으로 요청을 전송합니다.

표준 등급

표준 등급에서 TCP 프록시 부하 분산은 리전 서비스입니다. 백엔드는 모두 부하 분산기의 외부 IP 주소 및 전달 규칙에서 사용하는 리전에 있어야 합니다.


TCP 프록시 부하 분산기의 구성요소는 다음과 같습니다.

전달 규칙 및 IP 주소

전달 규칙은 IP 주소, 포트, 프로토콜별로 트래픽을 대상 프록시와 백엔드 서비스로 구성된 부하 분산 구성으로 라우팅합니다.

각 전달 규칙은 애플리케이션의 DNS 레코드에 사용할 수 있는 단일 IP 주소를 제공합니다. DNS 기반 부하 분산은 필요 없습니다. 사용할 수 있는 고정 IP 주소를 예약하거나 Cloud Load Balancing에서 IP 주소를 하나 할당하도록 할 수 있습니다. 고정 IP 주소를 예약하는 것이 좋습니다. 그렇지 않으면 전달 규칙을 삭제하고 새 규칙을 만들 때마다 DNS 레코드를 새로 할당된 임시 IP 주소로 업데이트해야 합니다.

TCP 프록시 부하 분산기의 정의에 사용되는 외부 전달 규칙은 전달 규칙 포트 사양에 나와 있는 포트 중 하나를 정확하게 참조할 수 있습니다.

대상 프록시

TCP 프록시 부하 분산은 클라이언트에서 TCP 연결을 종료하고 백엔드에 새 연결을 만듭니다. 기본적으로 원래 클라이언트 IP 주소와 포트 정보는 유지되지 않습니다. 이 정보를 유지하려면 PROXY 프로토콜을 사용하면 됩니다. 대상 프록시는 들어오는 요청을 직접 백엔드 서비스로 라우팅합니다.

백엔드 서비스

백엔드 서비스는 들어오는 트래픽을 연결된 백엔드 1개 이상에 전달합니다. 각 백엔드는 인스턴스 그룹 또는 네트워크 엔드포인트 그룹과 백엔드의 제공 용량에 대한 정보로 구성됩니다. 백엔드 제공 용량은 CPU 또는 초당 요청 수(RPS)를 기반으로 합니다.

TCP 프록시 부하 분산기마다 하나의 백엔드 서비스 리소스가 있습니다. 백엔드 서비스 변경사항은 즉시 적용되지 않습니다. 변경사항이 Google 프런트엔드(GFE)에 적용되는 데 몇 분 정도 걸릴 수 있습니다.

각 백엔드 서비스는 사용 가능한 백엔드에 수행할 상태 확인을 지정합니다.

사용자에 대한 중단이 최소화되도록 백엔드 서비스에서 연결 드레이닝을 사용 설정할 수 있습니다. 이러한 중단은 백엔드가 종료되거나 수동으로 삭제되거나 자동 확장 처리 과정에서 삭제될 때 발생할 수 있습니다. 연결 드레이닝을 사용하여 서비스 중단을 최소화하기에 대해 자세히 알아보려면 연결 드레이닝 사용 설정을 참조하세요.

백엔드와의 통신에 사용되는 프로토콜

TCP 프록시 부하 분산기에 백엔드 서비스를 구성할 때 백엔드 서비스가 백엔드와 통신하는 데 사용할 프로토콜을 설정합니다. SSL 또는 TCP를 선택할 수 있습니다. 부하 분산기는 사용자가 지정한 프로토콜만 사용하고 다른 프로토콜과의 연결 협상을 시도하지 않습니다.

방화벽 규칙

백엔드 인스턴스는 부하 분산기 GFE/상태 확인 범위에서의 연결을 허용해야 합니다. 즉,의 트래픽이 백엔드 인스턴스 또는 엔드포인트에 도달하도록 허용하는 방화벽 규칙을 만들어야합니다. 이러한 IP 주소 범위는 상태 확인 패킷과 백엔드로 전송되는 모든 부하 분산 패킷의 소스로 사용됩니다.

이 방화벽 규칙에 대해 구성하는 포트는 백엔드 인스턴스 또는 엔드포인트에 대한 트래픽을 허용해야 합니다.

  • 각 전달 규칙에서 사용하는 포트를 허용해야 합니다.
  • 각 백엔드 서비스에 구성된 각 상태 확인에 사용하는 포트를 허용해야 합니다.

방화벽 규칙은 Google 프런트엔드(GFE) 프록시가 아닌 VM 인스턴스 수준에서 구현됩니다. Google Cloud 방화벽 규칙을 사용하여 트래픽이 부하 분산기에 도달하는 것을 막을 수 없습니다.

상태 확인 프로브와의 트래픽을 허용해야 하는 이유에 대한 자세한 내용은 프로브 IP 범위 및 방화벽 규칙을 참조하세요.

소스 IP 주소

각 백엔드 가상 머신(VM) 인스턴스 또는 컨테이너에서 확인되는 패킷의 소스 IP 주소는 다음 범위의 IP 주소입니다.


실제 부하 분산 트래픽의 소스 IP 주소는 상태 확인 프로브 IP 범위와 같습니다.

백엔드에서 확인되는 트래픽의 소스 IP 주소는 부하 분산기의 Google Cloud 외부 IP 주소가 아닙니다. 다시 말해 HTTP, SSL 또는 TCP 세션이 두 개 있습니다.

  • 원래 클라이언트에서 부하 분산기(GFE)로 이동하는 세션 1:
    • 원본 IP 주소: 원래 클라이언트 또는 클라이언트가 NAT 뒤에 있는 경우 외부 IP 주소입니다.
    • 대상 IP 주소: 부하 분산기의 IP 주소입니다.
  • 부하 분산기(GFE)에서 백엔드 VM 또는 컨테이너로 이동하는 세션 2:
    • 소스 IP 주소: IP 주소는 또는 범위 중 하나입니다.
    • 실제 소스 주소는 예측할 수 없습니다.
    • 대상 IP 주소: Virtual Private Cloud(VPC) 네트워크의 백엔드 VM 또는 컨테이너의 내부 IP 주소입니다.

중요: 또는에 있는 IP 주소 중 어떤 IP 주소를 차단해도 상태 확인은 계속 진행될 수 있습니다. 여러 프로버가 동시에 사용됩니다. 다수가 통과하면 몇몇 실패한 프로버가 무시될 수 있습니다. 그러나 실제 부하 분산 트래픽을 차단할 수 있습니다.

열린 포트

TCP 프록시 부하 분산기는 역방향 프록시 부하 분산기입니다. 부하 분산기는 수신 연결을 종료한 후 부하 분산기에서 백엔드로 새 연결을 엽니다. 역방향 프록시 기능은 Google 프런트엔드(GFE)에서 제공합니다.

GFE에는 다른 Google Cloud 부하 분산기와 다른 Google 서비스를 지원하는 열린 포트가 여러 개 있습니다. 부하 분산기의 외부 IP 주소에 대해 보안 또는 포트 검사를 실행하면 추가 포트가 열려 있는 것처럼 보입니다.

이는 TCP 프록시 부하 분산기에 영향을 주지 않습니다. TCP 프록시 부하 분산기에서 사용하는 외부 전달 규칙마다 전달 규칙 포트 사양에 나와 있는 포트 중 하나를 정확하게 참조할 수 있습니다. 다른 TCP 대상 포트를 사용하는 트래픽은 부하 분산기의 백엔드로 전달되지 않습니다. 승인되지 않은 포트에 대한 TCP 세션을 열어서 추가 포트에 대한 트래픽이 처리되지 않는지 확인할 수 있습니다. 요청을 처리하는 GFE가 TCP 재설정(RST) 패킷으로 연결을 닫습니다.

트래픽 분산

TCP 프록시 부하 분산기가 트래픽을 백엔드로 배포하는 방식은 분산 모드와 백엔드를 선택하기 위해 선택한 해싱 메서드(세션 어피니티)에 따라 다릅니다.

분산 모드

백엔드 서비스에 백엔드를 추가할 때 부하 분산 모드를 설정합니다.

TCP 프록시 부하 분산의 경우 분산 모드는 CONNECTION 또는 UTILIZATION일 수 있습니다.

부하 분산 모드가 CONNECTION이면 백엔드에서 처리할 수 있는 동시 연결 수에 따라 부하가 분산됩니다. 매개변수 maxConnections(리전 관리형 인스턴스 그룹 제외), maxConnectionsPerInstance, maxConnectionsPerEndpoint 중 하나를 정확하게 지정해야 합니다.

부하 분산 모드가 UTILIZATION이면 인스턴스 그룹의 인스턴스 사용률에 따라 부하가 분산됩니다.

부하 분산기 유형과 지원되는 부하 분산 모드 비교에 대한 자세한 내용은 부하 분산 방법을 참조하세요.

세션 어피니티

세션 어피니티는 백엔드가 정상이고 용량이 있는 한 동일한 클라이언트의 모든 요청을 동일한 백엔드로 전송합니다.

TCP 프록시 부하 분산은 동일한 클라이언트 IP 주소의 모든 요청을 동일한 백엔드에 전달하는 클라이언트 IP 어피니티를 제공합니다.

장애 조치

백엔드가 비정상이 되면 트래픽은 자동으로 동일한 리전에 있는 정상 백엔드로 리디렉션됩니다. 한 리전 내 모든 백엔드가 비정상이면 트래픽이 다른 리전의 정상 백엔드로 분산됩니다(프리미엄 등급만 해당). 모든 백엔드가 비정상이면 부하 분산기가 트래픽을 삭제합니다.

다음 단계





TCP 프록시 부하 분산 개요  |  Google Cloud

TCP 프록시 부하 분산은 인터넷에서 들어오는 TCP 트래픽을 Google Cloud VPC 네트워크의 가상 머신(VM) 인스턴스로 배포하는 역방향 프록시 부하 분산기입니다. TCP 프록시 부하 분산을 사용하면 TCP 연



블로그 이미지



댓글을 달아 주세요


Nginx 에서 HTTP 프로토콜에 대하여 HTTPS로 redirect 설정하는 것과 다른 포트로 포트포워딩(Port Forwarding) 하는 설정 내용을 정리합니다.

테스트 환경



Nginx를 설치 및 HTTPS 설정된 환경에서 진행을 하고 위 링크의 포스트가 선행되어야 하겠습니다.

Nginx HTTP redirect to HTTPS

HTTP redirect는 HTTP(비암호화 프로토콜)로 접속했을 때 자동적으로 HTTPS 프로토콜로 서비스되도록 리다이렉트 처리를 하는 것입니다.

일반적으로 사이트 접속 시 jackerlab.com 이렇게 도메인을 치고 사이트 접속을 하면 https://jackerlab.com과 같은 형태의 HTTP 프로토콜로 접속이 됩니다.

사이트를 항상 HTTPS로 서비스하기 위하여 HTTPS로 리다이렉트 처리하여 HTTPS로 접속을 전환/유도하는 것입니다.

Redirect 설정은 /etc/nginx/nginx.conf 파일에서 설정하고 Nginx 서비스를 구동하면 되고 HTTPS(443) 설정이 사전에 되어 있어야 합니다.

[root@jackerlab ~]# vim /etc/nginx/nginx.conf ... (앞부분 생략) server { listen 80 default_server; listen [::]:80 default_server; #server_name _; server_name apps.jackerlab.com; root /usr/share/nginx/html; charset utf-8; # Load configuration files for the default server block. include /etc/nginx/default.d/*.conf; location / { } error_page 404 /404.html; location = /40x.html { } error_page 500 502 503 504 /50x.html; location = /50x.html { } return 301 https://$host$request_uri; # HTTP to HTTPS redirect } ... (뒷부분 생략 - 뒷부분의 HTTPS 설정이 되어 있어야 함) [root@jackerlab ~]#

위 설정은 마지막 부분에 1줄 추가가 된 상태고 301 HTTP 응답 코드에 의하여 https://도메인으로 redirect 처리 해주는 설정입니다.

Nginx 포트 포워딩 설정

웹 어플리케이션을 작성했을 때 HTTPS 통신을 하기 위하여 포트 포워딩을 사용할 수 있겠습니다.

예를 들어 React, Django 등의 웹서버가 별도로 구동되어 있을 경우, HTTPS인 443 포트에 React(3000), Django(8000) 매핑을 하여 HTTPS 프로토콜로 웹 서비스를 제공할 수 있겠습니다.

이번 테스트에서는 React(3000) 가 구동되었다고 가정하고 포트포워딩 설정을 해보겠습니다.

Redirect 설정과 연계되어 있고 최종적으로는 아래와 같은 구조가 되겠습니다.

최종적으로 사이트를 접속하면 HTTPS 암호화 통신 환경에서 React(3000) 어플리케이션에 접속이 되는 것입니다.

/etc/nginx/nginx.conf 파일에서 설정하고 Nginx 서비스를 구동하면 되고 HTTPS(443) 설정 및 React(3000) 서비스 구동이 사전에 되어 있어야 합니다.

[root@jackerlab nginx]# cat nginx.conf ... (앞부분 생략 - HTTP(80) 설정 부분) # Settings for a TLS enabled server. server { listen 443 ssl http2 default_server; listen [::]:443 ssl http2 default_server; server_name localhost; # server_name apps.jackerlab.com; root /usr/share/nginx/html; ssl_certificate /etc/letsencrypt/live/apps.jackerlab.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/apps.jackerlab.com/privkey.pem; ssl_session_cache shared:SSL:1m; ssl_session_timeout 10m; ssl_ciphers PROFILE=SYSTEM; ssl_prefer_server_ciphers on; # Load configuration files for the default server block. include /etc/nginx/default.d/*.conf; location / { proxy_pass http://localhost:3000; # 포트 포워딩 설정 } error_page 404 /404.html; location = /40x.html { } error_page 500 502 503 504 /50x.html; location = /50x.html { } } } ... (뒷부분 생략) [root@jackerlab nginx]#

위 설정은 중간 location 부분에 1줄 추가가 된 상태고 HTTPS(443) 접속 시, 프록시 기능으로 3000 포트로 포워딩을 하겠다는 설정입니다.

최종적으로 설정 된 결과는 아래와 같고 HTTPS(443) 과 인증서 적용(자물쇠)이 정상적으로 된 후, React(3000) 웹 서비스로 정상 접속된 것을 확인할 수 있습니다.







[Nginx] Nginx HTTP redirect 및 포트포워딩(Port Forwarding) 설정⋆ JackerLab

Nginx 에서 HTTP 프로토콜에 대하여 HTTPS로 redirect 설정하는 것과 다른 포트로 포트포워딩(Port Forwarding) 하는 설정 내용을 정리합니다.






블로그 이미지



댓글을 달아 주세요

Ever wondered how more than one application is deployed to the same machine, and how traffic is routed to the corresponding applications? Keep reading to find out.



By the end of the article, you’ll understand

  • What a Reverse Proxy is?
  • What NGINX is?
  • How does NGINX help in managing multiple applications?
  • How to leverage NGINX as a Reverse Proxy?

Reverse Proxy

According to Wikipedia, a reverse proxy is a type of proxy server that retrieves resources on behalf of a client from one or more servers. These resources are then returned to the client, appearing as if they originated from the server itself.

Refer to this article to better understand what Reverse Proxies are.


We will be using NGINX as a Reverse Proxy. According to Wikipedia,
NGINX is a web server that can be used as a reverse proxy, load balancer, mail proxy, and HTTP cache. The software was created by Igor Sysoev and was publicly released in 2004. Nginx is a free and open-source software, released under the terms of the 2-clause BSD license. A large fraction of web servers use NGINX, often as a load balancer.

Some other examples Reverse Proxies available are:

Reverse Proxy Example

This is an example of an architecture, where two apps are running in the background, but the clients have no idea about them. The clients only know about NGINX which acts as a reverse proxy that sends the request to the appropriate application.

Now that you have a broader idea of what we are about to build, let’s jump right in!


  • Deploy two applications and have them managed by NGINX.

Setup & Pre-Requisites:

  • For this example, we have two sample Express Applications. One can have any kind of application running on different ports.

NOTE: Do not run your application on Port 80 or 443. We will explaining later why this must not be done.
Refer the official ExpressJS documentation for help getting started.

  • We have installed NGINX on our local machine, but the same could be done on any Virtual Machine where the applications are expected to be deployed.

Here is the documentation on how to install NGINX on your machine.

Step 1: Start two apps running in different ports

As we’ve mentioned earlier, we’ve got two Node.js Apps running on two different ports as shown below.

Server app running on Port 3000

Client app running on Port 3001

Now that we have our apps up and running, we don’t want our users to use these applications by typing their PORTS explicitly, so we need to map it with something that is more human-readable.

In this example, we will be using subdomains to distinguish between them. Again one is free to use whichever element is suitable as per requirements.

Another example could be a particular route like domain/client and domain/server. The only condition for the distinguishing element is to follow a valid URL regular expression. To learn about Regex you can click here.

Step 2: Add DNS records

This is the part where one would add the DNS records in their DNS management dashboard. If you are running Nginx locally, you can skip this step.

The general DNS Configurations would be something like:

  • Server app mapped to the server.domain
  • Client app mapped to the client.domain

My Localhost Config, in this case, would be:

  • Server mapped to server.localhost
  • Client mapped to client.localhost

There are two standard protocols HTTP and HTTPS. The default port for HTTP is 80 and HTTPS is 443. The reason we must not run our applications on these ports is because our NGINX server is running on these two ports. All the requests the client makes would either be redirected to port 80 or 443 from where it would be redirected internally to the corresponding application.

Step 3 - Configure NGINX at 80 for HTTP and 443 for HTTPS

Now that we have our apps running and our DNS records ready. We can start configuring our NGINX Reverse Proxy to make it all work.

By default, the configuration file is named nginx.conf and placed in the directory /usr/local/nginx/conf, /etc/nginx, or /usr/local/etc/nginx for Linux and Debian Based systems.

On Windows, the file is placed inside the installation folder, nginx/conf/nginx.conf.

Add these configurations inside the HTTP block.

Step 3.1 - HTTP

server { listen 80; server_name server.domain; location / { proxy_pass "http://localhost:3000" ; } } server { listen 80; server_name client.domain; location / { proxy_pass "http://localhost:3001" ; } }

Step 3.2 - HTTPS

server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name server.domain; location / { proxy_pass "http://localhost:3000/"; } ssl_certificate <location of SSL certificate>; ssl_certificate_key <location of SSL certificate Key>; } server { listen 443 ssl http2; listen [::]:443 ssl http2; server_name client.domain; location / { proxy_pass "http://localhost:3001/"; } ssl_certificate <location of SSL certificate>; ssl_certificate_key <location of SSL certificate Key>; }

NOTE: These are the minimum configurations required to successfully implement NGINX for reverse proxying. Feel free to explore other config parameters as well.

Make sure to change the domain name to your domain. For a SSL Certificate and Key, you can obtain them from your SSL provider.

If you don’t have one, use this free service LetsEncrypt.

Follow their documentation to get free SSL instantly!

Step 4 - Save and Restart

After editing, save your changes. Use the sudo nginx -t command to test your changes before actually reloading NGINX. It is good practice do this to make sure your server won’t crash, if there were any errors in your config file.

Once you get a message that the test is successful, you can go ahead and restart NGINX.

Use this command sudo nginx -s reload to restart NGINX.

Open the browser and enter the URLs to find your applications running on the corresponding URLs configured.

For the example above, the URLs are:

  • client.localhost
  • server.localhost

Important Note

Using NGINX secures your server because it routes the traffic internally. Instead of having to open up all of your ports, in this case 3000 and 3001, to the internet, just 80 and 443 will do the trick.

This is because all traffic passes through the secure NGINX server (like a gateway) and is redirected to the correct application. Using a reverse proxy like NGINX is more secure that opening up several ports for every application you deploy because of the increased risk a hacker will use an open port for malicious activity.


Here is the end result:

Congratulations! You did it! 🎉

In large systems, the system is highly dependent on the micro-services architecture where each service would be served by an application. In that case, managing multiple apps would be an essential skill to know.

The microservices architecture is discussed here in detail.

Hope this article helped you to manage those independently deployed applications as a whole with the help of NGINX as a reverse proxy.

Thanks for reading!


Peer Review Contributions by: Louise Findlay

About the author

Harish Ramesh Babu

Harish Ramesh Babu is a final year CS Undergrad at the National Institute of Technology, Rourkela, India. He gets really excited about new tech and the cool things you can build with it. Mostly you’ll find him working on web apps either for the campus or an opensource project with the





블로그 이미지



댓글을 달아 주세요

기본적으로 웹서버 구조는

와 같습니다.

nginx 와 php 를 사용하는 경우

와 같이 됩니다.

FastCGI는 웹 서버와 프로그램이 상호작용(데이터를 주고 받기 위한) 인터페이스 개발을 위한 프로토콜입니다.

FastCGI는 CGI(Common Gateway Interface)를 개선한 인터페이스입니다.

PHP 는 FastCgi 구현채인 php-fpm 을 사용해서 nginx 와 통신합니다.

php-fpm 설정 ( 기본경로 : /etc/php-fpm.d/www.conf )

listen =

9000 번 포트로 tcp/ip socket 통신을 하는걸 알 수 있습니다.

nginx 설정 에서 php-fpm 과 통신할 수 있도록 설정 해봅시다.

nginx 설정 ( 기본경로 : /etc/nginx/nginx.conf )

server { location ~ \.(php)$ { fastcgi_pass; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; fastcgi_param QUERY_STRING $query_string; } location ~ \.(gif|jpg|png)$ { root /data/images; } }

만일 nginx 와 php-fpm 이 물리적으로 동일한 서버에 있다면 unix socket 을 사용해서 속도를 향상 시킬 수 있습니다.

(주의 : unix socket 은 프로세스간 통신 이기 때문에 물리적으로 다른 서버에 있다면 사용 할 수 없습니다.)

다음과 같이 설정을 바꿉니다.

php-fpm 설정

listen = /var/run/php7-fpm.sock

nginx 설정

fastcgi_pass unix:/var/run/php7-fpm.sock;

설정 후

설정한 경로에 파일이 생김을 알 수 있습니다. (리눅스는 소켓을 파일 취급 합니다.)

nginx 와 php-fpm 소켓통신의 경우 접근이 잦기 때문에 /dev/shm 경로 아래에 넣어주면 약간의 속도 향상 효과를 얻을 수 있습니다.

/dev/shm 은 실제로 메모리를 점유하는건 아니지만 사용하는 만큼 램을 사용하는데


php-fpm 설정

listen = /dev/shm/php7-fpm.sock

nginx 설정

fastcgi_pass unix:/dev/shm/php7-fpm.sock;

으로 수정하면 됩니다.

아주 간단하게 벤치마킹을 해봅시다.

server 코드

<?php echo "test"; echo PHP_EOL;

client 코드

<?php $message = 'test'; $header = array(); $url = "서버 주소"; $start = microtime(true); for($i=0; $i<100; $i++) { $curlSession = curl_init(); curl_setopt($curlSession, CURLOPT_URL, $url); curl_setopt($curlSession, CURLOPT_HTTPHEADER, $header); curl_setopt($curlSession, CURLOPT_POST, TRUE); curl_setopt($curlSession, CURLOPT_POSTFIELDS, $message); curl_setopt($curlSession, CURLOPT_RETURNTRANSFER, TRUE); $curlResult = curl_exec($curlSession); curl_close($curlSession); } $end = microtime(true); print_r($end - $start);

5회 돌려본 결과


tcp/ip socket 2.2519 2.5132 2.3198 2.4347 2.4336
unix socket 2.4471 2.3182 2.1452 2.1803 1.9307

참고 사이트



팀 동료가 tcp/ip socket 을 unix socket 으로 수정후 테스트 케이스 1000개 정도의 속도가 1분정도 감소 하는 효과가 있었다고 말 해줬습니다.


또다른 팀 동료는 tcp/ip socket 대신 unix socket 사용하는 이유는 tcp/ip socket 은 close 시에 프로세스가 time wait 가 걸려서 바로 반환 하지 않기 때문에 소켓 개수 제한에 금방 걸릴수 있어서 unix socket 으로 대체 한다고 말해 줬다.

관련 내용은 다시 찾아봐야 할 거 같습니다.

블로그 이미지



댓글을 달아 주세요