정말 더 알고 싶은 이상한 문제가 있습니다. 어제 저는 호스팅 서버에 새 사이트를 배포하고 있었습니다. 서버에서 PHP 5.2.17로 전환하기 전날 . PHP 5.4.10이상한 점은 버전이 여전히 5.2.17? 나는 동료에게 사이트를 방문해 달라고 요청했고 그는 올바른 버전을 얻었습니다. 마지막으로 VPN(이 특정 서버에는 사용되지 않음)을 끄자 서버가 올바른 PHP 버전을 실행하는 것을 즉시 확인할 수 있었습니다. 이제 저는 왜 이런 일이 일어났는지 정말로 알고 싶습니다. 내가 생각할 수 있는 유일한 것은 이것이 실행 중인 VPN 터널과 관련된 일종의 캐싱 문제임에 틀림없다는 것입니다.
웹 루트에서 SSH를 통해 새 파일을 생성하면 브라우저를 통해 파일에 액세스할 수 없으며 대신 404 페이지가 나타납니다. VPN을 켜거나 다시 시작하면 이 오류가 사라집니다.
나는 사용하고있다주노 펄스내 VPN 클라이언트로.
제가 알아차린 또 다른 흥미로운 점은 VPN 클라이언트를 다시 시작한 후 페이지에 올바른 버전이 다시 보고된다는 것입니다.
답변1
제 생각엔 공급자+DNS 문제인 것 같습니다. 특히 공급자가 공유 웹 저장소가 있지만 주기적으로 시스템 저장소를 동기화하는 여러 컴퓨터를 가지고 있다고 가정합니다. 그리고 VPN을 사용하거나 사용하지 않음으로써 이전에 라우팅을 다른 컴퓨터로 변경했습니다. PHP - 업데이트되었습니다.
이에 대한 징후는 다음과 같습니다. 1. 캐시가 아닙니다. info.php 파일의 이름을 바꾸면 문제가 해결됩니다. 2. 라우팅 관련 문제입니다. VPN을 통해 라우팅이 변경됩니다. 3. 일시적인 문제였습니다.
답변2
기본 설정을 확인하지 않고 문제가 무엇인지 정확히 말하기는 어렵지만 제공한 일부 정보를 기반으로 info2.php 파일을 생성했고 동일한 문제가 있었다는 점을 고려하면 캐시일 가능성은 거의 없습니다.
VPN을 사용할 때 다른 서버로 라우팅되는 위치를 나타냅니다. 공급자의 로드 밸런서 또는 DNS를 통해(여러 레코드/라운드 로빈이 있는지 확인) 귀하의 VPN에는 이 문제를 일으킬 수 있는 캐시가 없습니다(제 생각에는 귀하가 겪고 있는 캐시입니다).
다양한 로드 밸런서 구성이 있지만 그러한 구성 중 하나는 IP 해시를 기반으로 하며, 이는 항상 동일한 시스템(아직 변경 사항을 동기화하지 않았을 수 있음)에 머물러 있지만 다른 시스템에서 액세스할 때 다른 시스템으로 라우팅되는 이유를 설명합니다. IP. nginx를 참조하세요IP_해시그러한 밸런서 구성의 예를 들어보세요. 구체적으로,
클라이언트 IPv4 주소의 처음 3개 옥텟 또는 전체 IPv6 주소가 해싱 키로 사용됩니다. 이 방법을 사용하면 이 서버를 사용할 수 없는 경우를 제외하고 동일한 클라이언트의 요청이 항상 동일한 서버로 전달됩니다.
DNS 옵션의 경우 도메인이 여러 A 레코드로 라우팅되는지 확인하거나 다음과 같은 도구를 사용할 수 있습니다.mxtoolbox이는 실제 LB가 없는 경우 다른 시스템으로 라우팅되는 것을 설명할 수도 있기 때문입니다.
이와 유사한 상황에서 떠오르는 것은 최근 특정 요청에 표시되지 않는 코드 변경이었습니다. 문제는 ENOM이 인터페이스에서 RFC1034에 따라 허용되지 않는 루트 레코드에 CNAME을 허용한다는 것입니다. 그러나 실제로 일어나는 일은 단순히 CNAME의 A 레코드를 조회하는 것입니다. 이 경우에는 AWS ELB였으며 ELB가 해결한 두 IP에 대해 2개의 A 레코드를 생성한 다음 몇 달 후 AWS가 IP 중 하나를 ELB로 변경했습니다. 이에 대한 라우팅이 반영되지 않았으므로 일부 요청이 이전 ELB IP로 라우팅되고 차례로 이전에 캐시된 코드가 표시됩니다.