请求/.well-known/apple-app-site-association
我刚刚检查了我的服务器日志，发现了很多很奇怪的请求。 我已经实现了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围绕苹果应用程序站点关联文件和应用程序切换function引入了稍微不同的查找逻辑。
“切换首先在.well-known子目录中search该文件（例如https://example.com/.well-known/apple-app-site-association ），如果您返回到顶级域名不要使用.well-known子目录“。
请参阅： https ： //developer.apple.com/library/ios/documentation/UserExperience/Conceptual/Handoff/AdoptingHandoff/AdoptingHandoff.html#//apple_ref/doc/uid/TP40014338-CH2-SW10
我也在我的日志中收到以下内容：
[Mon Feb 29 12:34:53 2016] [error] [source 66.249.75.XXX] File does not exist: /public_path/apple-app-site-association
日志中的XXX是0到255之间的数字。
然后，我查了Whois IP 66.249.69.0，1，2 ……. 255
而我发现，All IP范围从66.249.64.0 – 66.249.95.255分配给Google Inc 等你开玩笑吧，为什么谷歌要求我的服务器上的apple-app-site-association ？
因为Google将其映射扩展为包含网站与特定iOS应用程序之间关联的信息，以用于Google App Indexing，以便在Safari中使用来自Googlesearch的通用链接。 。
WhoisloginIP 66.249.69.0
NetRange: 66.249.64.0 - 66.249.95.255 CIDR: 66.249.64.0/19 NetName: GOOGLE NetHandle: NET-66-249-64-0-1 Parent: NET66 (NET-66-0-0-0-0) NetType: Direct Allocation OriginAS: Organization: Google Inc. (GOGL) RegDate: 2004-03-05 Updated: 2012-02-24 Ref: https://whois.arin.net/rest/net/NET-66-249-64-0-1 OrgName: Google Inc. OrgId: GOGL Address: 1600 Amphitheatre Parkway City: Mountain View StateProv: CA PostalCode: 94043 Country: US RegDate: 2000-03-30 Updated: 2015-11-06 Ref: https://whois.arin.net/rest/org/GOGL OrgAbuseHandle: ABUSE5250-ARIN OrgAbuseName: Abuse OrgAbusePhone: +1-650-253-0000 OrgAbuseEmail: email@google.com OrgAbuseRef: https://whois.arin.net/rest/poc/ABUSE5250-ARIN OrgTechHandle: ZG39-ARIN OrgTechName: Google Inc OrgTechPhone: +1-650-253-0000 OrgTechEmail: email@google.com OrgTechRef: https://whois.arin.net/rest/poc/ZG39-ARIN
我们也看到了这种行为。 我们服务器的绝大多数访问日志文件现在都是针对这个特定文件的请求。
如果你碰巧正在运行一个安装程序，nginx在应用服务器/框架之前提供静态文件，一定要确认/.well-known/apple-app-site-association AND /apple-app-site-association文件存在或返回响应。
如果他们不这样做，缺less的请求将全部传递给您的框架，在许多情况下，导致在确定不匹配之前必须处理您的路由。 直到昨天我们做出这样的改变，我们的服务器增加的压力是相当大的。
我看到很多这样的请求（无论是否有.well-known子目录）。 他们来自google-bot ，但我想其他蜘蛛也可能会开始寻找他们，在某些时候。 由于我的网站没有任何与iOS （或Android ）应用程序的重叠function，他们是浪费带宽。 我喜欢@ aramisbear的答案来保护我的应用程序服务器（ https://stackoverflow.com/a/36185061/467590 ）。 但是我会尝试将它们添加到我的robots.txt 。 由于google-bot尊重robots.txt （和其他机器人有兴趣创build应用程序索引几乎肯定也会），我会认为这样做可以防止甚至浪费我的nginx代理的带宽。
