web-dev-qa-db-ja.com

サイトアクセスの問題

一部のユーザーがWebサイトにアクセスできません。サイトがまったく読み込まれないか（「サーバーがデータを送信しなかった」などのエラー）、またはブラウザーが単にサイトに接続できません（「ネットワーク接続を確認する」などのエラー）。その間、他のサイトへのアクセスは問題ありません！

私はこれを解決しようとして頭を掻いてきましたが、問題を理解して解決するために考えられるすべての手段を使い果たしました。

私たちが見つけたトリックの1つは、一部（すべてではない）に役立つもので、ブラウザの履歴、キャッシュ、Cookieをクリアすることでした。サイトは再び登場し、彼らのためにうまく機能しました-未知の（しかし短い）時間のために。

単一のブラウザ、OS、またはデバイスを追跡することはできません。これは、ほとんどすべてのデバイス/ブラウザーの組み合わせのユーザーに起こります。また、あるデバイスで一部のユーザーに問題が発生した場合でも、別のデバイスでは問題なく機能します。ああ！

特に役立つユーザーの1人が、私たちのサイトへの接続の問題を常に最新の状態に保ち、最近では1時間以内にCookieなどを削除して、私のサイトにアクセスできるようにしなければなりません。

非常に役立つ別のユーザーは、アドレスバーにURLを手動で入力してもサイトにアクセスできないが、別のWebサイトからリンクをクリックしてサイトにアクセスできるという別の問題に言及しています。ただし、Google検索結果のリンクからサイトを読み込むことはできません!!

私の心が吹き飛ばされます。ここに受験者はいますか？私はありとあらゆる提案を聞きたいです。私たちはすでに失敗しているかもしれませんが、誰かが私たちがまだ試していないという考えを持っているかもしれませんか？

サイトの詳細：Magento 1.9.2.4（完全に更新済み）、Intensoテーマを使用専用サーバーでホスト：Dell Poweredge R220、32GB RAM、256GB Samsung Enterprise SSD（raid 1）x 2、Quad Core-Intel Xeon E3 x 8 -1271 v3 CPU E3 @ 3.6Gh

CentOS 6.8およびApacheを実行しているサーバー

URL： https://www.modelhelicopters.co.uk/

乾杯、ロブ

apachewebservermagento
3
robgt

この断続的な問題が発生し始め、さまざまなシステム、テクノロジープラットフォーム、およびネットワーク上の顧客に影響を与えている場合、多くの場合、問題は一般的なインターネットの正常性に関係しています。 1月の質問の日付に注目し、私が見つけることができたものを調べると、1月に断続的に問題が発生し、かなりの数の人々にこの問題が発生することがありました。より一般的な意味では、あなたが見なければならないトラブルシューティングの質問は含んでいます...

  • これは1種類のブラウザにのみ影響しますか？ 1種類のブラウザにのみ影響する場合は、その特定のブラウザに対してサイトの開発レベルのテストを行い、ブラウザの最新の更新を確認するか、または拡張機能の組み合わせがサイト上の何かに影響を与えています。特定のケースでは、拡張機能またはブラウザが変更されるまでサイトに同じ影響を与え続ける必要があり、そのブラウザと拡張機能の組み合わせを持つほとんどの人に影響を与えるため、異常です。
  • これは1つのISPの顧客に影響しますか？ピアリングが行われている方法を考えると、ゲートウェイのルーティング構成に誤りがある場合、ISPの顧客に対してインターネットの一部がブロックされる可能性があります。これは、1つのISPが1つの州のみにサービスを提供する単一のゲートウェイでルーティング構成に小さなミスを犯したオーストラリアで以前に発生しました。問題のないオーストラリアのサイト。
  • これは顧客のすべてまたは大部分に影響しますか？これは、サーバーまたはホスティングプロバイダーのネットワークに問題があることを示している可能性があります。ここでできることはそれほど多くありません。プロバイダーに調査して、問題を特定できるかどうかを確認するように要求するサポートチケットを提出する以外にありません。共有サーバーでは、他のクライアントがホスティングプロバイダーに既に接続している可能性がありますが、専用サーバーを使用すると、ネットワークに応じて、他のホスティングクライアントに障害が影響する場合と影響しない場合があります。

