兄弟，刚迁移完独立Fastly账户就遇上这种周期性搞崩服务器的麻烦，真的够糟心的。我结合Fastly的实际使用经验，给你梳理下排查思路和精准拦截的方案：

一、先搞清楚：这些流量到底是啥来头？ #

想要精准拦截，得先摸透对手的底，别上来就瞎拦误伤正常用户：

• 把Fastly的日志拉满挖细节！默认的日志维度太浅，你得在VCL里新增几个关键日志字段：req.url的完整参数、req.http.Referer的具体内容、client.ip（请求的真实IP）、还有req.http.User-Agent。等下次流量冲击来的时候，导出日志一分析，就能搞清楚这些Google跳转请求是不是来自同一批IP集群，UA有没有重复的爬虫标识，甚至能看到它们死盯着你站点的哪个页面薅。
• 解析Google跳转的真实目标：Google的google.com/url?跳转链接里，url参数才是指向你站点的真实路径。你可以在VCL里用querystring.get(req.url, "url")提取这个参数，看看这些请求是不是集中在某个特定页面（比如后台API、高频更新的内容页），这能帮你判断是针对性爬取还是无差别恶意请求。
• 对比迁移前后的Fastly配置差异：哪怕你说迁移得完全准确，Heroku的Fastly add-on可能带了一些默认防护规则或缓存策略，独立账户的默认配置说不定不一样。比如缓存命中率是不是迁移后掉了？要是更多请求直接透传到Heroku，再叠加恶意流量，服务器不崩才怪。先查下缓存命中率，要是不对就调回之前的策略，能先减轻一半压力。

二、精准拦截：别误伤正常Google跳转用户 #

搞清楚流量特征后，就可以在Fastly层动手拦截，把恶意请求挡在Heroku外面：

• 抓IP集群的小辫子：如果日志里发现恶意请求集中在某几个IP段，直接在Fastly的IP黑名单里加就行——不过得先确认这些IP不是普通用户的，恶意爬虫的IP大多是云服务商的集群IP，和家庭用户的IP很好区分。
• 基于跳转请求的特征写VCL规则：比如发现这些请求都是通过Google跳转访问你某个特定页面，就可以在VCL里加规则：当req.http.Referer包含google.com/url?或google.co.uk/url?，且请求路径匹配那个特定页面，同时请求频率超过正常范围，直接返回403拦截。
• 用Rate Limiting软限制：要是不想硬拦，就给这类请求设个限速门槛——比如同一个IP通过Google跳转来的请求，每分钟最多10次，超过就返回429。正常用户通过Google搜来的请求绝对到不了这个频率，恶意爬虫一冲就触发限制，还不会误伤好人。
• 揪出UA的马脚：正常用户的UA都是Chrome、Safari这些浏览器的标准标识，恶意爬虫的UA要么是一堆奇怪字符，要么是明确的爬虫名字（比如Scrapy/2.8.0）。你可以在VCL里加规则：如果Referer是Google跳转，同时UA属于爬虫类，直接拦截。
• 用Fastly WAF补漏：要是你开了Fastly的WAF功能，可以创建自定义规则，匹配「Referer含Google跳转+请求频率过高」「UA异常+Google跳转」这类组合特征，自动拦截恶意请求。

三、临时应急：先把服务器保住 #

要是现在流量还在炸服务器，先搞个临时限速救急：在Fastly里给所有来自Google跳转的请求设个宽松点的限速（比如每分钟20次），先把峰值压下来，再慢慢排查精准拦截的规则，别让服务器一直挂着。

备注：内容来源于stack exchange，提问作者Adaddinsane