`wget` 오류 발생 시 더 많은 로그를 얻는 방법

`wget` 오류 발생 시 더 많은 로그를 얻는 방법

wgetGNU/Linux의 도구에 관해 몇 가지 질문이 있습니다:

# wget http://www.jdfschool.com

--2019-04-05 02:33:44-- (Trys: 3) http://www.jdfschool.com/
Connecting www.jdfschool.com|115.28.223.13|:80... Connected.
An HTTP request has been issued, waiting for a response... Connection reset by peer.
Retrying.
  1. ConnectedConnecting www.jdfschool.com|115.28.223.13|:80... Connected.TCP 연결이 성공했다는 뜻 인가요 ?

  2. 로그에서 봤는데 Connection reset by peer, 더 자세한 로그가 있나요? 초기화 문제의 원인을 모르겠습니다.

답변1

올바르게 가정한 대로 80... 연결됨은 (웹) 서비스가 포트 80에서 수신 대기 중이고 이에 연결할 수 있음을 의미합니다.

귀하의 브라우저(및 기타 IP 주소)를 사용하여 사이트가 제대로 작동하는 경우, connection reset by peer귀하가 무엇을 시도하더라도 작동하지 않을 것이라는 피드백만 제공할 뿐입니다. 더 자세한 내용을 알고 싶다면 연결을 스니핑해 보세요.

그러나 사이트 소유자에게 로그/디버깅을 요청하지 않으면 재설정 이유에 대한 더 많은 데이터를 얻을 수 없을 것입니다.

그 이유는 사용자 에이전트/스파이더/특정 페이지/또는 구성을 허용하지 않거나 의도적으로 해당 오류를 발생시키거나 정의된 기간 내에 페이지를 시도한 후/페이지를 차단하는 규칙이 있을 수 있습니다( 그들에 의해 정의됨)).

이전에 언급했듯이 이는 Unix 문제 자체보다는 사이트별 보안 조치 및 구성과 더 관련이 있습니다.

실제 HTTP 요청을 수신하려면 다음을 실행할 수도 있습니다.

# ngrep -q "." "port 80"

또는

# ngrep -q "." "port 80 and host www.jdfschool.com"

ngrep구성, HTML, DNS 및 인프라 설정에 따라 두 번째 항목이 모든 HTTP 요청을 수신하는 것은 아닙니다.

@muru가 의견에서 지적했듯이

wget -v http://www.jdfschool.com

보다 유용한 데이터를 출력하는 것도 가능합니다.

앞서 말했듯이, 그 일이 발생한 이유를 정확히 찾아낼 가능성은 희박합니다. (예를 들어 Apache 웹 서버에서는 mod_evasive 및 mod_security가 스파이더/남용을 억제하도록 설정되는 경우가 많습니다.)

TLDR 사이트 소유자의 관점에서 볼 때 귀하의 명령으로 일어나는 일은 예상된 동작일 가능성이 높습니다.

관련 정보