“상대방에 의한 연결 재설정” 오류를 효과적으로 해결하는 방법

“Connection reset by peer” 오류는 서버가 시스템이 통신을 완료하기 전에 예기치 않게 연결을 끊을 때 발생하는 성가신 네트워크 문제 중 하나입니다.일반적으로 방화벽, 보안 설정 또는 시간 초과로 인해 연결이 차단되지만, 서버 구성 오류나 네트워크 라우팅 문제와 같은 더 복잡한 원인일 수도 있습니다.기본적으로 서버가 더 이상 연결을 유지하려 하지 않는 상황이며, 원인을 파악하는 것은 다소 어려울 수 있습니다. SSH, FTP 또는 사용자 지정 애플리케이션을 설정하는 도중에 이 오류가 발생하여 모든 것이 중단되는 경우, 다음 사항들을 확인해 보세요.특히 서버 로그에 접근할 수 없는 경우 해결이 항상 간단하지는 않지만, 아래 단계를 따르면 원인을 파악하거나 문제를 해결할 수 있을 것입니다.

상대방에 의한 연결 재설정 오류 해결 방법

로그 및 오류 메시지를 확인하세요.

이건 마치 탐정처럼 로그를 살펴보고 단서를 찾는 단계입니다.예를 들어 SSH 연결 문제라면 인증 로그를 실시간으로 확인하여 백그라운드에서 무슨 일이 벌어지고 있는지 살펴볼 수 있습니다. Linux 서버에서 터미널을 열고 다음 명령어를 입력하세요.

tail -f /var/log/auth.log

이렇게 하면 연결을 시도할 때 실시간으로 로그 항목이 표시됩니다.다른 서비스와 관련된 문제라면 해당 서비스의 로그를 확인하세요.일반적으로 `/var/log/` 디렉터리에 있거나 systemd를 사용하는 경우 `journalctl` 명령어를 통해 확인할 수 있습니다.일부 설정에서는 서비스 또는 데몬에 대해 자세한 디버깅 모드를 활성화하면 더 많은 정보를 얻을 수 있습니다.예를 들어 SSH에서 자세한 정보 표시 모드를 활성화하는 것과 같습니다 ssh -vvv.

좀 이상하게 들릴 수도 있지만, 로그를 보면 서버가 IP 주소를 차단했는지, 사용량 제한에 걸렸는지, 내부 오류가 발생했는지 등을 알 수 있는 경우가 많습니다.경우에 따라서는 더 자세한 정보를 얻기 위해 추가 로깅을 활성화하거나 설정 파일에 디버그 플래그를 설정해야 할 수도 있습니다.

인터넷 연결 및 라우팅 테스트

다음으로, 서버 경로에 대한 연결이 실제로 작동하는지 확인하십시오.traceroute [domain/IP]Linux에서는 `git status`를, tracert [domain/IP]Windows에서는 `git status`를 사용하십시오.마치 패킷이 이동하는 경로를 지도처럼 그려보는 것입니다.만약 어느 단계에서 연결이 끊기거나 문제가 발생한다면, 그것이 문제의 원인일 수 있습니다.

때때로 서버 또는 연결 체인 앞부분의 게이트웨이가 다운되거나 과부하가 걸릴 수 있습니다.몇 단계 떨어진 곳에서 지속적으로 타임아웃이 발생하는 경우, 이는 사용자가 해결할 수 없는 문제일 가능성이 높습니다.개인 서버의 경우, 네트워크 서비스를 재시작하거나 서버 전체를 재시작하면 멈춘 상태를 해결할 수 있습니다.예를 들어, Linux에서는 `network.php` 또는 `network.php`와 같은 네트워크 관련 서비스를 재시작할 수 sudo systemctl restart networking있습니다 sudo systemctl restart NetworkManager.

내 IP 주소가 차단 또는 블랙리스트에 등록되었는지 확인하세요

