DNS/Rules Issues | Users being led to search domain instead of being directed to it

What is the name of the domain?

‘rlinx.dev’

What is the issue you’re encountering

Currently some mobile users are experiencing issues with the url being searched on their mobile browser instead of being directed to it when for example the base url is used to create a QR code and then scanned.

What steps have you taken to resolve the issue?

Attempted many different configurations of page rules, dns records, and redirects. For further context this domain is one which is deployed under Cloudflare Pages, the DNS records of which were automatically set up during its creation through their guided flow, the only addition being the connection to the custom domain.
Currently I am under the impression this may be an issue from the core codebase not sending the appropiate headers with requests, meaning (if my understanding is correct) the URL’s perceived credibility in a given parsing models eyes, native phone QR code scanners for example, is low enough that the URL identified by the scanned QR is searched instead of directed to.
I am more than capable of forensics on my side and feel like I’ll have a real duh moment when I figure things out, if anybody in the community may have some input for me that would be wonderful.

What are the steps to reproduce the issue?

Reproduction would mean a clone of my current private github repo, deployment to cloudflare pages, proper config of KV storage and Analytics worker, sync with custom domain, and modification of SSL/TLS encrption mode to strict and ‘Always Use HTTPS’ to on. All other parameters are typical.

You could start by sharing the QR code that isn’t working.

Of course, please see attached. When using an IOS device and scanning the QR through the camera the modal prompt directs a user to search the URL instead of being directed to the URL. I’ve also attached screenshots of the current DNS records and Page Rule config.
(Due to my new user status I am limited in what I can attach, please see Cloudinary links below instead.)

QR:


DNS:

Page Rules:

The QR code doesn’t start with a schema, so it will be hit and miss if any device that scans it interprets it as a URL or not. Add https:// in front.

2 Likes

Correct, yet through our market research we’ve determined it’s completely possible. See below pasted logs where we found largely the only difference between our requests and Bitly’s is the included headers; Leading us to believe what I initially mentioned about domain credibility across backend url validity services. For example, Bitly links turned into QR codes from their base domain, direct a given user without issue.

The headers won’t make any difference if the device scanning the QR code doesn’t think what it has scanned is a URL.

2 Likes

This topic was automatically closed after 15 days. New replies are no longer allowed.