サーバーログを確認したところ、次のような奇妙なリクエストが大量に届いていることがわかりました。iOS 9 Universal Linking を実装しましたが、私の知る限り、これらのリクエストは /apple-app-site-association に対して実行されています。
Jan 15 09:36:23 method=GET path="/.well-known/apple-app-site-association"
他の誰かがこれらのパターンを見たことがありますか? これは既知のスパム行為か何かですか?
iOS 9.3 では、apple-app-site-association ファイルとアプリのハンドオフ機能に関して、わずかに異なるルックアップ ロジックが導入されたと思います。
「Handoff は、最初に .wellknown サブディレクトリ (たとえば、https://example.com/.well-known/apple-app-site-association ) でファイルを検索します。 .well-known サブディレクトリは使用しないでください。」
iOS 9.3 以降、Apple は最初にダウンロード/.well-known/apple-app-site-associationを試み、失敗した場合は にフォールバックし/apple-app-site-associationます。
Apple のテクニカル Q&A QA1919を参照してください。
/.well-known/apple-app-site-association ファイルの着信リクエスト
Q: Web サーバーがhttps://example.com/.well-known/apple-app-site-associationのリクエストを受信するのはなぜですか?
A: 最近リリースされた iOS 9.3 アップデートでは、RFC 5785が実装されています。このため、iOS 9.3 を実行しているデバイスは、ユニバーサル リンクと共有 Web 資格情報を実装するために必要なファイルを最初に要求
/.well-known/apple-app-site-associationします。この場所にファイルが見つからない場合、iOS 9 の以前のリリースと同様に、デバイスは Web サーバーのルートにあるファイルを要求します。apple-app-site-association
この動作も見られます。現在、サーバーのアクセス ログ ファイルの大部分は、この特定のファイルに対する要求です。
アプリケーションサーバー/フレームワークの前で静的ファイルを提供するnginxを使用してセットアップを実行している場合は、/.well-known/apple-app-site-associationAND/apple-app-site-associationファイルが存在するか、応答を返すことを確認してください。
そうでない場合、欠落しているリクエストはすべてフレームワークに渡され、多くの場合、一致しないと判断する前にルートを処理する必要があります。昨日その変更を行うまで、サーバーに加えられたストレスはかなりのものでした。
これらのリクエストがたくさん見られます (.well-knownサブディレクトリの有無にかかわらず)。それらは から来てgoogle-botいますが、ある時点で他のスパイダーもそれらを探し始める可能性があると思います。iOS私のサイトには(またはAndroid) アプリと重複する機能がないため、帯域幅の無駄です。アプリケーションサーバーを保護するための@aramisbearの回答が好きです( https://stackoverflow.com/a/36185061/467590 )。しかし、代わりにそれらを私のものに追加しようとしますrobots.txt。google-bot念のためrobots.txt(そして、アプリ インデックスの作成に関心のある他のボットもほぼ確実にそうするでしょう)、これを行うことで、nginxプロキシの帯域幅の浪費も防ぐことができると思います。