あなたの特定の状況では、私はネットワークレベルの問題をもっと見る傾向があります。私はコメントから、サービスの監視についての提案があったことを認識していますが、それをもう少し拡張します。ホスティングプロバイダーが監視を行うことに注意してください。監視を行うほとんどのホスティングプロバイダーは、アラームを監視するシステム中心の監視を行いますが、常にすべてを監視するわけではないため、独自の監視を行うことをお勧めします。ベストプラクティスは、ネットワークエンドポイントとしてだけでなく、Webサイトとしてのサイト自体のパフォーマンスを監視する顧客中心の監視を行うことです。安価なものはサーバーにpingできるかどうかを確認するだけですが、より良いものは実際にサイトでHTTPチェックを実行し、サイト自体が戻ってくるか、サービスにかかる時間などを確認します。時間のしきい値を超えた場合、Webサイトがオフラインになった場合、またはサイト以外のものが提供された場合、アラームがトリガーされ、電子メールが送信されます。また、世界中の複数のネットワークからチェックするサービスを使用する必要があります。これにより、1か国、または限られた範囲のティア2のユーザーにのみ影響する障害が発生する可能性があるため、状況をよりよく把握できますまたは一般的なインターネットではなく、地域のティア1ネットワーク。

Magentoからの潜在的な修正
この回答に対するあなたのコメントに基づいて、私が見つけたいくつかのさらなる情報に基づいてこの編集を追加しました。

Magentoコアには、frontend_cid Cookieの更新に必要なロジックが存在しないという既知のエラーがあるようです。別の人は、失われたCookieに遭遇しましたが、それが引き起こしたエラーの原因については詳しく説明していないようです。

Magentoは、彼らが明らかにパブリッシュすることはできなかったが、人がパブリッシュしたパッチを提供したので、これを試してみて、それがどうなるかを確認できます。同じルート障害が原因である場合、問題はapp/code/core/Mage/Core/Model/Session/Abstract/Varien.phpにあります。パッチが行うことは置き換えです

if (Mage::app()->getFrontController()->getRequest()->isSecure() && empty($cookieParams['secure'])) {
            // secure cookie check to prevent MITM attack
            $secureCookieName = $sessionName . '_cid';
            if (isset($_SESSION[self::SECURE_COOKIE_CHECK_KEY])
                && $_SESSION[self::SECURE_COOKIE_CHECK_KEY] !== md5($cookie->get($secureCookieName))
            ) {
                session_regenerate_id(false);
                $sessionHosts = $this->getSessionHosts();
                $currentCookieDomain = $cookie->getDomain();
                foreach (array_keys($sessionHosts) as $Host) {
                    // Delete cookies with the same name for parent domains
                    if (strpos($currentCookieDomain, $Host) > 0) {
                        $cookie->delete($this->getSessionName(), null, $Host);
                    }
                }
                $_SESSION = array();
            }
            if (!isset($_SESSION[self::SECURE_COOKIE_CHECK_KEY])) {
                $checkId = Mage::helper('core')->getRandomString(16);
                $cookie->set($secureCookieName, $checkId, null, null, null, true);
                $_SESSION[self::SECURE_COOKIE_CHECK_KEY] = md5($checkId);
            }
        }

と

if (Mage::app()->getFrontController()->getRequest()->isSecure() && empty($cookieParams['secure'])) {
            // secure cookie check to prevent MITM attack
            $secureCookieName = $sessionName . '_cid';
            if (isset($_SESSION[self::SECURE_COOKIE_CHECK_KEY])) {
                if ($_SESSION[self::SECURE_COOKIE_CHECK_KEY] !== md5($cookie->get($secureCookieName))) {
                    session_regenerate_id(false);
                    $sessionHosts = $this->getSessionHosts();
                    $currentCookieDomain = $cookie->getDomain();
                    foreach (array_keys($sessionHosts) as $Host) {
                        // Delete cookies with the same name for parent domains
                        if (strpos($currentCookieDomain, $Host) > 0) {
                            $cookie->delete($this->getSessionName(), null, $Host);
                        }
                    }
                    $_SESSION = array();
                } else {
                    /**
                     * Renew secure cookie expiration time if secure id did not change
                     */
                    $cookie->renew($secureCookieName, null, null, null, true, null);
                }
            }
            if (!isset($_SESSION[self::SECURE_COOKIE_CHECK_KEY])) {
                $checkId = Mage::helper('core')->getRandomString(16);
                $cookie->set($secureCookieName, $checkId, null, null, null, true);
                $_SESSION[self::SECURE_COOKIE_CHECK_KEY] = md5($checkId);
            }
        }

これで、Magentoのインストールに、コメントで指定したとおりにfrontend_cid Cookieを更新するロジックが欠落している場合は、この問題を解決できます。パッチSUPEE-7136として提供されましたが、現時点では公式チャンネルから公開されていませんでしたが、この問題に遭遇した他の人は昨年10月にしか遭遇しなかったため、同じ根本原因が原因で同様の問題が発生する可能性があります。

1
Chris Rutherfurd