좀 교묘한 방법이 있는데요, 여러분의 IP 주소가 차단되거나 블랙리스트에 올라 있을 수 있습니다.공용 서버는 의심스러운 IP 주소를 빠르게 차단하는데, 이 때문에 재설정 오류가 발생하는 것입니다.여러분의 IP 주소가 블랙리스트에 있는지 확인하려면 MX Toolbox Blacklist Check 같은 사이트를 이용해 보세요. IP 주소를 입력하고 (확실하지 않으면 “내 IP 주소는 무엇인가요?”를 검색하세요), 만약 블랙리스트에 올라 있다면 그 IP 주소가 문제의 원인일 가능성이 높습니다.

이 경우, 인터넷 서비스 제공업체(ISP)에 문의하거나 VPN을 사용하여 IP 주소를 변경하세요.블랙리스트 문제를 해결하는 유일한 방법은 서버 관리자를 통하는 것이며, 이 과정은 시간이 걸릴 수 있습니다.다만, IP 주소 변경이 항상 영구적인 해결책은 아니며, 특히 네트워크가 다시 블랙리스트에 오를 경우 더욱 그렇다는 점을 명심하세요.

방화벽 및 보안 필터를 점검하십시오.

여기서 문제가 발생하는 경우가 많습니다.로컬 또는 서버 측 방화벽은 트래픽이 의심스럽다고 판단될 경우 연결을 차단하거나 재설정할 수 있습니다.서버를 관리하는 경우 (Linux의 경우) iptables 규칙을 확인하세요.

sudo iptables -L --line-numbers

IP 주소나 연결 포트를 차단하는 규칙이 있는지 확인하십시오.마찬가지로 Fail2ban이나 DenyHosts와 같은 보안 앱을 실행 중인 경우 IP 주소가 차단 목록에 포함되어 있지 않은지 확인하십시오. Fail2ban의 경우 구성 파일에서 /etc/fail2ban/jail.conf해당 ignoreip줄을 확인하세요.

방화벽을 완전히 비활성화하는 것은 절대 금물입니다.문제를 자초하는 행위입니다.대신 IP 주소를 화이트리스트에 추가하거나 규칙을 신중하게 조정하세요.윈도우와 리눅스는 방화벽 규칙을 관리하는 방법이 다르고, 구문도 다를 수 있기 때문입니다.

리눅스에서는 iptables 외에도 다음과 같은 도구들이 ufw더욱 친숙한 인터페이스를 제공합니다.

sudo ufw allow from [your-ip] to any port [port]

Windows에서는 제어판이나 PowerShell 명령어를 통해 Windows Defender 방화벽 규칙을 확인하세요.

네트워크 서비스 및 데몬 재시작

서버 구성이 최근에 변경되었지만 서비스를 재부팅하지 않은 경우, 문제가 지속될 수 있습니다. SSH, FTP 또는 사용자 지정 서비스와 같은 데몬을 재시작하면 멈춘 상태를 해결할 수 있습니다.예를 들어, Debian 또는 Ubuntu 서버에서는 다음 명령을 실행하세요.

sudo systemctl restart ssh

마찬가지로 FTP나 Samba의 경우 에도 해당 서비스 이름 ssh으로 바꾸시면 됩니다 smbd.참고로, 일부 환경에서는 활성 세션을 중단하지 않도록 서버 관리자와 협의해야 할 수도 있습니다.

접근 제어를 위해 호스트 파일을 편집하세요

호스트 파일을 사용하여 특정 IP 주소의 접속을 허용하거나 차단할 수 있습니다. IP 주소 차단이 의심되는 경우 /etc/hosts.deny 및 /etc/hosts.allow 파일을 확인하십시오.예를 들어, IP 주소가 /etc/hosts.deny 파일에 있다면 /etc/hosts.deny해당 줄을 주석 처리하거나 삭제하십시오.

# your IP in hosts.deny

그런 다음 다음과 같이 추가하세요 /etc/hosts.allow.

sshd : 10.10.10.8

