# Browser cookie corruption(?) after site migration on Azure
**URL:** https://meta.discourse.org/t/browser-cookie-corruption-after-site-migration-on-azure/141574
**Category:** Support
**Created:** [February 14, 2020, 4:23am UTC](https://meta.discourse.org/t/browser-cookie-corruption-after-site-migration-on-azure/141574 "2020-02-14T04:23:07Z")
**Posts on this page:** 5
**Page:** 1
### Author:  [@Simon\_Miller](https://meta.discourse.org/u/Simon_Miller)
#### Post date: [February 14, 2020, 4:23am UTC](https://meta.discourse.org/t/browser-cookie-corruption-after-site-migration-on-azure/141574/1 "2020-02-14T04:23:07Z")
Hello,
I have migrated a Discourse platform from Vultur host to Azure, within a CentOS linux flavour. The migration went smoothly, using the built in database backup and restore process. We then delegated the DNS.
Some users (including myself at one point) are getting the sad face 500 error loading /latest.json. In all instances, clearing your cookies/sessions fixes the problem.. but it appears to come back after half an hour or so.
I was also as an admin able to see during the error in my Settings section that the key-value pairs for the various settings labels were not parsed to a language locale e.g. “default locale” was displayed as something like “[en.default\_locale]”.
I am not a Linux or Discourse guru so have no idea where to go with this issue. It may be things “settling down” after DNS migration, or there could be something more going on.
The problem so far has only been reported on Windows Chrome. I cannot reproduce on Edge or Chrome Android.
Looking in the /logs I see entries such as the following:
```
Job exception: PG::InvalidTextRepresentation: ERROR: invalid input syntax for type inet:"106.70.36.109:6082" LINE 1: UPDATE "users" SET "ip_address" = '106.70.36.109:6082' WHERE...
```
Any advice would be appreciated.
Simon
---
### Author:  [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [February 14, 2020, 5:56am UTC](https://meta.discourse.org/t/browser-cookie-corruption-after-site-migration-on-azure/141574/2 "2020-02-14T05:56:49Z")
> [@Simon\_Miller](#):
>
> invalid input syntax for type inet:“106.70.36.109:6082”
That is a well know Azure bug with some workarounds described here
> [@Invalid input for update\_ip\_address](https://meta.discourse.org/t/invalid-input-for-update-ip-address/77085/13):
>
> Hi, Just to add to the conversation - this is standard practice in Azure Application Gateways, and it’s infuriating. They add the port to the forwarded-for header even though they also send it in the forwarded port header. Two feedback/change requests on Microsoft which you can vote for; [Azure Application Gateway x-forwarded-for remove port information – Customer Feedback for Microsoft Azure](https://feedback.azure.com/forums/217313-networking/suggestions/33043528-azure-application-gateway-x-forwarded-for-remove-p)[Support for dropping port out of x-forwarded-for header – Customer Feedback for Microsoft Azure](https://feedback.azure.com/forums/217313-networking/suggestions/20220997-support-for-dropping-port-out-of-x-forwarded-for-h) Our …
---
### Author:  [@Justin\_Vega](https://meta.discourse.org/u/Justin_Vega)
#### Post date: [February 14, 2020, 10:10pm UTC](https://meta.discourse.org/t/browser-cookie-corruption-after-site-migration-on-azure/141574/3 "2020-02-14T22:10:15Z")
> [@Simon\_Miller](#):
>
> I cannot reproduce on Edge
Chromium Edge or Legacy Edge?
---
### Author:  [@Simon\_Miller](https://meta.discourse.org/u/Simon_Miller)
#### Post date: [February 17, 2020, 4:30am UTC](https://meta.discourse.org/t/browser-cookie-corruption-after-site-migration-on-azure/141574/4 "2020-02-17T04:30:10Z")
We came to this conclusion as well, and it was the case. The Appgw was sending its internal IPs instead of user IPs and presumably Nginx’ flood protection was kicking in. Updating Nginx configs solved the issue.
---
### Author:  [@system](https://meta.discourse.org/u/system)
#### Post date: [March 18, 2020, 4:30am UTC](https://meta.discourse.org/t/browser-cookie-corruption-after-site-migration-on-azure/141574/5 "2020-03-18T04:30:32Z")
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.