我有一个为用户使用子域的域，例如：
user1.example.com
为了区分其他官方子域和用户子域，我为所有此类情况保留了“at”。例如，一些官方子域是：
api.at.example.com, releases.at.example.com, support.at.example.com
由于误报网络钓鱼检测，我现在已经两次遇到块。离谷歌和思科还差得很远。他们似乎暗示我的网站试图冒充“api.at”或“releases.at”。
服务正在阻止没有其他恶意活动迹象的子域，这很烦人，只是基于它们给出的相当通用的名称。Cisco 尤其烦人，因为他们阻止了 fetch/xhr 请求，而用户无法绕过。只有当您在浏览器中将域作为页面访问时，Google 至少不会阻止 fetch/xhr。
我想知道这种情况有多普遍？我正在考虑保留一些第一级子域来绕过它（例如api.example.com），但服务有效地阻止所有嵌套的子域似乎很愚蠢。如果这不常见，那么我可能会尝试向违规服务提交支持票。
（这是一个全新的域，没有以前的所有者，也没有任何恶意内容，因为我自己编写了整个应用程序）
是的，虽然我同意这种过度阻塞导致广泛的问题是鲁莽的，但这并不限于您可以单独为您解决此问题的单个实体。
我在我管理的桌面系统中安装了类似的阻止规则，并已与重要的商业实体确认他们在其设备群中强制执行此类阻止。我的规则至少只适用于包含或类似拥有和相关品牌名称的域。其他公司声称使用“机器学习”来确定他们的“URL 威胁分类”，在我看来，这听起来更有可能导致您在思科遇到的情况。
这种检测在电子邮件环境中肯定很常见- 如果您看到转发未经授权的邮件，您应该会立即被归类为垃圾邮件来源
<brandname>.<tld>.<otherdomain>.<tld>。您应该审查和监控您的客户，
bankofamerica.com.yourdomain.example以免被骗子使用。如果您的域看起来您忽略了选择安全默认值，那么预计会出现特别敏感的启发式问题。对于在较长域名中间使用的标签，我建议您不要使用任何流行的 ccTLD（例如 .at）和 uTLD（例如 .com） 。根据您向用户提供的服务类型，将该域添加到公共后缀列表中甚至可能是合适的。即使不是，请阅读相关文档，它可以帮助您首先确定在域下托管用户内容是否是一个好主意，该域也用于其他服务（提示：如今，浏览器是复杂的野兽）。