Both the apex and www domains are verified on our side with valid TLS certificates, and the public nameservers and public resolvers (Google and Cloudflare) return our edge address, which matches your successful curl test against 69.46.46.69.

The other answers you saw (95.179.149.165, 159.100.251.128 and ::1) are not coming from the domain's DNS, so the Wi-Fi networks returning them are getting answers from their own resolver, router, or a filtering service, and the certificate errors follow from browsers connecting to a server that does not hold your certificate. The DNS records and certificates need no corrections, and you can confirm this on an affected network by switching that device or router to 1.1.1.1 or 8.8.8.8, flushing the DNS cache, and retrying.

Please escalate this issue to a human support engineer. The problem affects multiple independent Wi-Fi networks and prevents users from accessing our production website and QR codes.

We re-checked both domains just now. Both are verified with valid certificates, the authoritative nameservers for the domain answer correctly, and public DNS returns only our edge address 69.46.46.69. That matches your successful curl tests, so no DNS records, delegation, or certificate settings need to change.

The other addresses you saw (95.179.149.165, 159.100.251.128, and ::1) are not answers from the domain's DNS or from our infrastructure. Each affected Wi-Fi network is getting them from its own resolver, router, or a DNS filtering service in front of it, and the certificate errors happen because browsers on those networks are being sent to a server that does not hold your certificate. That is also why mobile data works: it uses a different resolver.

On an affected network, setting the router or device DNS to 1.1.1.1 or 8.8.8.8 and flushing the DNS cache will show whether that network's resolver is the cause. Where you do not control the network, its administrator or ISP needs to stop overriding or filtering the domain.

Thank you for checking.

I understand that the authoritative DNS and TLS certificates appear to be configured correctly.

However, the issue remains unresolved and affects access to our production website from multiple Wi-Fi networks.

Could you please escalate this case to a human support engineer?

I would also appreciate confirmation of whether there are any known domain reputation or DNS filtering issues affecting myidentita.com.

I need to determine why multiple networks return unexpected DNS addresses and how to resolve this for all visitors, without requiring individual users to change their DNS settings.

Thank you.

We checked again just now and nothing has changed on our side: both domains are verified with valid certificates, the domain's nameservers are our registrar's, and public DNS returns only our edge address, the same one your successful curl tests used.

We have no record of any reputation flag, block, or DNS filtering applied to the domain by us, and the addresses those Wi-Fi networks returned are not ones we serve. We can't see into the resolvers or filtering services those networks use, so we can't tell you which list or policy is rewriting the answer. An address like ::1 points back at the visitor's own device, which is how many filtering resolvers and content blockers handle a domain they've decided to block.

There is no change to the domain's DNS or certificates that will override a network resolver that is substituting its own answer. Because the domain is new and the QR codes send people straight to it, filtering services that score newly registered domains are a common cause. The way to fix this for every visitor is to find out which resolver or security product each affected network uses, then ask that vendor or network administrator to review or reclassify the domain.

Thank you for your response.

The problem is still unresolved and affects our production service.

I understand that your authoritative DNS records and TLS certificates are valid. However, several Wi-Fi networks return unexpected IP addresses, causing DNS and certificate errors, while direct connections to your edge IP work correctly.

This is particularly serious because our customers scan QR codes attached to vehicles and must be able to open the website immediately, without changing their DNS settings.

Could you please escalate this case to a human support engineer rather than an automated response?

Please also confirm whether Railway can assist with investigating domain reputation, DNS filtering, or any registrar-related issue affecting this recently registered domain.

We need a permanent solution for visitors across different networks.

Thank you.

We re-checked the domain again just now and nothing has changed: it is verified with a valid certificate, its nameservers are the ones the registrar assigned when you bought it, and public DNS returns only our edge address, the same one your direct tests succeed against. We see no registrar-side problem with the domain, and we have not applied any reputation flag, block, or filtering to it.

We can't investigate or change how third-party resolvers or DNS filtering services on other networks classify the domain, because those lists and policies belong to whoever runs those networks, not to us or the registrar. No change to the domain's DNS records or certificate will override a resolver that substitutes its own answer.

The permanent fix for all visitors has to come from the networks that are rewriting the answer. On each affected Wi-Fi network, the network owner or ISP can tell you which resolver or security product it uses, and that vendor or administrator is the one who can review or reclassify the domain so it resolves normally there.

Thank you for your response.

The issue is still unresolved and affects real users of MYIDENTITA.COM across multiple Wi-Fi networks and devices.

I understand that your authoritative DNS records and TLS certificates appear correct. However, the domain is being resolved to unexpected IP addresses by some networks, causing SSL certificate errors and making our QR AUTO service inaccessible.

Since the domain was purchased through Railway, I would like this case escalated to a human support engineer.

Could you please:

1. Confirm the domain's registration date and authoritative nameserver configuration.
2. Investigate whether the domain or its previous history could be causing DNS security filtering or reputation-based blocking.
3. Recommend an actionable domain-wide solution or a process for requesting reclassification by major DNS security providers.
4. Confirm whether moving authoritative DNS management to Cloudflare while keeping Railway hosting would be supported.

This is a production service where users scan QR codes to contact vehicle owners. We cannot require every visitor to change their Wi-Fi or DNS settings.

Please keep this support case open until we have a clear remediation plan.

Thank you.