Does Azure block the requests from the URL contains GA's cross domain parameter?

@Seungbin Pang Can you please elaborate more on your set-up and provide information on which all Azure Services you are using? Have you set-up a Web Application Firewall or Azure DDOS protection?

ChaitanyaNaykodi-MSFT thank you, it is sooo much grateful, since I'm a marketer (here's no IT manager...) I post below picture of the incident, have no informations on firewall and protection, but my other IT partner replied this is a rare incident the AZURE, normally it will not block the certain Google analystic applied URLs...there's no or little chance the AZURE activated the DDos protection since the URL's GA parameter because it is commonly used in IT industry. My apologies for not enough information.

Hello @Seungbin Pang , Thank you for the quick reply here. Unfortunately, this not enough information to troubleshoot the issue here. I think it will be best to file a support ticket in this case as a support engineer can take a deeper look at your set-up and determine the exact issue. If you have a support plan you may file a support ticket, else could you please send an email to azcommunity@microsoft.com with the below details. Subject : Attn Chaitanya

Thread URL: Link to this thread.

Subscription ID

Please let me know once you have done the same.

@Seungbin Pang Just following up here to see if you were able take a look at my comment above. Thank you!

A. The trigger is the same shared before.  We are receiving all of the request see below 8.46k, however all was detected as malform URL.

Sample of one of 8.46k the response code 400

It is a little challenging to extract the logs as we incorporate our logging directly into the Microsoft workbench analytics for most of our entire platform.   Q.
Do they know why the page seems to be loading fine with the parameter in place now? Were there additional parameters on the ad we did not know about? A. Yes, it looks fine and no malform URL detected.  I believe the Google Analytics will mention this as well.  On additional parameters we might not be able to advice as this from two different sites: rescue.org -> rescue.or.kr. Q.  Can SG let us know how we can set up the URL differently for the next time we run Naver ads? Should the cross-site scripting be turned off? Should the URL be formed or configured in some different way in the ad platform? A. Usually there is pre-staging not just click on the link but a pre-stage with volume to test the demand capacity.  I am not sure if Naver can provide a test run.  URL as long it obeys the Internet rules it should be fine.  Another we notice is why not use UTM in the link instead?  Instagram analytics uses UTM heavily and it is cross site friendly however it has different analytic goals. Yes, cross-site scription should be turned off or it should follow uniform safe cross sites rules.  Another is to consider using CloudFlare WAF services as the domain names and the internet routing flow is in your control.   Q. Are there other actions SG proposes taking to handle high volumes of traffic? What are the limitations here? Has load testing been performed? A. Currently in actual the platform is able to receive hence why you see the 8.46k transactions coming in but stopped at the Azure level. The site is currently having the same capacity as that of one of our core Products and Services Charitable and SignUp.   Regarding Azure DDOS this is something we have seen before.  Please understand this is just additional information from our previous experiences.  It is more of a response inflammation. It can be also due to WAF is not implemented at the controlling domain name however I do not know enough of the current originating domain setup reference to rescue.or.kr to comment. I no longer have the reference but it is similar to this. https://www.microsoft.com/en-us/security/business/security-101/what-is-a-ddos-attack In our experience we notice that when the Azure DNS is flooded with the what it might think as an attack it will clear the global DNS cache which we also saw thru our internet routing monitoring as the CNAME url was no longer able to request post the 8.46k requests that went thru. We moved to CloudFlare DNS with WAF to allow our own assets to be always contactable at all times and CloudFlare DNS also allows us granular control to not have the global cache emptied or clear or to quickly put back.