서버 차단이 지나치게 강력한 경우, 이 방법은 접근 권한을 다시 확보하는 확실한 방법이 될 수 있습니다.

TCP 타임아웃 기간을 늘리고 유지 패킷을 전송하세요.

이는 최후의 수단이지만, 유휴 시간 동안 연결이 끊어지는 경우 keepalive 설정을 조정하면 도움이 될 수 있습니다. Linux에서는 /etc/sysctl.conf다음 줄을 편집하고 추가하거나 수정할 수 있습니다.

net.ipv4.tcp_keepalive_time = 300 net.ipv4.tcp_keepalive_probes = 9 net.ipv4.tcp_keepalive_intvl = 10

그런 다음 를 사용하여 다시 로드합니다 sysctl --load=/etc/sysctl.conf.이렇게 하면 시스템이 정기적인 하트비트 패킷을 전송하여 서버가 연결을 유지하고 안정성을 높일 수 있습니다. Windows의 경우 레지스트리를 통해 유사한 설정을 조정할 수 있습니다.로 이동하여 및 를 HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Tcpip\Parameters조정하십시오.KeepAliveTimeKeepAliveInterval

서버의 SSH 구성 검토

SSH 연결에 문제가 발생하면 설정 /etc/ssh/sshd_config파일을 확인하세요.MaxStartups 및 ClientAliveInterval 과 같은 설정 이 너무 제한적으로 설정되어 있으면 연결 끊김이 발생할 수 있습니다.예를 들어, 이 값을 높이면 MaxStartups인증되지 않은 동시 연결 수가 늘어나고, ClientAliveInterval적절한 값으로 설정하면 ClientAliveCountMax세션이 자연스럽게 시간 초과되는 것을 방지할 수 있습니다.

편집 후에는 SSH를 다시 ​​시작하는 것을 잊지 마세요.

sudo systemctl restart ssh

SSL 지원 및 연결 제한 해제를 확인하십시오.

서버는 연결을 보호하기 위해 SSL을 사용하는 경우가 있는데, 클라이언트가 SSL을 지원하지 않거나 제대로 구성하지 않으면 연결이 재설정될 수 있습니다.클라이언트가 필요한 경우 SSL을 지원하는지, 그리고 인증서가 유효하고 올바르게 설치되었는지 확인하십시오.

또한 서버에는 최대 소켓 수(열린 연결 수)가 있습니다.이 한도에 도달하면 새 연결이 거부되거나 재설정될 수 있습니다.이 한도를 테스트하거나 일시적으로 늘리려면 다음 명령을 실행하세요.

ulimit -n 65535

영구적인 변경을 위해서는 /etc/security/limits.conf다음과 유사한 줄을 추가하여 수정하세요.

* soft nofile 65535 * hard nofile 65535

그리고 PAM이 이러한 제한을 준수하도록 설정되어 있는지 확인하려면 편집하여 /etc/pam.d/common-session포함시키십시오 required pam_limits.so.

사용자 지정 스크립트 및 프로토콜 호환성 디버깅

직접 연결 스크립트나 앱을 개발했다면 프로토콜 표준을 준수하는지 확인하세요.소켓 연결을 닫는 것을 잊거나, TLS를 잘못 처리하거나, 예기치 않은 종료 명령을 보내는 등의 버그는 서버가 연결을 재설정하게 만들 수 있습니다.또한, 제대로 종료되지 않은 좀비 프로세스나 자식 프로세스가 있는지 확인하세요.이러한 프로세스는 프로세스 테이블을 가득 채워 온갖 종류의 이상한 오류를 일으킬 수 있습니다.

디버깅 도구나 로그를 사용하여 스크립트의 실행 과정을 추적해 보세요.때로는 연결 시도 방식을 바꾸거나 지연 시간을 추가하는 것만으로도 도움이 될 수 있습니다.이런 문제에 부딪혔을 때는 Stack Overflow와 같은 개발자 포럼이 의외로 유용할 수 있습니다.다만, 충분한 정보와 설정 파일을 공유해야 합니다.