嵌套子域是否因網路釣魚檢測而被阻止？
我有一個為使用者使用子域的域，例如：
user1.example.com為了區分其他官方子域和使用者子域，我為所有此類情況保留了“at”。例如，一些官方子域是：
api.at.example.com, releases.at.example.com, support.at.example.com由於誤報網路釣魚檢測，我現在已經兩次遇到塊。離Google和思科還差得很遠。他們似乎暗示我的網站試圖冒充“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） 。根據您向使用者提供的服務類型，將該域添加到公共後綴列表中甚至可能是合適的。即使不是，請閱讀相關文件，它可能會幫助您首先確定在域下託管使用者內容是否是一個好主意，該域也用於其他服務（提示：如今，瀏覽器是複雜的野獸）。