DEV Community: Faizan

Unknown character set index for field received from server

Faizan — Sun, 18 Oct 2026 11:52:56 +0000

java.sql.SQLException: Unknown character set index for field '255' received from server. If your app suddenly throws this after moving to MySQL 8, the database isn't broken. Your client is too old to understand the collation the server is sending back.

The "unknown character set index for field received from server" error means MySQL sent a collation ID (usually 255, which is utf8mb4_0900_ai_ci) that your driver doesn't know about. Fix it by upgrading the MySQL driver. If you can't, switch the server and your tables to utf8mb4_unicode_ci.

Why unknown character set index for field received from server happens

Every column in a result set comes with metadata, including a numeric collation ID. MySQL 8.0 made utf8mb4_0900_ai_ci the default collation for utf8mb4, and its ID is 255.

Older drivers carry a hardcoded lookup table of collation IDs. That table ends before 255. So when the driver reads the field metadata, it finds an ID it has never seen and gives up.

You'll typically hit it in these situations:

An old Java app using a legacy mysql-connector-java 5.1.x jar, pointed at a fresh MySQL 8 server
A PHP 7.x build from before mysqlnd learned about the new collations
A Docker setup where you bumped the image from mysql:5.7 to mysql:8 and changed nothing else

To reproduce it, take any old client, connect to a default MySQL 8 install, and run SELECT on a table created with default settings. It fails on the first string column.

Error variations you might see instead

The same root cause shows up with different wording depending on the client:

Connector/J, at connect time: Unknown initial character set index '255' received from server. Initial client character set can be forced via the 'characterEncoding' property.
Connector/J, at query time: Unknown character set index for field '255' received from server.
PHP mysqlnd: Server sent charset (255) unknown to the client. Please, report to the developers

Occasionally the number is something else, like 224 or 246, on very old drivers. The fix is the same.

Step 1: Confirm the server is sending collation 255

SHOW VARIABLES LIKE 'collation_%';
SHOW VARIABLES LIKE 'character_set_server';

If collation_server or collation_database shows utf8mb4_0900_ai_ci, you've found the source. You can confirm the ID mapping directly:

SELECT ID, COLLATION_NAME
FROM information_schema.COLLATIONS
WHERE ID = 255;

Step 2: Upgrade the MySQL driver (the real fix)

This is the fix I'd go for first. Changing collations is a workaround; a current driver simply understands ID 255.

For Java with Maven, replace the old mysql:mysql-connector-java artifact with the current one. If you're on Spring Boot, leave the version out and let Boot manage it:

<dependency>
    <groupId>com.mysql</groupId>
    <artifactId>mysql-connector-j</artifactId>
    <scope>runtime</scope>
</dependency>

Gradle equivalent:

runtimeOnly 'com.mysql:mysql-connector-j'

Not on Spring Boot? Pick the latest version from Maven Central and pin it. Also update the driver class if your config still says com.mysql.jdbc.Driver; the current one is com.mysql.cj.jdbc.Driver. If Spring then complains about the datasource, see this fix for BeanCreationException with database type NONE on MySQL.

For PHP, check your version and mysqlnd build:

php -v
php -i | grep -i mysqlnd

On Windows (XAMPP), use php -i | findstr mysqlnd. If you're on an old PHP 7.x release, upgrading PHP is the clean fix. Current PHP versions handle MySQL 8 collations without any extra config.

Step 3: If you can't upgrade, change the server default collation

Sometimes the client is a vendor app or a legacy service you can't touch. In that case, make the server stop sending 255.

Edit my.cnf (often /etc/mysql/my.cnf or /etc/mysql/mysql.conf.d/mysqld.cnf on Linux, my.ini on Windows):

[mysqld]
character-set-server=utf8mb4
collation-server=utf8mb4_unicode_ci

Restart MySQL:

sudo systemctl restart mysql

For Docker Compose, pass the flags on the command line instead:

services:
  db:
    image: mysql:8
    command: --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci

Gotcha: this only changes defaults for new objects. Tables you already created keep utf8mb4_0900_ai_ci, and their columns can still report 255. That's why most people who "fixed the config" still see the error. Do Step 4.

Step 4: Convert existing tables away from utf8mb4_0900_ai_ci

Find the affected tables:

SELECT TABLE_NAME, TABLE_COLLATION
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_db'
  AND TABLE_COLLATION = 'utf8mb4_0900_ai_ci';

Change the database default, then generate the ALTER statements instead of typing them by hand:

ALTER DATABASE your_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

SELECT CONCAT('ALTER TABLE `', TABLE_NAME,
              '` CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;')
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_db'
  AND TABLE_COLLATION = 'utf8mb4_0900_ai_ci';

Copy the output and run it. Back up first. CONVERT TO rebuilds each table, which takes time and locks on large tables, so don't do it on production at noon. The two collations also compare some characters differently, so a unique index can occasionally throw a duplicate-key error during conversion. Test on a copy.

Step 5: Set the charset explicitly in your connection settings

Pin the connection collation so the client and server agree from the first handshake.

JDBC URL:

jdbc:mysql://localhost:3306/your_db?characterEncoding=UTF-8&connectionCollation=utf8mb4_unicode_ci

Laravel, in config/database.php under the mysql connection:

'charset' => 'utf8mb4',
'collation' => 'utf8mb4_unicode_ci',

Laravel already defaults to these, but check that nothing in .env or a custom connection overrides them. If your connection parameters are confusing in plain PHP, this breakdown of the host parameter in mysqli_connect() covers the basics.

One opinion: adding characterEncoding=UTF-8 alone to an old driver is a weak fix. It can get you past the "initial" variant at connect time, but the "for field" variant comes from table metadata, so it often comes straight back on the first query.

Step 6: Verify the fix

Check that no columns still use the 0900 collation:

SELECT TABLE_NAME, COLUMN_NAME, COLLATION_NAME
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'your_db'
  AND COLLATION_NAME = 'utf8mb4_0900_ai_ci';

You want Empty set. Then restart your app and run the query that failed before. If you're on Laravel, a quick php artisan migrate:status hits the database and is a fast smoke test. If seeding breaks after the collation change, this guide on migrate:fresh --seed not seeding into MySQL may help.

For future migrations, keep the collation consistent so new tables don't drift back to the server default. If you'd rather have someone check your setup directly, you can contact HeadsNTail.

FAQ

What is character set index 255 in MySQL?

It's the numeric ID of the utf8mb4_0900_ai_ci collation, the default for utf8mb4 in MySQL 8.0. Drivers written before MySQL 8 don't have it in their lookup table, which is why they reject it.

Why did this error start after upgrading to MySQL 8?

MySQL 5.7 defaulted to collations your old driver already knew. MySQL 8 changed the default to utf8mb4_0900_ai_ci, so any table created on the new server, or imported without an explicit collation, now sends ID 255 to the client.

Is utf8mb4_unicode_ci worse than utf8mb4_0900_ai_ci?

utf8mb4_0900_ai_ci follows a newer Unicode collation standard, so sorting and comparison can be more accurate for some languages. For most English or mixed-language web apps, utf8mb4_unicode_ci works fine. Still, upgrading the driver and keeping the MySQL 8 default is the better long-term choice.

Does adding characterEncoding=UTF-8 to the JDBC URL fix it?

Sometimes, for the "Unknown initial character set index" variant raised at connect time. It usually doesn't fix the "for field" variant, because that ID comes from the column metadata. Upgrade the connector or convert the tables.

If you see "unknown character set index for field received from server" again later, check whether a new table was created with the server default, then rerun the Step 6 query to find it.

Originally published at headsntail.com. Free tools for PHP, Laravel and cPanel work: headsntail.com/tools.

Cloudflare JS Challenge Is Breaking My SPA: Laravel Fix

Faizan — Sun, 18 Oct 2026 11:41:23 +0000

By the end of this, your Laravel SPA will handle Cloudflare challenges instead of crashing on them, and the fix takes about 30 minutes. If your bug report says "a Cloudflare JS challenge is breaking my SPA", the problem isn't in your Vue or Laravel code.

What changed is how Cloudflare describes and handles these challenges. Its docs now list the old JS Challenge as a Non-Interactive Challenge and point SPA owners to Turnstile pre-clearance for fetch and XHR calls. I couldn't confirm an exact date for either change, so go by the labels your dashboard shows.

Short answer: Cloudflare challenges are HTML pages that need a full browser navigation to run. When one lands on an axios or fetch call, your SPA gets a 403 with a cf-mitigated: challenge header and HTML instead of JSON. Fix it by excluding API routes from challenge rules, reloading the page when that header appears, or using Turnstile pre-clearance.

Why the Cloudflare JS challenge is breaking my SPA

I'll use one example throughout. You have a Laravel + Vue storefront at shop.example.com. The product list loads from /api/products with axios, and you have a WAF custom rule that challenges traffic from outside your main market.

Here's the sequence that breaks it:

A visitor opens shop.example.com. That's a normal page load, so the browser shows the challenge, passes it, and Cloudflare sets a cf_clearance cookie.
The SPA works. Every axios call sends the cookie and gets through.
The cookie expires (its lifetime is the zone's Challenge Passage setting), or a rule matches the API path more strictly than the page.
The next call to /api/products gets challenged. Cloudflare returns an HTML challenge page with a 403.

A browser can run a challenge page when it navigates to it. It can't run one that arrives as the body of an XHR or fetch response. Your JavaScript just receives a string of HTML it has no use for.

That's also why it works fine on your machine. There's no Cloudflare in front of php artisan serve.

What this means for PHP/web developers

The first thing to accept: Laravel never sees these requests. Cloudflare answers them at the edge. Nothing shows up in storage/logs/laravel.log, and no middleware or exception handler can catch them. The fix lives in Cloudflare's settings or in your frontend.

Reproduce the 403 cf-mitigated: challenge response

You don't need to wait for a real visitor to hit it.

In Cloudflare, add a temporary custom rule with action Managed Challenge and this expression (use your own IP):

(ip.src eq 203.0.113.10 and starts_with(http.request.uri.path, "/api/"))

Open the site, then delete the cf_clearance cookie in DevTools (Application tab, Cookies).
Trigger an API call and open the request in the Network tab.

You should see:

HTTP/2 403
content-type: text/html; charset=UTF-8
cf-mitigated: challenge
server: cloudflare

cf-mitigated: challenge is the header Cloudflare documents for detecting challenged responses in fetch and XHR calls. It's what your fix will check for.

Why you see "Unexpected token '<'" instead of a challenge

If you use fetch() and call response.json() without checking the status, the console shows:

SyntaxError: Unexpected token '<', "<!DOCTYPE "... is not valid JSON

With axios you usually get a rejected promise with status: 403 and an HTML string in error.response.data. Different symptom, same cause.

The cross-origin variation

If your API lives on another hostname, say api.example.com, you may only see a CORS error. As far as I can tell, that's because the challenge response comes from Cloudflare, not Laravel, so the headers from your config/cors.php aren't on it. The browser blocks the response before your code can read cf-mitigated. Same-origin APIs avoid this, which is one more reason Sanctum's SPA setup keeps things on one domain.

The Inertia variation

Inertia apps get hit on regular page routes, not just /api. After the first load, every Inertia visit is an XHR. A challenged visit shows the challenge HTML in Inertia's modal for non-Inertia responses, or just fails. Excluding /api/ from your rule won't help here.

Should you act now? Fixes in the order I'd try them

Check Security > Events in Cloudflare (the menu name may differ on your plan) and filter by your API path. If you see challenge actions on /api/ or on Inertia routes, act now. If you don't, I'd still add Fix 2. It's a few lines and stops a confusing failure later.

Fix 1: Stop challenging your API routes

This is the standard approach. Challenge HTML page loads, where a browser can actually solve the challenge, and protect the API another way (Sanctum auth, Laravel's throttle middleware, Cloudflare rate limiting).

Edit the challenge rule and add a path exclusion. In our example the rule was:

(ip.src.country ne "SA" and not cf.client.bot)

Change it to:

(ip.src.country ne "SA" and not cf.client.bot and not starts_with(http.request.uri.path, "/api/") and http.request.uri.path ne "/sanctum/csrf-cookie")

If you're on Inertia, a path exclusion won't cover the visits, so go straight to Fix 2.

If the challenge comes from Bot Fight Mode rather than your own rule, a custom rule can't skip it, according to Cloudflare's docs. Your choices there are turning Bot Fight Mode off or moving to a plan with configurable bot rules.

Fix 2: Catch the challenge in axios and reload

When a challenge lands on an API call, the simplest recovery is a full page reload. The browser then gets the challenge as a page, solves it, gets a fresh cf_clearance, and the SPA starts working again.

In resources/js/bootstrap.js:

import axios from 'axios';

window.axios = axios;
window.axios.defaults.headers.common['X-Requested-With'] = 'XMLHttpRequest';

const isChallenge = (response) =>
    response?.status === 403 && response.headers?.['cf-mitigated'] === 'challenge';

window.axios.interceptors.response.use(
    (response) => response,
    (error) => {
        if (isChallenge(error.response)) {
            let last = 0;
            try { last = Number(sessionStorage.getItem('cfReloadAt') || 0); } catch (e) {}

            // Reload at most once every 30 seconds to avoid a reload loop
            if (Date.now() - last > 30000) {
                try { sessionStorage.setItem('cfReloadAt', String(Date.now())); } catch (e) {}
                window.location.reload();
                return new Promise(() => {}); // stop the chain while the page reloads
            }
        }

        return Promise.reject(error);
    }
);

For Inertia, use its invalid event, which fires on non-Inertia responses:

import { router } from '@inertiajs/vue3';

router.on('invalid', (event) => {
    const res = event.detail.response;

    if (res?.status === 403 && res.headers?.['cf-mitigated'] === 'challenge') {
        event.preventDefault();
        window.location.reload();
    }
});

The shape of event.detail.response can differ between Inertia versions, so log it once and check before you rely on it.

The gotcha: a reload only helps if the page URL itself is covered by a challenge of the same level or higher. If your rule challenges /api/* but not the page, the reload passes without a challenge, no new cookie is issued, and the next API call fails again. That's what the 30 second guard is for. If you hit it, fix the rule so it covers pages, or use Fix 3. Also warn your users: a reload loses unsaved form input.

Fix 3: Use Turnstile pre-clearance

Pre-clearance lets a Turnstile widget on your page issue the cf_clearance cookie, so the SPA can get cleared without a reload. You enable it on the widget in the Turnstile dashboard and pick a clearance level. That level must match or exceed your rule: per Cloudflare's docs, a Managed clearance passes Managed and Non-Interactive challenges, but not Interactive ones. The widget's hostname must also belong to the same zone.

Load the script in your Blade layout and add a container:

<div id="cf-turnstile"></div>
<script src="https://challenges.cloudflare.com/turnstile/v0/api.js?render=explicit" async defer></script>

Then retry the request after the widget succeeds:

const getClearance = () =>
    new Promise((resolve, reject) => {
        window.turnstile.render('#cf-turnstile', {
            sitekey: import.meta.env.VITE_TURNSTILE_SITE_KEY,
            callback: (token) => resolve(token),
            'error-callback': () => reject(new Error('Turnstile failed')),
        });
    });

window.axios.interceptors.response.use(
    (response) => response,
    async (error) => {
        const config = error.config;

        if (isChallenge(error.response) && !config._cfRetried) {
            config._cfRetried = true;
            await getClearance();          // sets cf_clearance on success
            return window.axios(config);   // replay the original request
        }

        return Promise.reject(error);
    }
);

Use this instead of the reload interceptor from Fix 2, not alongside it. Cloudflare's docs also say to validate the Turnstile token on your server. If you've done this for reCAPTCHA, it'll look familiar (the token-expiry issues in this reCAPTCHA v3 timeout fix for PHP forms work the same way):

use Illuminate\Support\Facades\Http;

$result = Http::asForm()->post('https://challenges.cloudflare.com/turnstile/v0/siteverify', [
    'secret'   => config('services.turnstile.secret'),
    'response' => $request->input('cf_turnstile_token'),
    'remoteip' => $request->ip(),
])->json();

abort_unless($result['success'] ?? false, 422, 'Bot check failed.');

What doesn't work

Sending Accept: application/json. Cloudflare decides before Laravel sees the request; your headers don't change the challenge.
Raising Challenge Passage. It only delays the next failure.
Skipping the rule when X-Requested-With is present. Anyone can send that header. In my opinion that's as good as having no rule.
Catching it in Laravel's exception handler. The request never reached PHP.

What to watch

Cloudflare renames and reorganizes its security products fairly often. "JS Challenge", "Non-Interactive Challenge" and "Managed Challenge" may show up differently in your dashboard than in older answers online, so check which action your rule actually uses.

Keep an eye on Bot Fight Mode and similar zone-wide toggles. They can start challenging API traffic without anyone adding a rule. I'd also send a small event to your error tracker whenever the interceptor sees cf-mitigated, so you find out from your logs, not your customers.

If your product list was built the way retrieving data from the database with Vue in Laravel describes, every component that calls axios gets this protection once the interceptor is in bootstrap.js.

If you'd like someone to look at your Cloudflare rules and Laravel setup with you, contact HeadsNTail.

FAQ

Why does my Laravel API return 403 only behind Cloudflare?

Cloudflare is answering the request, not Laravel. Look for server: cloudflare and cf-mitigated: challenge in the response headers. If they're there, the 403 came from a challenge or a bot setting, and your Laravel logs will be empty.

Can a Cloudflare challenge be solved inside an AJAX request?

No. A challenge is an HTML page that has to render and run in the browser, and an XHR or fetch call can't do that. You need a full page load or Turnstile pre-clearance.

Why does it work locally but fail in production?

Your local XAMPP or php artisan serve setup has no Cloudflare in front of it, so there's nothing to challenge requests. Test against the live domain, or a staging hostname proxied through Cloudflare.

How long does the cf_clearance cookie last?

It lasts for the Challenge Passage duration configured on your zone. When it expires, the next challenged request fails, which is why SPAs often break after the tab has been open a while.

Should I turn off Bot Fight Mode for my API?

If it's what challenges your API calls and you can't exclude paths from it, yes, or move to a plan where bot rules are configurable. Protect the API with authentication and rate limiting instead.

Next time someone tells you "the Cloudflare JS challenge is breaking my SPA", open the Network tab, look for cf-mitigated: challenge, and start with Fix 1 or Fix 2.

Originally published at headsntail.com. Free tools for PHP, Laravel and cPanel work: headsntail.com/tools.

Setting DNS Server to Use With a Curl Request: Fix

Faizan — Sun, 18 Oct 2026 11:07:09 +0000

Can you tell curl to use a specific DNS server instead of the one configured on your computer or hosting server? Yes, but the method depends on how curl was built and whether you want to change the DNS resolver or connect to a specific IP address.

If you're setting DNS server to use with a curl request, the direct option is --dns-servers, but it only works when curl uses the c-ares resolver. Other builds can use DNS-over-HTTPS with --doh-url. If you already know the destination IP address, --resolve lets you bypass the normal hostname lookup for that request.

This tutorial covers all three methods, including PHP cURL, so you can choose the right approach without changing the DNS settings of your entire server.

Setting DNS server to use with a curl request in 6 steps

By default, curl uses the DNS resolution mechanism provided by its build and operating environment.

On Linux, this may involve the system resolver configuration, such as /etc/resolv.conf or a resolver service managed by the operating system.

On Windows, DNS resolution normally follows the network's configured resolver settings when curl uses the native resolver.

For example:

curl https://example.com

Before curl can connect to example.com, it generally needs to determine the destination IP address.

The normal request flow looks like this:

curl https://example.com
         |
         v
DNS lookup
         |
         v
System-configured resolver
         |
         v
IP address returned
         |
         v
TCP/TLS connection
         |
         v
HTTPS response

Sometimes the system resolver is unavailable, returns an unexpected address, or cannot resolve an internal hostname.

In those cases, you may want a different DNS resolver for one request rather than modifying the server's network configuration.

Step 1: Confirm whether the problem is DNS resolution

First, reproduce the request using verbose output.

Run:

curl -v https://example.com/

The -v option displays connection details, including hostname resolution and the address curl attempts to contact.

A successful lookup may produce output similar to:

* Host example.com:443 was resolved.
* IPv4: ...
*   Trying ...
* Connected to example.com

The exact messages depend on the installed curl version and network configuration.

If DNS resolution fails, you may see:

curl: (6) Could not resolve host: example.com

This is curl error 6, meaning the destination hostname couldn't be resolved.

You can reproduce this type of failure with a deliberately invalid hostname:

curl -v https://missing.example.invalid/

The .invalid domain is reserved for names that should not resolve through public DNS.

If curl is using a proxy, however, the error may concern the proxy instead of the destination.

For example:

curl: (5) Could not resolve proxy

That's a different problem.

What to check before changing DNS:

Does the hostname actually exist?
Is the DNS server reachable from your machine?
Is curl using an HTTP or SOCKS proxy?
Does the same hostname resolve through another DNS resolver?

You can compare public DNS responses using:

nslookup example.com 1.1.1.1

This asks Cloudflare's public DNS resolver to look up example.com.

If that succeeds while curl reports a resolution failure, the system resolver or curl's network path deserves closer investigation.

A successful nslookup doesn't automatically mean curl can reach the website. DNS lookup and HTTPS connectivity are separate operations.

Step 2: Use --dns-servers to select a specific DNS resolver

The most direct curl option is:

curl --dns-servers 1.1.1.1 https://example.com/

This tells a compatible curl build to use 1.1.1.1 for DNS resolution instead of the system's default resolver.

You can also provide multiple DNS servers:

curl --dns-servers 1.1.1.1,1.0.0.1 https://example.com/

Or specify a DNS port:

curl --dns-servers 1.1.1.1:53 https://example.com/

Port 53 is the normal port for conventional DNS queries.

The limitation is that --dns-servers requires curl to be built with c-ares support.

It isn't available in every curl installation.

Check whether curl supports c-ares

Run:

curl -V

Look at the version information.

A c-ares-enabled build typically identifies c-ares in its version or resolver information.

Don't assume the presence of AsynchDNS in the features list proves c-ares support. Curl can also perform asynchronous DNS resolution using other backends.

If your build doesn't support the option, trying --dns-servers may return an error indicating that the installed libcurl doesn't support it.

The complete option requirements are documented in the official curl DNS server documentation.

On Windows PowerShell, explicitly use:

curl.exe -V

Using curl.exe avoids confusion with the curl alias found in some Windows PowerShell environments.

What to expect: If your curl build supports c-ares and the DNS server is reachable, curl resolves example.com through the requested resolver and proceeds with the HTTPS connection.

If your curl build doesn't support c-ares, move to the next step instead of repeatedly changing DNS addresses.

Step 3: Use DNS-over-HTTPS when --dns-servers isn't supported

A practical alternative is DNS-over-HTTPS, usually called DoH.

Instead of sending conventional DNS queries to a resolver over port 53, curl sends DNS queries through an HTTPS endpoint.

Curl provides the following option:

curl --doh-url https://cloudflare-dns.com/dns-query https://example.com/

The URL:

https://cloudflare-dns.com/dns-query

is Cloudflare's documented DNS-over-HTTPS endpoint.

This instructs curl to use that DoH service when resolving the destination hostname.

For troubleshooting, add verbose output:

curl -v \
  --doh-url https://cloudflare-dns.com/dns-query \
  https://example.com/

The backslashes shown above are line continuations for Unix-like shells. If you're using Windows PowerShell, put the command on one line:

curl.exe -v --doh-url https://cloudflare-dns.com/dns-query https://example.com/

Your curl installation must support the --doh-url option and the required HTTPS functionality.

What if curl cannot resolve the DoH server itself?

There's a detail that often gets missed.

Before curl can ask cloudflare-dns.com to resolve example.com, it must first connect to the DoH service.

If the configured DoH service uses a hostname, its initial hostname lookup normally uses the regular resolver.

That creates a bootstrap problem when your system DNS is completely unavailable.

You can supply the DoH server's known IP address:

curl -v \
  --resolve cloudflare-dns.com:443:1.1.1.1 \
  --doh-url https://cloudflare-dns.com/dns-query \
  https://example.com/

Here, 1.1.1.1 is a documented Cloudflare resolver address.

The --resolve option provides the address for the DoH hostname, while --doh-url tells curl where to perform the destination hostname lookup.

This is useful when conventional DNS is broken but HTTPS connectivity to the DoH service is available.

Important: Don't disable TLS certificate verification to make DNS troubleshooting easier. A certificate failure is a separate issue and should be investigated rather than bypassed.

Step 4: Use --resolve to connect to a specific IP address

Sometimes you don't actually need to select another DNS server.

You already know the destination IP address and simply want curl to connect there.

For that situation, use:

--resolve hostname:port:ip-address

For example, to test the known Cloudflare DoH hostname at its documented resolver address:

curl -v \
  --resolve cloudflare-dns.com:443:1.1.1.1 \
  https://cloudflare-dns.com/dns-query

The DoH endpoint may return an HTTP error because this request doesn't contain a DNS query. That's fine for this particular connection test. Look for successful connection and TLS verification in the verbose output.

The significant part is:

--resolve cloudflare-dns.com:443:1.1.1.1

Curl uses the specified IP address for that hostname and port.

This differs from --dns-servers.

The --dns-servers option selects a resolver to answer DNS queries.

The --resolve option supplies an address directly, avoiding the usual DNS lookup for that hostname and port.

Why --resolve is better than changing the Host header

You might be tempted to connect to an IP address and manually set the HTTP Host header.

For HTTPS, that isn't always sufficient.

TLS uses the requested hostname for server name indication and certificate verification.

Keeping the original hostname in the URL while overriding the connection address is the cleaner approach.

It's especially useful when:

Testing a website before DNS records are updated.
Checking a new hosting server.
Comparing responses from two web servers.
Investigating whether a DNS record points to the wrong address.

For another example of separating connection problems from protocol errors, see our guide to fixing curl error 35 and SSL wrong version number on Nginx.

One warning: --resolve isn't a general-purpose replacement for DNS.

It only applies to the hostname and port you specify. Other hostnames, including those used during redirects, may still need normal resolution.

Step 5: Set a custom DNS server in PHP cURL

If you're running PHP on a hosting server, you may want the same behavior inside a PHP script.

PHP's cURL extension exposes several libcurl options, including CURLOPT_DNS_SERVERS when the installed PHP/libcurl combination supports it.

Create a file named:

dns-test.php

Add:

<?php

$url = 'https://example.com/';

$ch = curl_init($url);

if ($ch === false) {
    throw new RuntimeException(
        'Unable to initialize cURL.'
    );
}

if (!defined('CURLOPT_DNS_SERVERS')) {
    curl_close($ch);

    throw new RuntimeException(
        'CURLOPT_DNS_SERVERS is not available.'
    );
}

$dnsConfigured = curl_setopt(
    $ch,
    CURLOPT_DNS_SERVERS,
    '1.1.1.1'
);

if (!$dnsConfigured) {
    curl_close($ch);

    throw new RuntimeException(
        'This libcurl build cannot set custom DNS servers.'
    );
}

curl_setopt_array($ch, [
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_CONNECTTIMEOUT => 10,
    CURLOPT_TIMEOUT => 30,
]);

$response = curl_exec($ch);

if ($response === false) {
    echo 'cURL Error: ' . curl_error($ch);
} else {
    echo 'HTTP Status: ' .
        curl_getinfo($ch, CURLINFO_HTTP_CODE);
}

curl_close($ch);

Run:

php dns-test.php

This example only works when your PHP cURL extension and underlying libcurl library support the DNS server option.

The PHP constant being defined doesn't guarantee that libcurl was built with c-ares.

A failed curl_setopt() call can also produce a PHP warning, depending on the installed extension.

Check the return value rather than assuming the DNS option was applied.

Alternative: Use CURLOPT_RESOLVE in PHP

When you know a hostname's IP address, you can use CURLOPT_RESOLVE instead.

Here's a complete connection test:

<?php

$ch = curl_init('https://cloudflare-dns.com/dns-query');

curl_setopt_array($ch, [
    CURLOPT_RESOLVE => [
        'cloudflare-dns.com:443:1.1.1.1',
    ],
    CURLOPT_RETURNTRANSFER => true,
    CURLOPT_CONNECTTIMEOUT => 10,
    CURLOPT_TIMEOUT => 30,
]);

$response = curl_exec($ch);

if ($response === false) {
    echo 'Error: ' . curl_error($ch);
} else {
    echo 'Connected successfully. HTTP status: ' .
        curl_getinfo($ch, CURLINFO_HTTP_CODE);
}

curl_close($ch);

Again, a non-200 HTTP status from this DNS service is possible because we're testing connectivity without submitting a DNS question.

For an ordinary application endpoint, replace the URL and resolve entry with the actual destination hostname and verified IP address.

This method doesn't require the c-ares DNS resolver backend.

For Laravel developers, the underlying database host concept is similar: the hostname determines where a connection should go. Our explanation of host values in MySQL connections covers that distinction in more detail.

Step 6: Check proxies, DNS caches, and server configuration

If custom DNS settings appear to make no difference, check whether curl is actually resolving the target hostname locally.

Check for a proxy

Run:

curl -v https://example.com/

Look for verbose messages showing proxy environment variables or a proxy connection.

For a direct-connect comparison, run:

curl -v --noproxy '*' https://example.com/

The --noproxy '*' option disables proxy use for the request.

If an HTTP proxy resolves the destination hostname itself, changing curl's local DNS resolver may not affect that destination lookup.

SOCKS proxies can behave differently depending on the selected protocol.

For example:

socks5://

typically means the client resolves the destination hostname locally.

But:

socks5h://

requests hostname resolution through the SOCKS proxy.

That difference matters when troubleshooting DNS.

Check the operating system resolver

On Linux systems using systemd-resolved, try:

resolvectl status

You can also inspect:

cat /etc/resolv.conf

On Windows PowerShell:

Get-DnsClientServerAddress

These commands help identify the resolver settings associated with the operating system.

Don't immediately edit /etc/resolv.conf on a managed server. NetworkManager, systemd-resolved, a container runtime, or hosting management software may regenerate it.

Changing the server's DNS configuration can affect other applications.

For a one-request test, I would use --doh-url or --resolve before modifying system-wide DNS settings.

Check whether DNS caching is involved

Curl can cache resolved addresses during a running libcurl session.

For short command-line tests, starting a new curl process is a simple way to avoid reusing that process's existing DNS cache.

Long-running PHP applications may reuse handles or connection pools, so cached resolution can become relevant there.

Also remember that web servers and reverse proxies can have their own DNS behavior.

Changing curl's resolver doesn't update a domain's authoritative DNS records, and it doesn't guarantee that every other application on the server will use the same resolver.

Verify that curl is using the intended DNS method

After applying your chosen method, run a verbose request again.

For a compatible c-ares build:

curl -v \
  --dns-servers 1.1.1.1 \
  https://example.com/

For DNS-over-HTTPS:

curl -v \
  --doh-url https://cloudflare-dns.com/dns-query \
  https://example.com/

For the DoH service with a fixed bootstrap address:

curl -v \
  --resolve cloudflare-dns.com:443:1.1.1.1 \
  --doh-url https://cloudflare-dns.com/dns-query \
  https://example.com/

Look for successful name resolution, the intended connection address, a completed TLS handshake, and an HTTP response.

A successful HTTP request confirms that the connection worked. It doesn't, by itself, prove which DNS server answered the lookup.

For that, use curl's resolver debug output where supported or inspect DNS traffic on the machine. With DoH, the DNS exchange is encrypted, so packet inspection won't expose the DNS question without additional instrumentation.

You can also try an alternate DNS service to compare results.

Keep in mind that public resolvers may return different answers because of DNS caching, geographic routing, or domain-specific policies.

FAQ

Can I specify a DNS server directly in a curl command?

Yes, if curl was built with c-ares support.

For example:

curl --dns-servers 1.1.1.1 https://example.com/

If your installed curl doesn't support that option, use a supported DNS-over-HTTPS endpoint with --doh-url or supply a known destination address with --resolve.

Why does curl say "Could not resolve host" even though the website works in my browser?

The browser and curl may use different DNS mechanisms, cached records, or proxy settings.

Some browsers can use their own DNS-over-HTTPS configuration, while curl may rely on the operating system resolver.

Use curl -v and compare the results with nslookup to identify where hostname resolution is failing.

Does CURLOPT_DNS_SERVERS work on every PHP hosting server?

No. The option depends on the libcurl library that PHP uses, and selecting custom conventional DNS servers requires the c-ares resolver backend.

Some shared hosting environments don't provide that capability.

If it isn't available, consider a supported DoH option, CURLOPT_RESOLVE for a known address, or an approved server-level DNS change.

What's the difference between --dns-servers and --resolve in curl?

--dns-servers tells curl which DNS server should resolve hostnames.

--resolve provides a specific IP address for a hostname and port, bypassing the normal DNS lookup for that entry.

Use --dns-servers when you want an alternate resolver. Use --resolve when you already know the destination address and need to test that specific server.

Can I use Google or Cloudflare DNS without changing my server settings?

Yes, provided your curl build and network environment support the chosen method.

For Cloudflare, a compatible c-ares build can use --dns-servers 1.1.1.1. Alternatively, a DoH-capable build can use Cloudflare's HTTPS DNS endpoint.

For Google's public DNS service, the conventional resolver addresses include 8.8.8.8 and 8.8.4.4. Select a resolver that your network policy permits and that supports your application's requirements.

If you need help diagnosing a hosting-specific DNS or PHP cURL configuration, contact HeadsNTail with the curl version information and the relevant error output.

The next step after setting dns server to use with a curl request is to test the same URL with both your default resolver and the selected alternative, then keep the smallest configuration change that fixes the actual problem.

Originally published at headsntail.com. Free tools for PHP, Laravel and cPanel work: headsntail.com/tools.

How to Retrieve Data From Database Using Vue in Laravel

Faizan — Sun, 18 Oct 2026 09:15:16 +0000

HNT-START
TITLE: How to Retrieve Data From Database Using Vue in Laravel
SLUG: how-to-retrieve-data-from-database-using-vue
EXCERPT: Learn how to fetch MySQL records in Laravel using Vue 3, Eloquent, JSON routes, and the Fetch API, with working code and fixes for common errors.

CATEGORY: Laravel

Your Vue component shows an empty list even though your Laravel database contains records. You can fix this by creating a Laravel JSON endpoint, fetching its response with Vue, and displaying the results using v-for.

If you're searching for how to retrieve data from database using vue, the correct approach is to let Laravel handle the database connection and send the results to Vue as JSON. Vue uses fetch() or Axios to request that data, stores it in a reactive variable, and updates the page automatically.

We'll build a working product listing using Laravel, MySQL, Vue 3, and Vite. The final page will load product names and prices directly from your database, with proper loading and error handling.

How to retrieve data from database using Vue in Laravel: 6 steps

Before writing code, understand how Laravel and Vue communicate.

Vue runs in the browser. It cannot directly execute Laravel's Eloquent queries or access your MySQL database securely.

Laravel runs on the server. It reads database records and returns the information that the frontend needs.

The request follows this flow:

User opens /products
        |
        v
Laravel returns Blade page
        |
        v
Vue component loads
        |
        v
fetch('/api/products')
        |
        v
Laravel ProductController
        |
        v
Product::get()
        |
        v
MySQL products table
        |
        v
JSON response
        |
        v
Vue displays products

This separation is important.

You don't put SQL queries inside Vue components, and you don't need to reload the entire page every time the displayed data changes.

For this example, we'll use an existing Laravel application with Vue 3 installed through npm. If Vue isn't installed yet, the setup is included below.

Step 1: Configure the Laravel MySQL database connection

Open your Laravel project's .env file.

Find the database settings and update them:

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=vue_demo
DB_USERNAME=root
DB_PASSWORD=

These values assume a local MySQL development environment.

Change the username and password according to your MySQL configuration. For production applications, use a dedicated database account with appropriate permissions instead of root.

The database must exist before Laravel can create tables inside it.

Open phpMyAdmin or a MySQL command-line session and execute:

CREATE DATABASE IF NOT EXISTS vue_demo;

Now clear Laravel's cached configuration:

php artisan config:clear

If you're using XAMPP, make sure MySQL is running in the XAMPP Control Panel.

You can confirm that MySQL accepts connections by running:

mysql -h 127.0.0.1 -P 3306 -u root -p

Enter the configured MySQL password when prompted.

If the account has no password in your local environment, use the appropriate login settings.

Once connected, run:

SHOW DATABASES;

You should see vue_demo in the results.

If Laravel reports:

SQLSTATE[HY000] [2002] Connection refused

Check whether MySQL is running and whether the port matches your .env configuration.

If you see:

SQLSTATE[HY000] [1045] Access denied for user

Check your credentials and database permissions.

For a closer explanation of local and remote MySQL connections, read our guide to the host parameter in MySQL connections.

What to expect: Laravel now has the connection settings needed to access the vue_demo database.

Step 2: Create the Product model and products table

We'll use a small products table so it's easy to see exactly where the data comes from.

Run this command in your Laravel project directory:

php artisan make:model Product -m

Laravel creates a model:

app/Models/Product.php

And a migration:

database/migrations/xxxx_xx_xx_xxxxxx_create_products_table.php

The timestamp in the migration filename will be different in your project.

Open the migration file and replace its contents with:

<?php

use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\Schema;

return new class extends Migration
{
    public function up(): void
    {
        Schema::create('products', function (Blueprint $table) {
            $table->id();
            $table->string('name');
            $table->decimal('price', 10, 2);
            $table->timestamps();
        });
    }

    public function down(): void
    {
        Schema::dropIfExists('products');
    }
};

This creates a table with the following columns:

id
name
price
created_at
updated_at

The id column is the primary key.

The price column uses decimal(10,2), which is appropriate for storing fixed-precision prices in this example.

Next, open:

app/Models/Product.php

Update it:

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class Product extends Model
{
    protected $fillable = [
        'name',
        'price',
    ];
}

The $fillable property allows these fields to be assigned when using Eloquent's create() method.

Now execute:

php artisan migrate

Laravel should report that the products migration ran successfully.

If you already have a products table, don't run a duplicate table-creation migration. Use your existing table structure or create a migration that changes only the columns you need.

Insert sample records

Open Laravel Tinker:

php artisan tinker

Insert some products:

\App\Models\Product::create([
    'name' => 'Laptop',
    'price' => 2500.00,
]);

\App\Models\Product::create([
    'name' => 'Keyboard',
    'price' => 150.00,
]);

\App\Models\Product::create([
    'name' => 'Mouse',
    'price' => 75.00,
]);

\App\Models\Product::create([
    'name' => 'Monitor',
    'price' => 850.00,
]);

You should see Eloquent model output after each successful insertion.

Exit Tinker:

exit

Check the records in MySQL:

SELECT id, name, price
FROM products
ORDER BY id;

For a new, empty table, the result should look like this:

+----+----------+---------+
| id | name     | price   |
+----+----------+---------+
|  1 | Laptop   | 2500.00 |
|  2 | Keyboard |  150.00 |
|  3 | Mouse    |   75.00 |
|  4 | Monitor  |  850.00 |
+----+----------+---------+

If your table already contained data, the IDs may be different.

What to expect: Four product records are now stored in MySQL and can be retrieved through Laravel.

Step 3: Create a Laravel controller to fetch MySQL records

Vue needs an HTTP endpoint that returns product data.

We'll create that endpoint using a Laravel controller.

Run:

php artisan make:controller ProductController

Open:

app/Http/Controllers/ProductController.php

Replace the contents with:

<?php

namespace App\Http\Controllers;

use App\Models\Product;
use Illuminate\Http\JsonResponse;

class ProductController extends Controller
{
    public function index(): JsonResponse
    {
        $products = Product::query()
            ->select('id', 'name', 'price')
            ->orderBy('id', 'asc')
            ->get();

        return response()->json($products);
    }
}

This is where Laravel retrieves data from MySQL.

Let's examine the query.

Product::query()

Creates an Eloquent query for the products table.

->select('id', 'name', 'price')

Selects only the fields needed by the frontend.

->orderBy('id', 'asc')

Sorts the records by ID.

->get()

Executes the query and retrieves the matching products.

Finally:

return response()->json($products);

Converts the result into a JSON HTTP response.

For this type of application, returning JSON is better than sending generated HTML from the controller. Vue can decide how to display the records without changing the backend response.

There's also no need to return every column from the database.

For example, if your products table later contains internal costs or supplier information, those fields shouldn't automatically become visible to every frontend user.

When working with more complex conditions, our tutorial on selecting SQL columns based on conditions covers the database-query side.

What to expect: Your controller can retrieve the product records and return only the selected fields.

Step 4: Create a Laravel route that Vue can call

Now we need a URL for the controller.

Open:

routes/web.php

Add:

use App\Http\Controllers\ProductController;
use Illuminate\Support\Facades\Route;

Route::get('/api/products', [ProductController::class, 'index']);

Route::view('/products', 'products');

The first route returns JSON:

GET /api/products

The second route displays the page that will contain our Vue component:

GET /products

Why put these routes inside web.php?

For this tutorial, Vue and Laravel use the same origin. A JSON GET route inside web.php is enough, and it works without installing Laravel's optional API routing setup.

If you're building a separate REST API, you can use routes/api.php instead.

In Laravel installations where API routing hasn't been configured, you can enable it using:

php artisan install:api

That command may also install API authentication-related dependencies and generate additional files. It isn't required for this example.

If you define a route in routes/api.php, remember that Laravel normally applies the /api prefix automatically.

For example:

Route::get('/products', [ProductController::class, 'index']);

Would become:

/api/products

Don't accidentally define /api/products inside api.php and end up requesting /api/api/products.

Test the JSON endpoint before writing Vue

Start Laravel:

php artisan serve

Open this URL in your browser:

http://127.0.0.1:8000/api/products

The response should resemble:

[
    {
        "id": 1,
        "name": "Laptop",
        "price": "2500.00"
    },
    {
        "id": 2,
        "name": "Keyboard",
        "price": "150.00"
    },
    {
        "id": 3,
        "name": "Mouse",
        "price": "75.00"
    },
    {
        "id": 4,
        "name": "Monitor",
        "price": "850.00"
    }
]

Notice that price may be returned as a string.

This is normal when MySQL decimal values are serialized through Laravel.

If the endpoint doesn't return records, stop here and investigate the Laravel response.

Don't start changing Vue code to fix a broken controller or database connection.

Step 5: Install Vue 3 and connect it to Laravel Vite

Laravel uses Vite to build frontend assets.

We'll install Vue 3 and its Vite plugin.

From the Laravel project directory, execute:

npm install

Then:

npm install vue

Install the Vue plugin:

npm install --save-dev @vitejs/plugin-vue

Now open:

vite.config.js

For a standard Laravel project with JavaScript and CSS entry points, use:

import { defineConfig } from 'vite';
import laravel from 'laravel-vite-plugin';
import vue from '@vitejs/plugin-vue';

export default defineConfig({
    plugins: [
        laravel({
            input: [
                'resources/css/app.css',
                'resources/js/app.js',
            ],
            refresh: true,
        }),
        vue(),
    ],
});

If the project already has custom Vite plugins or asset paths, preserve them and add Vue support to the existing configuration.

Next, open:

resources/js/app.js

Replace or adjust it with:

import './bootstrap';

import { createApp } from 'vue';
import ProductsList from './components/ProductsList.vue';

createApp(ProductsList).mount('#app');

The createApp() function initializes Vue.

The mount('#app') instruction tells Vue where to render the component.

Later, our Blade page will contain:

<div id="app"></div>

Vue will mount inside that element.

This is a common place where developers get confused.

Laravel Blade and Vue can work together, but they do different jobs.

Blade generates the initial HTML page on the server. Vue runs in the browser after the JavaScript loads.

You don't need to transfer every database record into Blade variables when Vue is already fetching a JSON endpoint.

For projects that mix server-rendered values and JavaScript components, see how to set variables in Laravel Blade templates.

What to expect: Laravel Vite is now configured to compile and load Vue single-file components.

Step 6: Retrieve and display Laravel database records in Vue

Create this folder if it doesn't exist:

resources/js/components

Inside that folder, create:

ProductsList.vue

Add the following code:

<script setup>
import { ref, onMounted } from 'vue';

const products = ref([]);
const loading = ref(false);
const error = ref('');

async function loadProducts() {
    loading.value = true;
    error.value = '';

    try {
        const response = await fetch('/api/products', {
            method: 'GET',
            headers: {
                Accept: 'application/json',
            },
        });

        if (!response.ok) {
            throw new Error(
                `Failed to load products: HTTP ${response.status}`
            );
        }

        const data = await response.json();

        if (!Array.isArray(data)) {
            throw new Error('Unexpected API response format');
        }

        products.value = data;
    } catch (err) {
        error.value = err.message;
    } finally {
        loading.value = false;
    }
}

onMounted(() => {
    loadProducts();
});
</script>

<template>
    <main class="products-page">
        <h1>Products</h1>

        <button
            type="button"
            @click="loadProducts"
            :disabled="loading"
        >
            {{ loading ? 'Loading...' : 'Refresh products' }}
        </button>

        <p v-if="loading">
            Loading products...
        </p>

        <p v-else-if="error">
            {{ error }}
        </p>

        <p v-else-if="products.length === 0">
            No products found.
        </p>

        <table v-else>
            <thead>
                <tr>
                    <th>ID</th>
                    <th>Product name</th>
                    <th>Price</th>
                </tr>
            </thead>

            <tbody>
                <tr
                    v-for="product in products"
                    :key="product.id"
                >
                    <td>{{ product.id }}</td>
                    <td>{{ product.name }}</td>
                    <td>
                        {{ Number(product.price).toFixed(2) }}
                    </td>
                </tr>
            </tbody>
        </table>
    </main>
</template>

<style scoped>
.products-page {
    max-width: 900px;
    margin: 40px auto;
    font-family: Arial, sans-serif;
}

table {
    width: 100%;
    border-collapse: collapse;
    margin-top: 20px;
}

th,
td {
    border: 1px solid #ddd;
    padding: 12px;
    text-align: left;
}

th {
    background: #f5f5f5;
}

button {
    padding: 10px 16px;
    cursor: pointer;
}
</style>

This component does more than simply fetch records.

It handles the initial request, shows a loading state, detects unsuccessful HTTP responses, checks the returned data format, and displays an error if the request fails.

It also includes a refresh button so you can reload products without refreshing the entire Laravel page.

Why ref() matters

Look at:

const products = ref([]);

Vue's ref() creates reactive state.

When this line executes:

products.value = data;

Vue detects the change and updates the table.

You don't need to manually rebuild the HTML or call a DOM update function.

Why onMounted() is used

This code:

onMounted(() => {
    loadProducts();
});

Runs after the component mounts.

It's a natural place to load the initial data for a client-rendered product listing.

Avoid putting the same fetch request in multiple lifecycle hooks unless you specifically need multiple requests.

Otherwise, you may accidentally load the data twice.

Why response.ok should be checked

The Fetch API doesn't automatically reject a promise when a server returns an HTTP error such as 404 or 500.

That's why we check:

if (!response.ok) {
    throw new Error(
        `Failed to load products: HTTP ${response.status}`
    );
}

Without this check, your code could attempt to display an error response as if it contained products.

Why v-for needs a unique key

The table contains:

<tr
    v-for="product in products"
    :key="product.id"
>

The v-for directive repeats the row for each product.

The key helps Vue identify which record belongs to each rendered row when the list changes.

Use a stable database ID rather than the array index when an ID is available.

Create the Laravel Blade page

Now create:

resources/views/products.blade.php

Add:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">

    <meta
        name="viewport"
        content="width=device-width, initial-scale=1"
    >

    <title>Laravel Vue Products</title>

    @vite([
        'resources/css/app.css',
        'resources/js/app.js'
    ])
</head>

<body>

    <div id="app"></div>

</body>
</html>

The Blade file doesn't need to query the database.

It simply provides the HTML document, Vite assets, and mounting element.

Vue takes care of requesting and displaying the products.

Start the frontend development server:

npm run dev

Keep the Laravel development server running in another terminal:

php artisan serve

Now visit:

http://127.0.0.1:8000/products

You should see a table containing the product records from MySQL.

Verify that Vue is fetching real MySQL data

Open the browser's developer tools and switch to the Network tab.

Refresh the products page.

Look for:

GET /api/products

Click the request and inspect its status.

A successful response should show:

Status: 200 OK
Content-Type: application/json

The Response or Preview tab should contain the product records.

Your page should display something similar to:

Products

[Refresh products]

ID   Product name    Price
1    Laptop          2500.00
2    Keyboard         150.00
3    Mouse             75.00
4    Monitor          850.00

To confirm that Vue is displaying live database content rather than hardcoded values, open Tinker:

php artisan tinker

Insert another record:

\App\Models\Product::create([
    'name' => 'USB Cable',
    'price' => 25.00,
]);

Exit Tinker and click the Refresh products button.

The new product should appear.

No changes to the Vue source code are needed.

That confirms the complete connection from MySQL through Laravel to the browser.

Fix Vue showing an empty list when Laravel has records

If the table still doesn't show anything, diagnose the problem from the backend toward the frontend.

That order is faster than changing unrelated Vue settings.

Laravel API returns 404 Not Found

First, check your route:

php artisan route:list --path=api/products

You should see a GET route pointing to ProductController.

If it isn't present, check routes/web.php.

You can also clear route caching:

php artisan route:clear

Make sure the frontend requests the correct path:

fetch('/api/products')

A small mismatch between /api/product and /api/products is enough to return 404.

Vue returns Unexpected token '<', "<!DOCTYPE" is not valid JSON

This error means the response is HTML, not the JSON that response.json() expected.

Common reasons include an incorrect route, a Laravel error page, or a redirect to a login screen.

Open the browser Network tab and inspect the response body.

If it contains an HTML document, find out why the server returned that document.

Don't try to fix the issue by replacing every response.json() call with response.text().

That changes how the response is parsed but doesn't solve the underlying API problem.

API returns an empty array

Suppose /api/products returns:

[]

That means Laravel successfully returned an empty collection.

Check the records directly:

php artisan tinker

Run:

\App\Models\Product::count();

Then:

\App\Models\Product::all();

If the count is zero, your configured database doesn't contain the expected records.

Check DB_DATABASE, the active environment, and any query conditions.

A frequent mistake is inserting records into one database through phpMyAdmin while Laravel is connected to another.

Laravel returns a 500 server error

A 500 response means the server encountered an error while processing the request.

Inspect Laravel's application logs under:

storage/logs/

The actual filename depends on the configured logging channel.

Look for SQL exceptions, missing tables, incorrect model names, or PHP errors.

For example:

SQLSTATE[42S02]: Base table or view not found

Usually means the expected table doesn't exist in the connected database.

Run:

php artisan migrate:status

Check whether the products migration was applied.

Don't assume every 500 error is caused by Vue. The browser is only reporting that Laravel failed to complete the request.

Vue displays nothing and no request is sent

If the Network tab doesn't show /api/products, the Vue component may not be mounting.

Check your app.js import:

import ProductsList from './components/ProductsList.vue';

Check the mounting instruction:

createApp(ProductsList).mount('#app');

Then confirm the Blade view contains:

<div id="app"></div>

Also inspect the browser Console tab for Vite compilation or module-loading errors.

If you're running locally, make sure Vite is running:

npm run dev

For a production build:

npm run build

Deploy the generated frontend assets with the Laravel application.

Fetch works locally but fails because of CORS

Cross-origin errors occur when the browser requests a different origin without the required permissions.

For example:

Vue frontend:
http://localhost:5173

Laravel backend:
http://127.0.0.1:8000

These are different origins.

If you host Vue separately, configure Laravel's CORS settings for the intended frontend origin and use the correct API URL.

For a browser request using credentials, the server also needs appropriate credentials and origin settings.

Don't disable browser security to make the request work.

The setup in this tutorial avoids the issue by serving the Vue page and API endpoint from the same Laravel origin.

The product list doesn't update after adding records

The component loads products when it mounts.

It won't automatically know that a different user added another product to MySQL.

That's expected.

The refresh button calls loadProducts() again and retrieves the latest records.

If you add product creation or editing forms later, call loadProducts() after a successful save.

For applications that need continuous updates, consider polling or a real-time broadcasting approach. Neither is necessary for a basic product listing.

Use pagination when the products table becomes large

The original controller uses:

->get();

That retrieves all matching records.

It's fine for a small example, but retrieving every row can become expensive as the table grows.

Laravel provides pagination through Eloquent.

Update the controller method:

public function index(): JsonResponse
{
    $products = Product::query()
        ->select('id', 'name', 'price')
        ->orderBy('id')
        ->paginate(10);

    return response()->json($products);
}

Now the endpoint returns a paginated response rather than a plain array.

The JSON contains the product records under data, alongside pagination metadata.

You'll need to change the Vue assignment from:

products.value = data;

To:

products.value = data.data;

Because the response structure has changed.

Also remove or adjust the earlier Array.isArray(data) check, since the top-level response is now an object.

For example, the relevant parsing code becomes:

const result = await response.json();

if (!Array.isArray(result.data)) {
    throw new Error('Unexpected pagination response');
}

products.value = result.data;

Laravel also provides metadata such as the current page and last page, which you can use to build pagination controls.

The next page can be requested through:

fetch('/api/products?page=2')

I'd use Laravel's built-in pagination instead of writing manual SQL LIMIT and OFFSET handling for an ordinary product list.

For an existing project with custom routing or database issues, HeadsNTail services is available for hands-on development assistance.

FAQ

Can Vue connect directly to a MySQL database?

No. A browser-based Vue application shouldn't open a direct MySQL connection.

Database credentials and server-side queries belong in Laravel. Vue should communicate with Laravel through an HTTP endpoint that returns only the data the user is authorized to access.

How do I fetch data from Laravel API using Axios in Vue 3?

Install Axios:

npm install axios

Then use it inside a Vue component:

import axios from 'axios';
import { ref, onMounted } from 'vue';

const products = ref([]);

onMounted(async () => {
    try {
        const response = await axios.get('/api/products');
        products.value = response.data;
    } catch (error) {
        console.error('Failed to load products:', error);
    }
});

Axios automatically parses JSON responses in ordinary cases.

The existing Laravel controller doesn't need to change. This example assumes the endpoint returns a plain array, not a paginated response.

How do I display data from a Laravel database in a Vue table?

Fetch the records from a Laravel endpoint and store them in a reactive array.

Then use v-for to generate the table rows:

<tr v-for="product in products" :key="product.id">
    <td>{{ product.name }}</td>
    <td>{{ product.price }}</td>
</tr>

Vue will update the table whenever the reactive array changes.

How do I get a single database record in Vue using Laravel?

Create a Laravel route that accepts a product ID:

Route::get('/api/products/{product}', function (
    \App\Models\Product $product
) {
    return response()->json(
        $product->only(['id', 'name', 'price'])
    );
});

Laravel route model binding retrieves the matching product or returns a 404 response if it doesn't exist.

Fetch the record from Vue:

const response = await fetch('/api/products/1', {
    headers: {
        Accept: 'application/json',
    },
});

if (!response.ok) {
    throw new Error(`HTTP ${response.status}`);
}

const product = await response.json();

For private records, add the appropriate authentication and authorization checks before returning them.

Why is Vue showing an empty array when MySQL has data?

First, open the Laravel API endpoint directly and inspect the JSON.

If Laravel returns [], check the Eloquent query and the database configured in .env. If Laravel returns records but Vue doesn't display them, check the component's response parsing, reactive state, and browser console.

For the next step after learning how to retrieve data from database using vue, add server-side search and pagination, then protect any endpoints that expose private data.

HNT-END

Originally published at headsntail.com. Free tools for PHP, Laravel and cPanel work: headsntail.com/tools.

BeanCreationException: Database Type NONE MySQL Fix

Faizan — Sun, 18 Oct 2026 08:14:36 +0000

You can fix this Spring Boot database startup failure in about 10 minutes by correcting the JDBC configuration and checking that the MySQL driver is available.

The error usually appears as:

org.springframework.beans.factory.BeanCreationException:
Cannot determine embedded database driver class for database type NONE.
If you want an embedded database please put a supported one on the classpath.

A missing spring.datasource.url is the most common configuration mistake.

A missing MySQL JDBC driver can also prevent Spring Boot from creating a working database connection.

Another frequent cause is placing valid database settings in a configuration file or Spring profile that isn't being loaded.

Quick answer: The error beancreationexception: cannot determine embedded database driver class for database type none means Spring Boot couldn't determine which JDBC driver to use while creating its DataSource. Add the MySQL connection URL, username, password, and Connector/J dependency. Then check that the correct application configuration and Spring profile are active.

Quick fix: BeanCreationException: Cannot determine embedded database driver class for database type NONE

Start with the application's database configuration. This resolves the problem when Spring Boot is missing the JDBC connection details.

Step 1: Configure MySQL in application.properties

Open:

src/main/resources/application.properties

Add these settings:

spring.datasource.url=jdbc:mysql://127.0.0.1:3306/appdb
spring.datasource.username=appuser
spring.datasource.password=your_password
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver

Replace:

127.0.0.1 with your MySQL server address.
3306 with the configured MySQL port.
appdb with your existing database name.
appuser and your_password with valid database credentials.

These are example values, not credentials that will work automatically.

For production, keep passwords outside source control and supply them through your deployment's secret or environment configuration.

Spring Boot can normally determine the MySQL driver from a valid JDBC URL. The explicit driver-class-name setting is useful for troubleshooting, but isn't usually required.

The important property is:

spring.datasource.url=jdbc:mysql://127.0.0.1:3306/appdb

Without that URL, Spring Boot may attempt to find an embedded database instead.

This behavior is documented in the Spring Boot SQL database configuration reference.

Step 2: Add the MySQL JDBC dependency

Open your Maven project's pom.xml.

For a Spring Boot project using its supported dependency management, add:

<dependency>
    <groupId>com.mysql</groupId>
    <artifactId>mysql-connector-j</artifactId>
    <scope>runtime</scope>
</dependency>

Place it inside the existing <dependencies> section.

Spring Boot's dependency management supplies the compatible version when your project uses its managed dependency definitions.

If your project doesn't use Spring Boot dependency management, you'll need to specify a Connector/J version compatible with your Java and MySQL setup.

For Gradle projects using Groovy DSL, add this to build.gradle:

dependencies {
    runtimeOnly 'com.mysql:mysql-connector-j'
}

For Gradle Kotlin DSL (build.gradle.kts):

dependencies {
    runtimeOnly("com.mysql:mysql-connector-j")
}

Use the syntax matching your build file. You don't need both.

Step 3: Restart Spring Boot

From the project directory, run:

./mvnw clean spring-boot:run

On Windows PowerShell:

.\mvnw.cmd clean spring-boot:run

These commands assume the project includes the Maven Wrapper and Spring Boot Maven plugin.

For Gradle:

./gradlew bootRun

If the application connects successfully, its startup log should proceed past DataSource initialization.

You may see Hikari connection pool initialization or Hibernate startup messages, depending on the project's dependencies.

If the error changes to Access denied, Unknown database, or Communications link failure, that's useful information. The driver-selection problem may be fixed, and you're now seeing an actual connection problem.

Why Spring Boot cannot determine the embedded database driver

The message sounds like MySQL doesn't support the requested database type. That's not what it means.

NONE is an internal Spring Boot database-type value used in the older error message. It indicates that Spring couldn't identify a supported embedded database during its DataSource configuration.

Spring Boot can automatically configure databases when it has enough information.

For an external MySQL database, it needs a valid JDBC URL and a usable driver.

For an embedded database, it needs an appropriate embedded database dependency, such as H2 or HSQLDB.

When neither path can be configured correctly, DataSource creation fails.

This can happen before the application sends a single SQL query to MySQL.

That's also why changing table definitions, SQL queries, or Hibernate mappings usually won't solve this particular startup error.

Cause 1: Missing spring.datasource.url in application.properties

How to confirm

Inspect:

src/main/resources/application.properties

Look for this exact property:

spring.datasource.url=

If it's missing, empty, or incorrectly named, Spring Boot may not receive the connection URL.

For example, this is not a standard Spring Boot DataSource property:

database.url=jdbc:mysql://127.0.0.1:3306/appdb

Spring Boot won't automatically treat database.url as spring.datasource.url.

How to fix

Use the expected prefix:

spring.datasource.url=jdbc:mysql://127.0.0.1:3306/appdb
spring.datasource.username=appuser
spring.datasource.password=your_password

If you prefer YAML, open:

src/main/resources/application.yml

Then configure:

spring:
  datasource:
    url: jdbc:mysql://127.0.0.1:3306/appdb
    username: appuser
    password: your_password
    driver-class-name: com.mysql.cj.jdbc.Driver

Don't put these settings under spring.jpa or spring.hibernate.

Those sections handle different database-related configuration.

Also check the file location. A file accidentally placed under src/main/resources/static isn't treated as the normal application configuration file.

Cause 2: MySQL JDBC driver not found in the classpath

A correct database URL doesn't help if the MySQL connector isn't available at runtime.

Depending on your Spring Boot version and configuration, the application might report:

Failed to determine a suitable driver class

Or:

Cannot load driver class: com.mysql.cj.jdbc.Driver

These errors are related, but not identical to the original database type NONE message.

How to confirm

For a Maven project using the current Connector/J artifact, run:

./mvnw dependency:tree -Dincludes=com.mysql:mysql-connector-j

You should find a dependency similar to:

com.mysql:mysql-connector-j:jar:...:runtime

The actual version depends on your project.

For Gradle:

./gradlew dependencies --configuration runtimeClasspath

Search the output for mysql-connector-j.

If the driver isn't listed, check the dependency declaration, dependency exclusions, and build configuration.

How to fix

Add the dependency shown in the quick fix, reload the project, and rebuild.

Older Spring Boot applications may use:

<dependency>
    <groupId>mysql</groupId>
    <artifactId>mysql-connector-java</artifactId>
    <scope>runtime</scope>
</dependency>

That's the older Maven artifact name. Don't replace it blindly without checking the project's Spring Boot version and dependency management.

For current MySQL Connector/J releases, the driver class is:

com.mysql.cj.jdbc.Driver

The older class name:

com.mysql.jdbc.Driver

is deprecated in newer Connector/J versions.

MySQL confirms the current driver name in its Connector/J documentation.

My preference is to let Spring Boot manage the connector version whenever possible rather than manually mixing unrelated library versions.

Cause 3: Spring Boot isn't loading your database profile

This one is easy to miss because the configuration can look perfectly correct.

Imagine your database settings live here:

src/main/resources/application-dev.properties

With:

spring.datasource.url=jdbc:mysql://127.0.0.1:3306/appdb
spring.datasource.username=appuser
spring.datasource.password=your_password

But you launch the application without activating dev.

Spring Boot might never apply those properties.

How to confirm

Check the startup log for a message about active profiles.

You might see:

No active profile set, falling back to default profiles

The exact wording varies across Spring Boot versions.

How to fix

Activate your development profile.

With Maven:

./mvnw spring-boot:run -Dspring-boot.run.profiles=dev

Or set the environment variable on Linux or macOS:

SPRING_PROFILES_ACTIVE=dev ./mvnw spring-boot:run

On Windows PowerShell:

$env:SPRING_PROFILES_ACTIVE = "dev"
.\mvnw.cmd spring-boot:run

You can also set the active profile in the base application.properties:

spring.profiles.active=dev

Use that only when selecting the profile in application configuration makes sense for your deployment.

Don't put spring.profiles.active inside application-dev.properties on modern Spring Boot versions. Profile activation belongs in a non-profile-specific configuration source.

One more gotcha: environment variables, command-line arguments, and external configuration files can override packaged configuration.

A correct setting in your source repository doesn't guarantee that's the value the running application receives.

Cause 4: The JDBC URL or MySQL server address is wrong

Once Spring identifies the JDBC driver, the next step is establishing a network connection.

A typical MySQL JDBC URL looks like:

spring.datasource.url=jdbc:mysql://127.0.0.1:3306/appdb

The jdbc:mysql:// prefix matters.

This is not a valid MySQL JDBC URL:

spring.datasource.url=mysql://127.0.0.1:3306/appdb

The second format is missing jdbc:.

Check that MySQL is reachable

Try connecting directly with the MySQL command-line client:

mysql -h 127.0.0.1 -P 3306 -u appuser -p appdb

Enter your password when prompted.

If it works, run:

SELECT 1;

You should get a result containing 1.

If you receive Access denied, investigate credentials and MySQL account permissions.

If you receive Unknown database, confirm that the named database exists.

If you receive a connection error, check that MySQL is running and listening on the expected interface and port.

For another explanation of MySQL host values, see our guide to the host parameter in mysqli_connect(). That's the PHP interface, not JDBC, but the server address and connection troubleshooting concepts overlap.

Important: A MySQL connection failure normally produces a different underlying exception from database type NONE. Don't spend time resetting passwords until Spring Boot can actually select its JDBC driver.

Cause 5: Spring Boot tries to configure a database your application doesn't use

Sometimes the application isn't supposed to connect to MySQL at all.

For example, you create a Spring Boot web service that only handles HTTP requests, but the project includes:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-jpa</artifactId>
</dependency>

Spring Boot sees database-related dependencies and attempts to configure a DataSource.

With no JDBC URL or embedded database available, initialization can fail.

How to confirm

Check pom.xml or build.gradle for dependencies such as:

spring-boot-starter-data-jpa
spring-boot-starter-jdbc

Then check whether your application actually uses JDBC, repositories, JPA entities, or database-backed services.

How to fix

If the dependency was added accidentally, remove it.

If the application genuinely doesn't need a database, you can exclude DataSource auto-configuration:

package com.example.demo;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration;

@SpringBootApplication(
    exclude = {DataSourceAutoConfiguration.class}
)
public class DemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(DemoApplication.class, args);
    }
}

Adjust the package and application class to match your project.

This prevents Spring Boot from automatically creating a DataSource.

Don't use this as a shortcut in a real MySQL/JPA application. Excluding auto-configuration doesn't repair the connection. It may simply replace the original error with missing DataSource, repository, or entity manager errors.

If you actually want an in-memory database for development or tests, add an appropriate embedded database dependency instead, such as H2:

<dependency>
    <groupId>com.h2database</groupId>
    <artifactId>h2</artifactId>
    <scope>runtime</scope>
</dependency>

Only do that when an embedded database is intentional. It isn't a substitute for MySQL.

Cause 6: The app works locally but fails after packaging or deployment

A working IDE launch doesn't prove the deployed application has the same configuration.

The deployed process may use another active profile, missing environment variables, or a package without the expected JDBC dependency.

Check the packaged application

First build the application:

./mvnw clean package

For an executable Spring Boot JAR, inspect its contents:

jar tf target/your-app.jar

Replace your-app.jar with the actual output filename.

Search the listing for the MySQL connector under the packaged libraries, typically within BOOT-INF/lib for an executable Spring Boot JAR using that layout.

Also inspect the packaged configuration under BOOT-INF/classes.

If your project builds a different deployment format, inspect that format instead.

A clean package can also reveal resource-copying mistakes.

For example, the source application.properties might contain a database URL while the copied configuration in target/classes is empty or outdated.

A clean rebuild removes stale build output before packaging.

If MySQL is hosted separately from the application, make sure the JDBC URL uses the hostname reachable from the application's runtime environment. Inside Docker, 127.0.0.1 refers to the container itself, not automatically to the host machine.

If nothing worked: capture the real Spring Boot failure

At this point, stop changing random properties and collect the first meaningful exception.

Spring's top-level BeanCreationException often wraps a more specific failure.

The useful message is frequently near the bottom of the stack trace, following Caused by:.

Enable Spring Boot debug output

For Maven:

./mvnw spring-boot:run -Dspring-boot.run.arguments=--debug

For Gradle:

./gradlew bootRun --args='--debug'

Debug mode shows more information about Spring Boot's auto-configuration decisions.

It can help establish why DataSource auto-configuration was selected and which configuration conditions matched.

Debug output doesn't automatically print every effective database property.

Save the startup log

On Linux or macOS:

./mvnw spring-boot:run > startup.log 2>&1

On Windows PowerShell:

.\mvnw.cmd spring-boot:run *> startup.log

Open startup.log and search for:

Caused by:
DataSourceAutoConfiguration
DataSourceProperties
Failed to determine a suitable driver class
Cannot load driver class
Access denied
Communications link failure

Interpret the first relevant root cause rather than treating every nested exception as a separate failure.

A useful troubleshooting report includes the Spring Boot version, active profile, sanitized JDBC URL, relevant dependency tree, and the first underlying exception.

Remove passwords, tokens, and other secrets before sharing logs or configuration.

For comparison, problems such as Laravel migrations and MySQL seeding failures happen at a different stage. If your Spring application never created its DataSource, investigating SQL inserts or table relationships is premature.

FAQ

Why does Spring Boot say database type NONE when I'm using MySQL?

NONE doesn't refer to a MySQL storage engine or database type. It's part of the older Spring Boot error wording used when an embedded database can't be identified during DataSource initialization.

Check that Spring receives a valid spring.datasource.url and that the required MySQL driver is available.

Is spring.datasource.driver-class-name required for MySQL?

Usually not. Spring Boot can identify the driver from a correctly configured jdbc:mysql:// URL when Connector/J is on the runtime classpath.

You can explicitly set spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver while troubleshooting. The setting won't help if the driver library itself is missing.

Can I fix this by adding H2 instead of MySQL Connector/J?

Only if you intend to use H2 as an embedded database. Adding H2 may allow a separate development or test application to start, but it doesn't configure a connection to your MySQL server.

For a MySQL-backed application, use the MySQL JDBC driver and the correct connection properties.

Why does the application work in the IDE but fail with java -jar?

The IDE and packaged application might not load the same profiles, environment variables, dependencies, or configuration files.

Compare the effective startup settings and inspect the packaged JAR. Don't assume the database driver is included simply because the project compiles successfully.

What's the difference between "Cannot determine embedded database driver class" and "Failed to determine a suitable driver class"?

Both errors concern Spring Boot's ability to configure a JDBC DataSource. The first is associated with older Spring Boot error messages, while newer versions commonly report the second.

The same diagnostic approach applies: check the JDBC URL, available driver, loaded configuration, and active profile before investigating the MySQL server.

If you're still getting beancreationexception: cannot determine embedded database driver class for database type none, gather the sanitized startup log and dependency tree, then use HeadsNTail services if you need hands-on help identifying the remaining configuration issue.

Originally published at headsntail.com. Free tools for PHP, Laravel and cPanel work: headsntail.com/tools.

How to Set Variables in a Laravel Blade Template

Faizan — Sun, 18 Oct 2026 07:29:53 +0000

Need to create a variable inside a Blade template, calculate a value, and display it without getting an Undefined variable error? You can do it directly in Blade, and you don't need to create a controller just for a simple calculation.

Direct answer: Use Blade's @php ... @endphp directive to assign a local PHP variable, then display it with {{ $variable }}. For values calculated from application data, it's usually better to define them in a controller and pass them to the view. Blade supports normal PHP variables, conditional assignments, arrays, and component properties.

1. Create a Blade template to reproduce the undefined variable error

Let's use a simple order summary throughout this tutorial.

We have a product price, a quantity, and a customer name. We want to calculate the total and display it in a Blade view.

Open your Laravel project's routes/web.php file and add:

use Illuminate\Support\Facades\Route;

Route::get('/blade-demo', function () {
    return view('blade-demo', [
        'unitPriceCents' => 2500,
        'quantity' => 2,
        'customerName' => 'Taylor',
    ]);
});

Now create this file:

resources/views/blade-demo.blade.php

Add:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Blade Variables Demo</title>
</head>
<body>
    <h2>Order Summary</h2>

    <p>Customer: {{ $customerName }}</p>
    <p>Quantity: {{ $quantity }}</p>
    <p>Total: {{ $subtotal }}</p>
</body>
</html>

Start the development server from your Laravel project directory:

php artisan serve

Visit:

http://127.0.0.1:8000/blade-demo

Assuming the server uses its default port, Laravel will throw an exception similar to:

ErrorException
Undefined variable $subtotal

Why?

We passed $unitPriceCents and $quantity to the view, but $subtotal was never defined.

Blade doesn't automatically calculate missing variables. It compiles templates into PHP, so undefined PHP variables cause the same kind of problem here.

If your development server can't start, see our guide to fixing php artisan serve when it fails to listen on port 8000.

2. How to set variables in a Laravel Blade template using @php

The simplest fix is Laravel's built-in @php directive.

Replace your template with:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>Blade Variables Demo</title>
</head>
<body>
    @php
        $subtotal = $unitPriceCents * $quantity;
    @endphp

    <h2>Order Summary</h2>

    <p>Customer: {{ $customerName }}</p>
    <p>Quantity: {{ $quantity }}</p>
    <p>Subtotal: ${{ number_format($subtotal / 100, 2) }}</p>
</body>
</html>

Refresh the page.

Expected output:

Order Summary

Customer: Taylor
Quantity: 2
Subtotal: $50.00

That's it. You've successfully declared a variable, assigned a value, and displayed it.

You can assign multiple variables inside the same block:

@php
    $subtotal = $unitPriceCents * $quantity;
    $taxRate = 0.10;
    $tax = (int) round($subtotal * $taxRate);
    $total = $subtotal + $tax;
@endphp

<p>Subtotal: ${{ number_format($subtotal / 100, 2) }}</p>
<p>Tax: ${{ number_format($tax / 100, 2) }}</p>
<p>Total: ${{ number_format($total / 100, 2) }}</p>

The tax rate here is just an example, not an actual tax rule.

My preference: Use @php for small, display-related calculations. Don't put database queries, payment processing, or complicated business rules inside Blade files.

The official Laravel Blade documentation documents @php as the supported way to execute PHP code in a template.

3. Pass variables from a Laravel controller instead

For real applications, calculating the subtotal outside the template is usually cleaner.

You don't have to create a controller to demonstrate this. We can move the calculation into our existing route first.

Open:

routes/web.php

Replace the demo route with:

Route::get('/blade-demo', function () {
    $unitPriceCents = 2500;
    $quantity = 2;

    $subtotal = $unitPriceCents * $quantity;

    return view('blade-demo', [
        'customerName' => 'Taylor',
        'quantity' => $quantity,
        'subtotal' => $subtotal,
    ]);
});

Now remove the previous @php calculation from resources/views/blade-demo.blade.php.

Your view can simply contain:

<h2>Order Summary</h2>

<p>Customer: {{ $customerName }}</p>
<p>Quantity: {{ $quantity }}</p>
<p>Subtotal: ${{ number_format($subtotal / 100, 2) }}</p>

This produces the same output, but the calculation happens before Laravel renders the template.

You can also use PHP's compact() function:

return view('blade-demo', compact(
    'customerName',
    'quantity',
    'subtotal'
));

That version works when all three variables have already been defined.

In a larger application, the same code would normally live inside a controller method.

One thing I'd avoid is loading database records from inside a Blade template. If your project has trouble preparing its database, resolve that separately. Our Laravel migrate:fresh and seeding troubleshooting guide covers one common setup issue.

4. Set conditional variables and default values in Blade

Sometimes a variable depends on a condition.

For example, an order may have an optional discount.

Assuming $subtotal is already available in the view, add:

@php
    $discountCents = $discountCents ?? 0;

    $payableCents = max(0, $subtotal - $discountCents);
@endphp

@if ($discountCents > 0)
    <p>Discount applied</p>
@else
    <p>No discount applied</p>
@endif

<p>
    Amount due:
    ${{ number_format($payableCents / 100, 2) }}
</p>

Here, ?? provides a default value when $discountCents is missing or null.

The max() call prevents a negative displayed amount if the discount exceeds the subtotal.

You can also display a default directly:

<p>Customer: {{ $customerName ?? 'Guest' }}</p>

Or check whether a variable exists:

@isset($customerName)
    <p>Welcome, {{ $customerName }}</p>
@endisset

A common mistake is trying to use {{ }} for assignment:

{{ $subtotal = 5000 }}

PHP can evaluate that assignment, but Blade also prints the result. That's usually not what you want.

Use @php for assignment and {{ }} for output.

Also, keep Blade's automatic HTML escaping enabled when displaying user-supplied data. Don't switch to {!! !!} merely to avoid formatting issues.

5. Pass variables to another Blade file using @include

A variable defined in one template can also be passed to an included view.

Let's move the order total into a reusable partial.

Create:

resources/views/partials/order-total.blade.php

Add:

<p>
    {{ $label }}:
    ${{ number_format($payableCents / 100, 2) }}
</p>

In your main Blade template, after calculating $payableCents, replace the previous total paragraph with:

@include('partials.order-total', [
    'payableCents' => $payableCents,
    'label' => 'Amount due',
])

The partial receives the variables and displays them.

Expected output:

Amount due: $50.00

Blade includes inherit variables available in the parent view, but I prefer passing the important values explicitly. That makes the partial easier to understand and reuse.

Don't rely on changing a variable inside an included file to update the parent template. Pass the value you need into the partial instead.

6. Declare component variables using @props

For reusable UI elements, Blade components are often a better choice than plain includes.

Create this file:

resources/views/components/order-total.blade.php

Add:

@props([
    'payableCents',
    'label' => 'Amount due',
])

<div class="order-total">
    <strong>{{ $label }}</strong>

    <span>
        ${{ number_format($payableCents / 100, 2) }}
    </span>
</div>

The @props directive declares which values the component expects.

Now, in the main template, you can use this component instead of the previous @include:

<x-order-total
    :payable-cents="$payableCents"
    label="Final total"
/>

Notice the colon before payable-cents.

It tells Laravel to evaluate $payableCents as a PHP expression rather than treating it as literal text.

Expected result:

Final total $50.00

The component's label property has a default value, so you can omit it if you want.

For larger Laravel projects, components are useful when the same display logic appears across several pages.

7. Fix Blade variables that still show errors

If you've assigned the variable correctly but Laravel still displays an error, check these cases.

Undefined variable

Undefined variable $subtotal

Confirm the variable exists before the template attempts to read it. Check spelling and capitalization, because $subtotal and $subTotal are different PHP variables.

Trying to use a nonexistent @set directive

Don't assume this syntax works in a standard Laravel installation:

@set('subtotal', 5000)

Laravel doesn't provide a built-in @set directive for this purpose. Some projects register custom directives, but portable Blade templates should use @php.

Changes don't appear after editing Blade

Try clearing the compiled views:

php artisan view:clear

This removes compiled Blade templates so Laravel can compile them again.

It doesn't clear your application's database or cached business data.

If you're actually dealing with stored application cache values, that's a different issue. See our Laravel cache tag retrieval guide for an example of working with cache entries.

Variable works in one template but not another

Check where the variable is created and which view receives it. Passing data to a component is different from declaring a local variable in its parent template.

Don't assume every variable is automatically available across independently rendered components.

Verify your Blade variable assignment works

Return to the example and add this code after $subtotal has been defined:

@php
    $testTotal = $subtotal + 1000;
@endphp

<p>Original: {{ $subtotal }}</p>
<p>After adding 1000 cents: {{ $testTotal }}</p>

Refresh:

http://127.0.0.1:8000/blade-demo

Expected output with the original example values:

Original: 5000
After adding 1000 cents: 6000

If these values appear, the variable assignment is working.

Remove the test code afterward.

For support with Blade templates or Laravel application work, you can contact HeadsNTail.

FAQ

Can I declare a variable directly inside a Laravel Blade file?

Yes. Use @php and @endphp to declare regular PHP variables inside the template. The variables can then be accessed by subsequent expressions in the same view.

Can I assign a variable inside a Blade @if statement?

Yes, but it's usually clearer to assign the value before the conditional block. Use @if to control what gets displayed and @php when you actually need to store a calculated value.

How do I give a Blade variable a default value?

Use PHP's null coalescing operator, such as $name = $name ?? 'Guest';. When you only need a fallback for display, {{ $name ?? 'Guest' }} is simpler and doesn't require an additional assignment.

How do I pass a variable from a controller to Blade?

Return a view with an associative array, such as return view('orders.show', ['total' => $total]);. Inside resources/views/orders/show.blade.php, access it using {{ $total }}. You can also use compact('total') if that variable exists in the controller method.

Why is my Blade variable undefined even after using @php?

The assignment may happen after the variable is accessed, or it may be inside a conditional branch that didn't execute. Check variable spelling and whether the correct view receives the data. If the template appears outdated, run php artisan view:clear.

Next, apply how to set variables in a Laravel Blade template to one real page in your project. Keep display-only calculations in Blade and move data loading or business rules into your application's PHP classes.

Originally published at headsntail.com. Free tools for PHP, Laravel and cPanel work: headsntail.com/tools.

Find the Query from query_id in MySQL (InnoDB)

Faizan — Sun, 18 Oct 2026 06:54:52 +0000

A MySQL deadlock report shows a query ID, but you can't find the SQL statement that caused the problem. You have the thread ID and query ID from SHOW ENGINE INNODB STATUS, yet neither tells you directly what was executed.

Direct answer: To find the query from query_id in mysql, first check whether the SQL statement is still visible in the InnoDB status report or process list. If it has finished, use previously collected Performance Schema history or general query logs. MySQL doesn't provide a standard lookup command that retrieves historical SQL using an InnoDB query ID alone.

Prerequisites before investigating the MySQL query ID

You'll need:

MySQL 8.0 or 8.4 for the examples below. MariaDB has some differences.
Access to the MySQL command-line client, MySQL Workbench, or another SQL client.
The PROCESS privilege to inspect server-wide activity and InnoDB status.
Appropriate SELECT privileges for Performance Schema or log tables.
Administrative privileges if you need to change server logging settings.

The investigation starts with a real kind of InnoDB status entry:

MySQL thread id 1106, query id 1360 localhost 127.0.0.1 test2
---TRANSACTION 0 19491, not started, OS thread id 2960035840

We want to identify the SQL statement associated with query ID 1360.

There's an important distinction:

Identifier	What it represents
`1106`	MySQL connection/thread ID
`1360`	Server query ID shown by InnoDB
`EVENT_ID`	Performance Schema statement event identifier
`Query_ID` in `SHOW PROFILES`	Session profiling identifier

These identifiers aren't interchangeable.

1. Find the query from query_id in MySQL InnoDB status

Start by connecting to MySQL:

mysql -u root -p

Check the server version:

SELECT VERSION(), @@version_comment;

Then capture the current InnoDB status:

SHOW ENGINE INNODB STATUS\G

Look for these sections:

LATEST DETECTED DEADLOCK
TRANSACTIONS
LIST OF TRANSACTIONS FOR EACH SESSION

InnoDB can include the actual SQL statement immediately after the connection and query information.

For example, you might see:

MySQL thread id 1106, query id 1360 localhost root updating
UPDATE orders SET status = 'paid' WHERE id = 25

In that case, you've found the statement without enabling additional logging.

But sometimes the output only contains:

---TRANSACTION 0 19491, not started

That means the transaction shown isn't currently active. It doesn't provide enough information to reconstruct its previous SQL statements.

For a saved report on Linux, run:

mysql -u root -p -e "SHOW ENGINE INNODB STATUS\G" > /tmp/innodb-status.txt

Search the captured text:

grep -n -A 15 "query id 1360" /tmp/innodb-status.txt

The -A 15 option displays 15 lines after the match, where SQL text may appear.

One gotcha: SHOW ENGINE INNODB STATUS is a snapshot, not a complete historical query archive. A newer deadlock can replace the previous deadlock details.

2. Find the SQL query using the MySQL thread ID

The thread ID is usually more useful than the InnoDB query ID.

In our example:

MySQL thread id 1106

Run:

SHOW FULL PROCESSLIST;

This displays connected sessions and their current statements.

You can narrow the search:

SELECT
    ID,
    USER,
    HOST,
    DB,
    COMMAND,
    TIME,
    INFO
FROM information_schema.PROCESSLIST
WHERE ID = 1106\G

The INFO column contains the SQL statement currently associated with that connection, when one is available.

Use SHOW FULL PROCESSLIST instead of SHOW PROCESSLIST if you need the complete statement. The shorter command can truncate the displayed SQL.

If connection 1106 is sleeping, INFO may be NULL. If the connection has closed, its row won't appear at all.

Also, don't confuse the connection ID with the query ID. Searching the process list for 1360 instead of 1106 could identify an entirely different connection.

If you're checking which database the application connected to, our guide to the host parameter in mysqli_connect() explains how PHP chooses its MySQL server.

3. Recover recent statements with Performance Schema

Performance Schema is the preferred built-in option for investigating recent statement execution in modern MySQL.

Check whether it's enabled:

SHOW VARIABLES LIKE 'performance_schema';

If the value is ON, inspect the statement consumers:

SELECT NAME, ENABLED
FROM performance_schema.setup_consumers
WHERE NAME LIKE 'events_statements%';

To inspect the current statement for connection 1106:

SELECT
    t.PROCESSLIST_ID,
    e.EVENT_ID,
    e.EVENT_NAME,
    e.SQL_TEXT
FROM performance_schema.threads AS t
JOIN performance_schema.events_statements_current AS e
    ON e.THREAD_ID = t.THREAD_ID
WHERE t.PROCESSLIST_ID = 1106\G

For recently completed statements, use:

SELECT
    t.PROCESSLIST_ID,
    e.EVENT_ID,
    e.SQL_TEXT
FROM performance_schema.threads AS t
JOIN performance_schema.events_statements_history AS e
    ON e.THREAD_ID = t.THREAD_ID
WHERE t.PROCESSLIST_ID = 1106
ORDER BY e.EVENT_ID DESC
LIMIT 10;

This gives you recent SQL associated with the connection, provided the events were recorded and haven't been discarded.

For a larger, server-wide history, enable its consumer before reproducing the problem:

UPDATE performance_schema.setup_instruments
SET ENABLED = 'YES', TIMED = 'YES'
WHERE NAME LIKE 'statement/%';

UPDATE performance_schema.setup_consumers
SET ENABLED = 'YES'
WHERE NAME IN (
    'events_statements_current',
    'events_statements_history_long'
);

Then examine recent captured statements:

SELECT
    THREAD_ID,
    EVENT_ID,
    SQL_TEXT
FROM performance_schema.events_statements_history_long
WHERE SQL_TEXT IS NOT NULL
ORDER BY THREAD_ID DESC, EVENT_ID DESC
LIMIT 20;

For a known live connection, filter these events by joining to performance_schema.threads, as shown earlier.

There are limitations. Performance Schema history has finite capacity, SQL text may be truncated, and a connection that has already closed might no longer have a thread mapping.

Its EVENT_ID is also not the InnoDB query ID 1360.

See the MySQL Performance Schema documentation for the supported statement-history tables.

4. Enable the MySQL general query log to capture future queries

If the query has already disappeared, the general query log is often the most practical way to investigate a reproducible problem.

The log records statements received by MySQL together with their connection identifiers.

First, save the existing settings:

SHOW GLOBAL VARIABLES
WHERE Variable_name IN ('general_log', 'log_output');

For temporary troubleshooting, enable table logging:

SET GLOBAL log_output = 'TABLE';
SET GLOBAL general_log = 'ON';

If log_output was previously FILE and you need to preserve file logging, use FILE,TABLE instead.

Now reproduce the application problem.

Search for statements belonging to connection 1106:

SELECT
    event_time,
    thread_id,
    command_type,
    CONVERT(argument USING utf8mb4) AS sql_text
FROM mysql.general_log
WHERE thread_id = 1106
  AND command_type = 'Query'
ORDER BY event_time DESC
LIMIT 30;

The output shows the statements received on that connection after logging was enabled.

This doesn't mean the general log stores query ID 1360. It stores the connection ID, timestamp, command type, and statement text. You'll correlate the relevant statement using the thread ID and time of the problem.

General logging can generate substantial data and expose sensitive application values. I'd enable it only for a short diagnostic window, preferably outside peak traffic.

If the investigation exposes an incorrect SQL expression, our guide to selecting multiple columns based on SQL conditions covers a related part of checking query logic.

5. Keep MySQL statement history enabled after restart

Runtime changes to Performance Schema consumers don't necessarily survive a server restart.

For a Linux MySQL installation using the Debian or Ubuntu package layout, a common configuration path is:

/etc/mysql/mysql.conf.d/mysqld.cnf

Other installations may use /etc/my.cnf or another configuration file.

To keep the extended statement-history consumer enabled, add these settings under [mysqld]:

[mysqld]
performance_schema=ON
performance-schema-consumer-events-statements-history-long=ON

If the server requires these changes, restart MySQL during an approved maintenance window:

sudo systemctl restart mysql

Then verify the configuration:

SELECT NAME, ENABLED
FROM performance_schema.setup_consumers
WHERE NAME = 'events_statements_history_long';

The expected value is:

events_statements_history_long | YES

This captures future completed statements. It cannot restore query history that was never recorded.

Verify that query capture works

After enabling monitoring, execute a harmless statement from an application connection:

SELECT CONNECTION_ID();
SELECT 12345 AS query_capture_test;

Keep the connection open.

From another administrative connection, inspect the history:

SELECT
    t.PROCESSLIST_ID,
    e.EVENT_ID,
    e.SQL_TEXT
FROM performance_schema.threads AS t
JOIN performance_schema.events_statements_history_long AS e
    ON e.THREAD_ID = t.THREAD_ID
WHERE e.SQL_TEXT LIKE '%query_capture_test%'
ORDER BY e.EVENT_ID DESC;

You should find the test statement if the consumer is collecting events and the row hasn't been discarded.

For general logging, search mysql.general_log using the connection ID returned by CONNECTION_ID().

Common errors during setup

Access denied when reading Performance Schema

Your MySQL account may lack the necessary permissions.

Check your grants:

SHOW GRANTS FOR CURRENT_USER();

Ask the database administrator for the required read access. Avoid granting broad administrative permissions to application accounts.

Unknown column 'QUERY_ID' in Performance Schema

MySQL's statement event tables use THREAD_ID and EVENT_ID.

They don't provide an InnoDB QUERY_ID column.

Don't try:

SELECT *
FROM performance_schema.events_statements_history_long
WHERE QUERY_ID = 1360;

Instead, use the thread mapping and statement history demonstrated above.

No rows returned from statement history

Check that the required consumers are enabled and that the statements were executed after monitoring started.

History can also be overwritten on a busy server. events_statements_history_long isn't permanent storage.

MariaDB query IDs behave differently

MariaDB exposes a QUERY_ID column in information_schema.PROCESSLIST.

For a still-running query, you can try:

SELECT
    ID,
    QUERY_ID,
    INFO
FROM information_schema.PROCESSLIST
WHERE QUERY_ID = 1360;

This is MariaDB-specific and only helps while the relevant process-list entry remains available.

Don't assume MySQL and MariaDB expose identical diagnostic columns, even if both are accessed using the mysql command-line client.

Rollback: disable temporary query logging

Once you've captured enough evidence, turn off general query logging if you enabled it solely for troubleshooting:

SET GLOBAL general_log = OFF;

Restore the original log_output value you recorded before making changes.

For example, only if the previous value was FILE:

SET GLOBAL log_output = 'FILE';

If general logging was already enabled before your investigation, restore that original state instead of leaving it disabled.

Also revert temporary Performance Schema instrumentation and consumer changes to their recorded previous values.

For persistent changes, remove only the settings you added to the MySQL configuration and restart during maintenance.

Don't truncate or delete diagnostic logs until you've saved the evidence you need.

FAQ

Can I get the exact SQL statement using only a MySQL query ID?

Not reliably. An InnoDB query ID isn't a persistent lookup key for SQL history. You'll need the original status output, an active connection, or previously captured statement logs to identify the query.

What is the difference between thread ID and query ID in MySQL?

The thread ID identifies a MySQL connection. The query ID identifies a query execution in the server's diagnostic context. One connection can execute many statements, so the values represent different things.

Does SHOW PROFILES display the same query ID as InnoDB?

No. SHOW PROFILES uses session profiling IDs, which aren't the same as the query IDs printed by InnoDB. The profiling statements are also deprecated in MySQL, so Performance Schema is the better choice for new monitoring setups.

Can I find a query after the MySQL connection has closed?

Only if the statement was captured somewhere that still retains it, such as the general query log or suitable diagnostic history. A closed connection disappears from the process list, and Performance Schema history isn't guaranteed to survive long enough for later investigation.

Can MySQL automatically save SQL statements involved in deadlocks?

MySQL can record InnoDB deadlock information, including SQL statements available at the time. For ongoing deadlock investigation, innodb_print_all_deadlocks can send details of all detected InnoDB deadlocks to the MySQL error log rather than relying only on the most recent deadlock shown by SHOW ENGINE INNODB STATUS.

If you need hands-on help configuring query diagnostics, you can contact HeadsNTail.

The practical next step when you need to find the query from query_id in mysql is to capture the InnoDB report, record the connection ID, and enable short-term SQL logging before reproducing the issue.

Originally published at headsntail.com. Free tools for PHP, Laravel and cPanel work: headsntail.com/tools.

How to select multiple columns based on a condition in SQL?

Faizan — Sat, 17 Oct 2026 13:08:34 +0000

ERROR 1241 (21000): Operand should contain 1 column(s).

This error often appears when you try to make a SQL CASE expression return multiple columns at once. If you're asking "how to select multiple columns based on a condition in sql?", the first thing to understand is the difference between filtering rows and changing which column values appear in your results. Both are possible, but they require different SQL techniques.

Quick answer: To select multiple columns based on a condition, list the required columns in SELECT and filter matching rows using WHERE. If individual column values should change depending on a condition, use separate CASE expressions for each output column. If the actual number or names of returned columns must change, use separate queries or safely constructed dynamic SQL.

Here's how to implement each approach in MySQL without running into confusing syntax errors.

1. Create a sample table to understand conditional column selection

We'll use an employee table throughout this tutorial.

Imagine you're building an employee management dashboard. Your database stores employee names, departments, salaries, and employment status.

You want to answer questions such as:

Show the names and salaries of active sales employees.
Display different salary columns depending on the department.
Return salary totals for active and inactive employees.
Change the columns displayed when someone selects a different report.

Start by creating a temporary table.

Open MySQL Workbench, phpMyAdmin, or your preferred MySQL client and execute:

DROP TEMPORARY TABLE IF EXISTS demo_employees;

CREATE TEMPORARY TABLE demo_employees (
    employee_id INT PRIMARY KEY,
    full_name VARCHAR(80) NOT NULL,
    department VARCHAR(30) NOT NULL,
    annual_salary DECIMAL(10,2) NOT NULL,
    status VARCHAR(12) NOT NULL
);

Now insert some sample records:

INSERT INTO demo_employees
    (employee_id, full_name, department, annual_salary, status)
VALUES
    (1, 'Ana', 'Sales', 54000.00, 'active'),
    (2, 'Ben', 'Support', 47000.00, 'active'),
    (3, 'Cara', 'Sales', 62000.00, 'inactive'),
    (4, 'Deepak', 'Engineering', 78000.00, 'active'),
    (5, 'Ema', 'Sales', 51000.00, 'active'),
    (6, 'Farah', 'Support', 50000.00, 'inactive');

Confirm that the records exist:

SELECT * FROM demo_employees
ORDER BY employee_id;

You should see six employees across three departments.

We're using a temporary table so the exercise doesn't modify an existing application table. Run all the SQL examples using the same database connection, because MySQL temporary tables disappear when their connection closes.

If you're testing through PHP and the connection fails before your query runs, check the mysqli_connect host parameter explained. Connection problems and SQL syntax problems need different fixes.

2. Select multiple columns using a WHERE condition

This is the simplest solution, and it's usually all you need.

Suppose your dashboard should show only active employees from the Sales department.

You need three output columns:

Employee ID
Employee name
Annual salary

The condition belongs in WHERE, not inside the column list.

SELECT
    employee_id,
    full_name,
    annual_salary
FROM demo_employees
WHERE department = 'Sales'
  AND status = 'active'
ORDER BY employee_id;

Expected result:

employee_id	full_name	annual_salary
1	Ana	54000.00
5	Ema	51000.00

Notice what SQL does here.

SELECT decides which columns appear in the result.

WHERE decides which rows qualify.

These are independent parts of the query. You can return five columns while filtering by a sixth column, even if that sixth column isn't displayed.

For example:

SELECT
    employee_id,
    full_name,
    annual_salary
FROM demo_employees
WHERE status = 'active';

The query filters using status, but doesn't include status in the returned columns.

That's perfectly valid.

Select columns using multiple conditions

You can combine conditions with AND, OR, or IN.

For employees belonging to either Sales or Support:

SELECT
    employee_id,
    full_name,
    department
FROM demo_employees
WHERE department IN ('Sales', 'Support')
  AND status = 'active'
ORDER BY employee_id;

Expected employee IDs: 1, 2, and 5.

You could write the same department condition using OR, but IN is easier to read when you're checking one column against several values.

One mistake I frequently recommend checking for is missing parentheses when mixing AND and OR.

This query may return unexpected results:

SELECT
    employee_id,
    full_name,
    department,
    status
FROM demo_employees
WHERE department = 'Sales'
   OR department = 'Support'
  AND status = 'active';

SQL evaluates AND before OR.

So inactive Sales employees can still appear.

If you want active employees from either department, write:

SELECT
    employee_id,
    full_name,
    department,
    status
FROM demo_employees
WHERE (department = 'Sales'
       OR department = 'Support')
  AND status = 'active';

Better still, use the earlier IN example.

3. How to select multiple columns based on a condition in SQL?

Sometimes filtering rows isn't the real requirement.

You want to return every employee, but show different values depending on their department.

For example:

Sales employees should have their salary in sales_salary.
Support employees should have their salary in support_salary.
Everyone else should have NULL in those columns.

This is where CASE becomes useful.

Use a separate CASE expression for each column

SELECT
    employee_id,
    full_name,

    CASE
        WHEN department = 'Sales'
        THEN annual_salary
        ELSE NULL
    END AS sales_salary,

    CASE
        WHEN department = 'Support'
        THEN annual_salary
        ELSE NULL
    END AS support_salary

FROM demo_employees
ORDER BY employee_id;

Expected result:

employee_id	full_name	sales_salary	support_salary
1	Ana	54000.00	NULL
2	Ben	NULL	47000.00
3	Cara	62000.00	NULL
4	Deepak	NULL	NULL
5	Ema	51000.00	NULL
6	Farah	NULL	50000.00

All six employees appear because there's no WHERE condition.

However, each calculated column displays a salary only when its condition matches.

There's an important detail here: Cara and Farah are inactive, but their salaries still appear because these conditions only check the department.

If inactive employees shouldn't have a salary displayed, extend each condition.

SELECT
    employee_id,
    full_name,

    CASE
        WHEN department = 'Sales'
         AND status = 'active'
        THEN annual_salary
        ELSE NULL
    END AS sales_salary,

    CASE
        WHEN department = 'Support'
         AND status = 'active'
        THEN annual_salary
        ELSE NULL
    END AS support_salary

FROM demo_employees
ORDER BY employee_id;

Now inactive employees receive NULL in both salary columns.

Keep in mind that conditional display isn't a security control. Database permissions and application authorization must still protect sensitive salary data.

Why one CASE cannot return two columns

Here's a common incorrect attempt:

SELECT
    employee_id,

    CASE
        WHEN department = 'Sales'
        THEN (full_name, annual_salary)
        ELSE (department, status)
    END AS details

FROM demo_employees;

This produces an error similar to:

ERROR 1241 (21000): Operand should contain 1 column(s)

The problem isn't the condition.

It's the attempt to return two values from a single CASE expression.

A CASE expression produces one result value. It doesn't expand into multiple output columns.

The correct approach is to use separate expressions:

SELECT
    employee_id,

    CASE
        WHEN department = 'Sales'
        THEN full_name
        ELSE department
    END AS display_label,

    CASE
        WHEN department = 'Sales'
        THEN annual_salary
        ELSE NULL
    END AS display_salary

FROM demo_employees;

Each CASE produces one column.

You can also use MySQL's IF() function for simpler conditions:

SELECT
    employee_id,
    full_name,
    IF(
        department = 'Sales',
        annual_salary,
        NULL
    ) AS sales_salary
FROM demo_employees;

IF() works for a basic true-or-false decision.

I prefer CASE when several conditions are involved because it's easier to extend and is also standard SQL.

The MySQL documentation for CASE expressions explains the supported syntax.

4. Select multiple columns with different WHERE conditions

Another situation is filtering rows based on different combinations of column values.

Suppose the business rule is:

Return active Sales employees, plus Support employees whose annual salary is at least 50000.

The query is:

SELECT
    employee_id,
    full_name,
    department,
    annual_salary,
    status
FROM demo_employees
WHERE
    (department = 'Sales'
     AND status = 'active')

    OR

    (department = 'Support'
     AND annual_salary >= 50000)

ORDER BY employee_id;

Expected matching employees:

employee_id	full_name	department
1	Ana	Sales
5	Ema	Sales
6	Farah	Support

Farah appears even though her status is inactive.

Why?

Because the Support condition checks the salary, not the employment status.

This is intentional for the example, but it's exactly the kind of mistake that can cause incorrect reports in a real application.

If both groups must be active, apply the active condition to the entire expression:

SELECT
    employee_id,
    full_name,
    department,
    annual_salary
FROM demo_employees
WHERE status = 'active'
  AND (
        department = 'Sales'
        OR (
            department = 'Support'
            AND annual_salary >= 50000
        )
      )
ORDER BY employee_id;

Now Farah is excluded.

Don't confuse WHERE with CASE

The distinction is simple.

Use WHERE when a condition should remove entire rows.

Use CASE when a condition should change a value in the returned row.

You can combine both:

SELECT
    employee_id,
    full_name,

    CASE
        WHEN annual_salary >= 60000
        THEN 'High salary'
        ELSE 'Standard salary'
    END AS salary_category

FROM demo_employees
WHERE status = 'active'
ORDER BY employee_id;

Only active employees appear, and each employee receives a calculated salary category.

This pattern is useful for administrative dashboards and filtered reports.

5. Select conditional totals across multiple columns

Sometimes you don't need individual employee records.

You want a report containing several calculated columns based on conditions.

For example, show each department with:

Total number of employees.
Number of active employees.
Number of inactive employees.
Combined salary of active employees.

You can build this using conditional aggregation.

SELECT
    department,

    COUNT(*) AS total_employees,

    SUM(
        CASE
            WHEN status = 'active'
            THEN 1
            ELSE 0
        END
    ) AS active_employees,

    SUM(
        CASE
            WHEN status = 'inactive'
            THEN 1
            ELSE 0
        END
    ) AS inactive_employees,

    SUM(
        CASE
            WHEN status = 'active'
            THEN annual_salary
            ELSE 0
        END
    ) AS active_salary_total

FROM demo_employees
GROUP BY department
ORDER BY department;

Expected result:

department	total_employees	active_employees	inactive_employees	active_salary_total
Engineering	1	1	0	78000.00
Sales	3	2	1	105000.00
Support	2	1	1	47000.00

Here's how this works.

GROUP BY department creates one result row for each department.

COUNT(*) counts all employees in that department.

Each SUM(CASE ...) evaluates a condition for individual rows and adds the matching values.

For the active employee count:

SUM(
    CASE
        WHEN status = 'active'
        THEN 1
        ELSE 0
    END
)

A matching employee contributes 1.

A non-matching employee contributes 0.

For the salary total, the same approach adds salary amounts instead.

Why WHERE can break conditional totals

Don't add:

WHERE status = 'active'

to the aggregation query if you still need inactive employee counts.

That condition removes inactive rows before the grouping and aggregation happen.

Your inactive count would always be zero.

Keep both types of records available and let the individual CASE expressions handle the conditions.

There's another small detail.

Using ELSE 0 makes the total zero when a department has no matching employees. Without ELSE, the expression returns NULL for non-matching records, and SUM() may return NULL if every input is NULL.

That difference matters when your result feeds a chart or financial report.

6. Select different column names dynamically in MySQL

What if your requirement is more specific?

You want the SQL query itself to return different columns depending on a selected report.

For example:

Directory report:

SELECT
    employee_id,
    full_name,
    department
FROM demo_employees;

Payroll report:

SELECT
    employee_id,
    full_name,
    annual_salary
FROM demo_employees;

These queries have different output structures.

A normal CASE expression cannot switch the entire SELECT column list.

You need separate SQL statements or dynamic SQL.

Build a safe dynamic SELECT statement

MySQL supports prepared statements using PREPARE and EXECUTE.

For this example, we'll allow only predefined column lists.

SET @view = 'payroll';

SET @columns = CASE
    WHEN @view = 'payroll'
        THEN 'employee_id, full_name, annual_salary'

    WHEN @view = 'directory'
        THEN 'employee_id, full_name, department'

    ELSE 'employee_id, full_name'
END;

SET @sql = CONCAT(
    'SELECT ',
    @columns,
    ' FROM demo_employees',
    ' WHERE status = ?',
    ' ORDER BY employee_id'
);

SET @status = 'active';

PREPARE employee_stmt FROM @sql;

EXECUTE employee_stmt USING @status;

DEALLOCATE PREPARE employee_stmt;

With @view = 'payroll', the result contains employee IDs, names, and salaries.

Change the variable to:

SET @view = 'directory';

Then rerun the remaining statements.

You'll receive employee IDs, names, and departments instead.

This works because the complete SQL statement is built before MySQL prepares it.

The column list is selected from fixed, trusted alternatives.

Never concatenate an unchecked user-supplied column name directly into SQL.

Prepared statement placeholders such as ? work for values, not SQL identifiers or entire column lists.

If users can choose columns, map their choices to a list of permitted identifiers first.

For most applications, I would keep a small set of predefined queries rather than construct complicated SQL strings. It's easier to review and much harder to misuse.

7. Apply conditional column selection in Laravel

If you're using Laravel, the Query Builder makes ordinary column selection straightforward.

Suppose your actual database contains a permanent employees table with the columns used in our example.

To get active Sales employees:

use Illuminate\Support\Facades\DB;

$employees = DB::table('employees')
    ->select(
        'employee_id',
        'full_name',
        'annual_salary'
    )
    ->where('department', 'Sales')
    ->where('status', 'active')
    ->orderBy('employee_id')
    ->get();

This is the Laravel equivalent of our second step.

Choose different columns for different reports

You can select the column list in PHP before building the query.

use Illuminate\Support\Facades\DB;

$reportType = 'payroll';

$allowedColumns = [
    'directory' => [
        'employee_id',
        'full_name',
        'department',
    ],
    'payroll' => [
        'employee_id',
        'full_name',
        'annual_salary',
    ],
];

$columns = $allowedColumns[$reportType]
    ?? $allowedColumns['directory'];

$employees = DB::table('employees')
    ->select($columns)
    ->where('status', 'active')
    ->orderBy('employee_id')
    ->get();

The important part is the $allowedColumns mapping.

Your application chooses a known column list rather than accepting arbitrary SQL identifiers from a request.

For calculated columns, Laravel can also use raw SQL expressions with bound values.

use Illuminate\Support\Facades\DB;

$department = 'Sales';

$employees = DB::table('employees')
    ->select('employee_id', 'full_name')
    ->selectRaw(
        'CASE
            WHEN department = ?
            THEN annual_salary
            ELSE NULL
         END AS selected_salary',
        [$department]
    )
    ->orderBy('employee_id')
    ->get();

Here, Laravel binds the department value safely.

Don't interpolate untrusted values directly into selectRaw().

And remember that the earlier demo_employees table was temporary. The Laravel examples assume you've created a normal application table with the corresponding fields.

What if the columns come from different tables?

That's a different problem.

Suppose names are stored in employees, but salaries are stored in employee_salaries.

You'll need a JOIN to combine those records.

For a related example, see how to JOIN a second table in CodeIgniter Query Builder.

The principle is the same in Laravel or plain MySQL: a join combines related tables, while WHERE and CASE handle the conditions.

Verify the results before using the query in production

Before adding your final SQL to a controller or report, check the row counts and the actual result values.

Start with:

SELECT
    department,
    status,
    COUNT(*) AS employee_count
FROM demo_employees
GROUP BY department, status
ORDER BY department, status;

This tells you how many records exist for each department and status combination.

Now test the basic filter:

SELECT
    COUNT(*) AS matching_employees
FROM demo_employees
WHERE department = 'Sales'
  AND status = 'active';

Expected result:

matching_employees
------------------
2

Next, check a conditional calculation:

SELECT
    SUM(
        CASE
            WHEN department = 'Sales'
             AND status = 'active'
            THEN 1
            ELSE 0
        END
    ) AS active_sales_count
FROM demo_employees;

Expected result:

active_sales_count
------------------
2

Both methods should agree.

If they don't, inspect the conditions rather than immediately changing the SQL structure.

I'd also check these issues before blaming CASE:

NULL comparisons: Use IS NULL and IS NOT NULL, not = NULL.
Unexpected duplicate rows: Look for joins that match multiple records.
Incorrect data types: Confirm that the values being compared use compatible types.
Missing columns: Run SHOW COLUMNS FROM demo_employees; to inspect the table.
Incorrect column aliases: An alias defined in SELECT generally cannot be referenced directly in the same query's WHERE clause.

If a query runs but returns zero records, temporarily remove the WHERE clause and add conditions back one at a time.

That's usually more useful than rewriting the whole query.

If the query is slow on a large production table, use:

EXPLAIN
SELECT
    employee_id,
    full_name,
    annual_salary
FROM demo_employees
WHERE department = 'Sales'
  AND status = 'active';

EXPLAIN shows how MySQL plans to read the table.

For a real, persistent table, check whether indexes support your frequently used filters. Don't automatically add an index for every column, because indexes also cost storage and make writes more expensive.

For a second set of eyes on a production query, you can also check HeadsNTail services.

FAQ

Can I select multiple columns using one CASE statement in SQL?

Not using a single CASE expression in a normal SELECT list. Each CASE expression produces one result value, so you'll need a separate expression for every conditional output column. If you want to change the actual set of output columns, use separate queries or dynamic SQL.

How do I select multiple columns with multiple WHERE conditions?

List the columns after SELECT, then combine your filters using AND, OR, or IN. Use parentheses to make the intended logic clear when mixing AND and OR. Remember that WHERE filters rows, not individual column values.

What's the difference between CASE and IF in MySQL?

Both allow conditional values to be returned in a query. IF() takes a condition and two possible results, while CASE can express multiple conditions more clearly. CASE is standard SQL, making it a better choice when portability matters.

Can SQL dynamically select column names based on user input?

Yes, but the column list must be decided before the SQL statement is prepared and executed. You can choose between predefined queries in your application or construct a statement using validated identifiers. Parameter placeholders cannot replace column names.

Can I use WHERE and CASE together in the same SELECT query?

Yes. WHERE removes rows that don't match your filter, while CASE calculates conditional values for rows that remain. Using both is common in reporting queries where you need to filter employees and calculate different output values based on their departments or statuses.

Next, apply these patterns to a small copy of your real data. Once you understand the difference between filtering rows, calculating conditional values, and switching column lists, the question "how to select multiple columns based on a condition in sql?" becomes much easier to solve.

Originally published at headsntail.com.

What Is the Host Parameter in mysqli_connect()?

Faizan — Sat, 17 Oct 2026 12:40:11 +0000

HNT-START
TITLE: What Is the Host Parameter in mysqli_connect()?
SLUG: mysqli-connect-host-parameter-explained
EXCERPT: Learn what the host parameter means in mysqli_connect(), when to use localhost or an IP address, and how to fix common MySQL connection errors.

CATEGORY: MySQL

You'll know exactly which host value to use in mysqli_connect() after a few minutes of checking your PHP and MySQL setup. The host parameter is the first argument of mysqli_connect(), and it tells PHP where to find the MySQL database server. If you're asking "what is the host parameter? what value should i put as the first argument in mysqli_connect()?", the answer depends on whether MySQL runs on your computer, another server, or inside a container.

Quick answer: Use localhost when PHP and MySQL run on the same machine. Use 127.0.0.1 when you specifically want to connect to local MySQL over TCP/IP. If your database runs on another server, enter its actual hostname or IP address. Don't use your website domain unless it also points to the MySQL server.

The confusion usually starts with a simple PHP example:

<?php

$conn = mysqli_connect(
    'localhost',
    'root',
    '',
    'my_database'
);

Someone copies this connection from a tutorial, changes the database name, and expects it to work everywhere.

It might work on XAMPP. It might fail immediately on shared hosting or inside Docker.

The reason isn't complicated. localhost describes where the database server is relative to PHP, not where your website is accessible from a browser.

We'll use a small order management application with a database called orders_db to explain how the connection works and how to fix it when the hostname is wrong.

How the host parameter works in mysqli_connect()

The syntax of mysqli_connect() is:

mysqli_connect(
    $hostname,
    $username,
    $password,
    $database,
    $port,
    $socket
);

Each parameter has a specific purpose.

Parameter	Purpose	Example
Host	Location of the MySQL server	`localhost`
Username	MySQL account	`app_user`
Password	MySQL account password	Your actual password
Database	Database to select	`orders_db`
Port	TCP port number	`3306`
Socket	Local socket path, when needed	`/var/run/mysqld/mysqld.sock`

The port and socket arguments are optional.

The first argument tells PHP where it should try to establish the database connection.

The second and third arguments are used to authenticate with MySQL. The fourth selects the database your application wants to work with.

Think of the connection process like this:

PHP application
      |
      | mysqli_connect()
      |
      v
MySQL host
(localhost or remote server)
      |
      v
MySQL authentication
(username + password)
      |
      v
Database: orders_db
      |
      v
Execute SQL queries

For our order management application, a normal connection might be:

<?php

$conn = mysqli_connect(
    '127.0.0.1',
    'app_user',
    'your_password',
    'orders_db',
    3306
);

This assumes the database exists, the MySQL user has been created, and the user has permission to access it.

Here, PHP connects to the local machine over TCP/IP using port 3306.

It doesn't search for a database named 127.0.0.1. That value identifies the server, not the database.

A complete PHP MySQL connection example

Create a file called db.php:

<?php

mysqli_report(
    MYSQLI_REPORT_ERROR | MYSQLI_REPORT_STRICT
);

$host = '127.0.0.1';
$username = 'app_user';
$password = 'your_actual_password';
$database = 'orders_db';
$port = 3306;

try {

    $conn = mysqli_connect(
        $host,
        $username,
        $password,
        $database,
        $port
    );

    mysqli_set_charset($conn, 'utf8mb4');

    echo 'MySQL connection successful';

    mysqli_close($conn);

} catch (mysqli_sql_exception $e) {

    error_log(
        'Database connection failed: ' .
        $e->getMessage()
    );

    http_response_code(500);

    exit('Unable to connect to the database.');
}

Replace the example username and password with your actual credentials.

If the database connection succeeds, you'll see:

MySQL connection successful

If the connection fails, the script logs the technical error rather than exposing sensitive information to website visitors.

That's the approach I'd use for diagnosing a connection in a real application.

For production, keep credentials in environment configuration outside the public web directory. Don't leave real database passwords inside publicly accessible diagnostic files.

Also, don't assume changing $host will fix every connection error. The hostname, authentication credentials, database name, and server configuration are separate things.

What is the host parameter? What value should I put as the first argument in mysqli_connect()?

The correct value depends on where your PHP application runs and where the MySQL server runs.

Here's the practical comparison:

Your setup	Host value
PHP and MySQL on the same computer	`localhost`
Local MySQL connection over TCP/IP	`127.0.0.1`
Database on a separate server	Actual database hostname or IP
PHP and MySQL in separate Docker Compose services	MySQL service name
Shared hosting	Hostname supplied by hosting provider
Cloud-managed MySQL	Database endpoint supplied by provider

The important part is choosing a value based on your actual environment.

Use localhost for a local PHP and MySQL installation

Suppose you're running Apache, PHP, and MySQL through XAMPP on Windows.

Both PHP and MySQL are installed on the same computer.

A connection can use:

$host = 'localhost';

Your code might look like:

<?php

$conn = mysqli_connect(
    'localhost',
    'app_user',
    'your_password',
    'orders_db'
);

In this setup, localhost is appropriate because the MySQL server is running locally.

You don't need to enter your computer's public IP address.

You also don't need to enter the URL you type into Chrome to open your PHP application.

One thing to check: XAMPP installations don't all have the same MySQL credentials.

Some fresh development installations may have a root account without a password. Others have been configured differently.

Don't assume the username is always root, and don't copy an empty root password into a production application.

A dedicated MySQL user is the safer choice.

Use 127.0.0.1 to connect through TCP/IP

You might wonder why PHP examples sometimes use:

$host = 'localhost';

while others use:

$host = '127.0.0.1';

Both refer to the local machine, but they don't always use the same connection method.

On Linux and other Unix-like systems, MySQL clients normally use a Unix socket when the hostname is localhost.

When you use 127.0.0.1, the client connects over TCP/IP.

For example:

<?php

$conn = mysqli_connect(
    '127.0.0.1',
    'app_user',
    'your_password',
    'orders_db',
    3306
);

This explicitly requests a TCP connection to the local machine on port 3306.

That difference matters when PHP can't find the MySQL socket file.

For example, you might get:

mysqli_sql_exception: No such file or directory

If PHP is using a local Unix socket and the configured socket path is incorrect, switching to 127.0.0.1 may work.

However, MySQL must be listening on TCP/IP, and the account must have permission to connect.

Changing the host doesn't start a stopped MySQL server or fix an incorrect password.

One gotcha: on Unix-like systems, passing a TCP port alongside localhost doesn't necessarily force TCP. If you need TCP explicitly, use 127.0.0.1.

Use the actual database server address for remote MySQL

Now suppose your PHP application runs on one server and MySQL runs on another.

Your website might be available at:

https://app.example.com

But the MySQL server might use:

db.internal.example

Your connection should look like:

<?php

$conn = mysqli_connect(
    'db.internal.example',
    'app_user',
    'your_password',
    'orders_db',
    3306
);

The hostname above is illustrative. Replace it with your actual database endpoint.

If the hosting provider gives you an IP address, you can use that instead.

For example:

$host = '192.0.2.10';

That address belongs to a reserved documentation range. It isn't a real database server for this example.

A remote MySQL server must also accept connections from your application.

This may involve MySQL account permissions, firewall settings, and secure network access.

Don't open MySQL to the entire public internet just to make a PHP connection work.

Where possible, use private networking and appropriate encryption for remote database connections.

Where you'll meet the host parameter in real PHP projects

The MySQL host setting appears in more places than the mysqli_connect() function.

You'll find it in local development tools, shared hosting, Docker, Laravel, and server configuration files.

XAMPP and WAMP

For XAMPP or WAMP, the most common starting point is:

$host = 'localhost';

If the connection doesn't work, open the XAMPP or WAMP control panel.

Check whether the database service is running.

Then confirm the configured port.

For example, if MySQL is using port 3307, your code must specify that port when connecting over TCP:

<?php

$conn = mysqli_connect(
    '127.0.0.1',
    'app_user',
    'your_password',
    'orders_db',
    3307
);

A wrong port can produce a connection error even when your hostname is correct.

I'd check the service status and port before reinstalling MySQL or editing random configuration files.

Shared hosting and cPanel

On shared hosting, the database might run on the same server as PHP or on a separate database server.

Open your hosting control panel and find the MySQL connection details.

The host may be:

localhost

Or it may be a hostname provided by your hosting company.

Don't assume your website domain is also the database hostname.

Similarly, the address used to access phpMyAdmin is not necessarily the address that your PHP application should use for MySQL.

If your hosting company gives you a database hostname, use that value.

Docker Compose

Docker is one of the easiest places to get localhost wrong.

Imagine PHP running inside one container and MySQL running inside another.

From inside the PHP container, localhost refers to the PHP container itself.

It doesn't automatically refer to the MySQL container.

Consider this Compose configuration:

services:
  app:
    build: .
    depends_on:
      - mysql

  mysql:
    image: mysql:8.4

    environment:
      MYSQL_DATABASE: orders_db
      MYSQL_USER: app_user
      MYSQL_PASSWORD: change_this_password
      MYSQL_ROOT_PASSWORD: change_this_root_password

This is an example configuration, assuming the application Dockerfile exists.

The example passwords must be replaced with suitable credentials or secret management before deployment.

Because the database service is named mysql, the PHP application running inside the app service can usually use:

$host = 'mysql';

Docker Compose provides name resolution between services sharing its network.

Using 127.0.0.1 inside the PHP container would point to the PHP container, not the MySQL container.

Also, depends_on doesn't guarantee that MySQL is ready to accept connections. Applications may need a database health check or connection retry.

If PHP runs directly on the Windows or Linux host rather than inside Compose, the connection setup is different. You may need a published database port.

Laravel DB_HOST configuration

Laravel uses the same underlying concept, although it normally connects through PDO instead of calling mysqli_connect().

In Laravel, you'll usually configure the host in .env:

DB_CONNECTION=mysql
DB_HOST=127.0.0.1
DB_PORT=3306
DB_DATABASE=orders_db
DB_USERNAME=app_user
DB_PASSWORD=your_password

The DB_HOST value tells Laravel where MySQL is located.

If the database moves to another machine, the host value may need to change.

After updating Laravel environment configuration, cached settings may need to be cleared:

php artisan config:clear

If your deployment uses configuration caching, rebuild the cache according to your deployment process.

For a related database setup problem, read Why php artisan migrate:fresh --seed can't seed a MySQL table.

Common misunderstandings about MySQL connection errors

Developers sometimes change the hostname whenever a MySQL connection fails.

That can make troubleshooting harder because different errors point to different problems.

Read the actual exception first.

mysqli_connect(): Connection refused

A failed connection might report:

mysqli_sql_exception: Connection refused

On Windows, you may see:

No connection could be made because the target machine actively refused it

This usually means the requested network endpoint isn't accepting the connection.

Possible causes include a stopped MySQL service, an incorrect port, or a server listening on a different network interface.

Test the connection outside PHP.

If you have the MySQL command-line client installed, run:

mysql --protocol=TCP --host=127.0.0.1 --port=3306 --user=app_user --password orders_db

The client will prompt for the password.

If the command fails, investigate the MySQL service and network settings.

If the command succeeds but PHP fails, compare the exact host, port, and credentials.

On Windows, you can also test TCP connectivity through PowerShell:

Test-NetConnection 127.0.0.1 -Port 3306

Look for:

TcpTestSucceeded : True

This confirms that a TCP connection can be established to that endpoint.

It doesn't confirm MySQL authentication or database permissions.

Access denied for user 'root'@'localhost'

Another common error looks like:

Access denied for user 'root'@'localhost'

This means the MySQL server rejected the account during authentication or authorization.

It doesn't automatically mean the database hostname is wrong.

Check the username and password first.

MySQL accounts are identified by both username and client host information.

For example:

'app_user'@'localhost'

and:

'app_user'@'192.0.2.%'

can have different authentication settings and permissions.

The second address pattern is illustrative.

A detail that causes confusion is that the host part of a MySQL account describes where an account is permitted to connect from. It isn't necessarily the hostname PHP uses to find the database server.

Don't fix an access-denied error by granting unrestricted database access to every host.

Unknown database 'orders_db'

Suppose PHP reports:

Unknown database 'orders_db'

This indicates that the requested database wasn't found on the MySQL server that received the connection.

Check the database name.

If you're connecting to a remote server, also verify you're reaching the correct MySQL instance.

Changing:

$host = 'localhost';

to:

$host = '127.0.0.1';

won't create a missing database.

No such file or directory

On Unix-like systems, you may encounter:

mysqli_sql_exception: No such file or directory

A common cause is an incorrect local MySQL socket path.

For example, PHP might be trying to access a socket file that doesn't exist at the configured location.

Try connecting over TCP:

$host = '127.0.0.1';

If that works, investigate the socket configuration.

If TCP also fails, check the MySQL service and listening interfaces.

mysql_connect() is not mysqli_connect()

Some old PHP tutorials contain:

mysql_connect(
    'localhost',
    'root',
    ''
);

That function belonged to the old mysql extension, which was removed from PHP.

Modern PHP applications should use MySQLi or PDO.

If you're maintaining older code, see How to fix mysql_fetch_array() expects parameter 1 to be resource.

How to check which MySQL server PHP connected to

Sometimes your connection succeeds, but you're unsure whether PHP is using the intended database server.

For example, your development and production databases might have similar names.

You can ask MySQL which server and database you're using.

After establishing a working $conn connection, run:

<?php

$result = mysqli_query(
    $conn,
    "SELECT
        DATABASE() AS database_name,
        @@hostname AS server_hostname,
        @@port AS server_port"
);

$row = mysqli_fetch_assoc($result);

echo '<pre>';

print_r($row);

echo '</pre>';

The query reports the currently selected database, the MySQL server's configured hostname, and its configured port.

Example output format:

Array
(
    [database_name] => orders_db
    [server_hostname] => database-server
    [server_port] => 3306
)

The actual hostname and port depend on your environment.

This is useful when you suspect PHP is connecting to the wrong database instance.

Run the diagnostic only in a trusted environment. Remove or protect the output before deploying publicly.

You can find the formal argument definitions in the official PHP mysqli_connect() documentation.

When the MySQL host parameter matters and when it doesn't

The host parameter matters whenever PHP must establish a database connection.

It becomes particularly relevant when moving a website between servers, connecting to remote MySQL, configuring Docker networks, or changing the database service port.

It also matters when switching between a local Unix socket and a TCP/IP connection.

However, the host parameter doesn't control SQL syntax or the structure of your database.

Consider this query:

<?php

$result = mysqli_query(
    $conn,
    'SELECT unknown_column FROM orders'
);

If the unknown_column field doesn't exist, MySQL will report an SQL error.

Changing the host won't repair that query.

The same applies to missing tables, incorrect column names, data type mismatches, and invalid SQL statements.

A successful database connection proves only that PHP could reach the MySQL server, authenticate, and select the requested database.

It doesn't prove that every SQL query in the application will work.

I'd avoid changing connection settings once you've verified that the application reaches the correct server.

If a query is failing, inspect the query and the actual database schema instead.

FAQ

What is the default host value in mysqli_connect()?

PHP's MySQLi connection function can use a configured default hostname when the argument is omitted. In many development environments, this corresponds to localhost. It's better to specify the intended hostname explicitly so the connection doesn't depend on environment-specific defaults.

Should I use localhost or 127.0.0.1 for MySQL?

Use localhost for a normal local connection when your configuration supports it. Use 127.0.0.1 if you specifically need a local TCP/IP connection. On Linux, the distinction is particularly relevant because localhost normally selects a Unix socket.

Can I use an IP address as the first argument in mysqli_connect()?

Yes. The first argument accepts a hostname or IP address. 127.0.0.1 identifies the local loopback interface, while a reachable remote address can identify a database running on another machine.

What is the default MySQL port for mysqli_connect()?

MySQL commonly listens on TCP port 3306. Your server may use a different port, depending on its configuration. You can provide the required TCP port as the fifth argument of mysqli_connect().

Why does mysqli_connect() work on localhost but fail on hosting?

Your hosting server may have a different MySQL hostname, username, password, port, or access policy. Check the database connection details provided by your hosting company. Also verify that the PHP server can reach the database and that the MySQL account has permission to connect.

If you're still asking "what is the host parameter? what value should i put as the first argument in mysqli_connect()?", start by identifying where MySQL actually runs. Test that hostname and port with the MySQL command-line client, then use the verified connection details in your PHP application.
HNT-END

Originally published at headsntail.com.

Export Large Data With Chunk in Laravel-Excel: Fix

Faizan — Sat, 17 Oct 2026 12:12:24 +0000

The most common mistake developers make when exporting thousands of database records is loading every row into memory before generating the Excel file. Calling Model::all() or Model::get() inside an export may work perfectly during development, then fail when the production database grows.

If you need to export large data with chunk in laravel-excel, the fix is usually to stop building a full collection and let Laravel Excel retrieve database records in smaller batches.

Quick answer: Use Laravel Excel's FromQuery concern instead of FromCollection with Model::all() or Model::get(). Return an Eloquent query without executing it. Laravel Excel processes the query in chunks automatically. For larger exports, queue the operation so it runs outside the HTTP request and avoids browser timeouts.

This guide uses one example throughout: exporting customer orders to an Excel spreadsheet. We'll start with the memory-heavy approach, replace it with a chunked query, and then move the export into Laravel's queue system.

The implementation follows the Laravel Excel 3.1 API. If you're using another major version, check the corresponding documentation before copying the code.

1. Reproduce the memory problem with a large Laravel export

Imagine an order management application containing a growing number of customer orders.

The orders table has these columns:

Column	Purpose
`id`	Order identifier
`order_number`	Reference number
`customer_email`	Customer email
`total`	Order amount
`created_at`	Order creation date

Your application already has an App\Models\Order Eloquent model.

A typical export begins with this command:

php artisan make:export OrdersExport --model=Order

If Artisan reports that the command does not exist, install Laravel Excel first:

composer require maatwebsite/excel

This installs the package version compatible with your project's Composer dependencies. Check which version was selected:

composer show maatwebsite/excel

For an existing installation, you don't need to reinstall the package.

The first implementation developers often write looks like this:

<?php

namespace App\Exports;

use App\Models\Order;
use Maatwebsite\Excel\Concerns\FromCollection;

class OrdersExport implements FromCollection
{
    public function collection()
    {
        return Order::all();
    }
}

And the controller might return:

return Excel::download(
    new OrdersExport(),
    'orders.xlsx'
);

This works for small datasets because the entire result fits comfortably in memory.

The problem is here:

return Order::all();

Eloquent loads every matching record into a collection before Laravel Excel begins processing it.

Every record becomes an Eloquent model containing attributes and additional object overhead. On top of that, PhpSpreadsheet needs resources to construct the workbook.

For a sufficiently large dataset, PHP may fail with:

Allowed memory size of 134217728 bytes exhausted

The exact memory limit and error location depend on your PHP configuration and the amount of data.

Another possible symptom is an HTTP timeout while the browser waits for the export.

Increasing memory_limit might temporarily hide the problem, but it doesn't remove the underlying inefficient data-loading approach.

Expected result at this stage: You have identified whether your export retrieves the entire dataset before writing the spreadsheet.

2. Export large data with chunk in laravel-excel using FromQuery

The recommended solution for database-backed exports is Laravel Excel's FromQuery concern.

Unlike FromCollection, it accepts an unexecuted Eloquent query. Laravel Excel then retrieves the results in chunks rather than requiring you to load all matching records at once.

Replace app/Exports/OrdersExport.php with:

<?php

namespace App\Exports;

use App\Models\Order;
use Maatwebsite\Excel\Concerns\FromQuery;
use Maatwebsite\Excel\Concerns\WithHeadings;
use Maatwebsite\Excel\Concerns\WithMapping;

class OrdersExport implements
    FromQuery,
    WithHeadings,
    WithMapping
{
    public function query()
    {
        return Order::query()
            ->select([
                'id',
                'order_number',
                'customer_email',
                'total',
                'created_at',
            ])
            ->orderBy('id');
    }

    public function headings(): array
    {
        return [
            'ID',
            'Order Number',
            'Customer Email',
            'Total',
            'Created At',
        ];
    }

    public function map($order): array
    {
        return [
            $order->id,
            $order->order_number,
            $order->customer_email,
            $order->total,
            $order->created_at?->format('Y-m-d H:i:s'),
        ];
    }
}

The crucial detail is that query() returns a builder.

Don't do this:

public function query()
{
    return Order::query()->get();
}

And don't do this:

public function query()
{
    return Order::all();
}

Both execute the database query and return the records immediately.

With FromQuery, Laravel Excel controls when and how the query runs.

Notice three other decisions in the working example.

First, select() retrieves only the fields required by the spreadsheet. This avoids loading unnecessary model attributes.

Second, orderBy('id') provides a deterministic ordering for the export. This is useful when processing results across multiple queries, although concurrent database modifications can still affect exports.

Third, WithMapping explicitly controls the spreadsheet columns. You don't need to export every model property.

According to the official Laravel Excel FromQuery documentation, chunking happens automatically when using this concern.

Expected result: The export now processes order records in database batches rather than loading the entire result into one collection.

One distinction matters: database chunking reduces the memory required for retrieving records, but it doesn't guarantee constant total memory usage. Generating a large XLSX workbook can still consume substantial memory.

3. Control the export chunk size without manual loops

Sometimes the default export chunk size isn't suitable for your workload.

Laravel Excel provides the WithCustomChunkSize concern for controlling how many query records are processed per chunk.

Modify the export class declaration:

use Maatwebsite\Excel\Concerns\WithCustomChunkSize;

class OrdersExport implements
    FromQuery,
    WithHeadings,
    WithMapping,
    WithCustomChunkSize
{
    // Keep the query(), headings(), and map()
    // methods from the previous step.

    public function chunkSize(): int
    {
        return 1000;
    }
}

Add the use statement and chunkSize() method to the existing export class; don't remove the implementations from Step 2.

The 1000 value is an example configuration, not a universally optimal setting.

Smaller chunks reduce the number of database records handled simultaneously but may require more queries and queued jobs.

Larger chunks reduce query overhead but can increase memory consumption during processing.

Choose a value based on actual measurements, especially if individual rows contain large text fields or require additional database relationships.

Why not call chunk() manually?

You might find examples like this:

Order::chunk(1000, function ($orders) {
    // Export each batch...
});

Laravel's chunk() method is useful when processing records yourself. However, manually calling it inside a normal Laravel Excel export doesn't automatically create one continuous spreadsheet.

You would need to coordinate writing and appending the batches.

With FromQuery, Laravel Excel already manages the underlying query chunks.

Also, don't confuse WithCustomChunkSize with WithChunkReading.

WithChunkReading belongs to Laravel Excel's import workflow. It is commonly used when reading large Excel files into Laravel, not when exporting database records.

See the Laravel Excel export concerns reference for the supported interfaces.

Expected result: Your export retrieves records in a controlled chunk size without custom database loops.

4. Queue the Laravel Excel export to prevent request timeouts

Chunking solves one part of the problem: retrieving too much database data at once.

However, an export may still take longer than the PHP request timeout or web server timeout.

This is why a chunked export can work through Artisan but fail when triggered from the browser.

For large reports, queueing is generally a better approach than forcing the user to wait for a synchronous download.

Laravel Excel supports queued exports directly.

First, configure a queue connection in .env:

QUEUE_CONNECTION=database

Make sure your application's queue tables exist. Newer Laravel application templates may already include their migrations.

If your project doesn't have a jobs-table migration, generate one using the appropriate command for your Laravel version:

php artisan make:queue-table

Older Laravel installations may use:

php artisan queue:table

Run migrations after creating any missing table:

php artisan migrate

Then start a queue worker:

php artisan queue:work database --tries=3 --timeout=300

The timeout shown is an example. Configure the queue connection's retry_after value to exceed the worker timeout, and use worker settings appropriate for your workload.

Now create a controller:

php artisan make:controller OrderExportController

In app/Http/Controllers/OrderExportController.php:

<?php

namespace App\Http\Controllers;

use App\Exports\OrdersExport;
use Illuminate\Http\RedirectResponse;

class OrderExportController extends Controller
{
    public function export(): RedirectResponse
    {
        (new OrdersExport())->queue(
            'exports/orders.xlsx',
            'local'
        );

        return back()->with(
            'success',
            'Your export has been queued.'
        );
    }
}

The queue() method is available through Laravel Excel's Exportable trait, so add it to the export class:

use Maatwebsite\Excel\Concerns\Exportable;

Inside the class:

use Exportable;

For clarity, the export class now implements FromQuery, WithHeadings, WithMapping, and WithCustomChunkSize, uses the Exportable trait, and retains all four methods from the earlier steps.

use App\Http\Controllers\OrderExportController;
use Illuminate\Support\Facades\Route;

Route::middleware('auth')->post(
    '/orders/export',
    [OrderExportController::class, 'export']
)->name('orders.export');

The route is protected by Laravel's authentication middleware, although you should also add any application-specific export authorization.

To trigger it from an authenticated Blade page:

<form method="POST" action="{{ route('orders.export') }}">
    @csrf

    <button type="submit">
        Export Orders
    </button>
</form>

When a user clicks the button, Laravel dispatches the export to the queue rather than waiting for the entire workbook to be generated.

The background worker processes the export chunks and saves the resulting file to the configured disk.

Important: Queuing returns immediately, but it does not immediately provide a completed downloadable file.

Your application should show an export status and only offer a download after completion.

This example uses a fixed filename for simplicity. In production, generate a unique filename per export request to prevent users from overwriting one another's reports. Downloads must also be authorized against the requesting user.

5. Fix Laravel Excel out-of-memory and failed queue jobs

If the queued export still fails, don't immediately increase PHP memory and assume the problem is resolved.

Check the failure category first.

The worker never processes the export

If the controller reports success but no file appears, verify that the queue worker is running.

php artisan queue:work database --tries=3 --timeout=300

Inspect failed jobs:

php artisan queue:failed

To inspect the application log, check:

storage/logs/laravel.log

If you corrected the underlying error, retry an appropriate failed job using its recorded identifier:

php artisan queue:retry FAILED_JOB_ID

Replace FAILED_JOB_ID with an actual identifier reported by Artisan.

Queued jobs don't complete merely because they were dispatched. A worker must actively consume them.

Memory is still exhausted

If FromQuery is already implemented, check the size and complexity of each spreadsheet row.

Avoid unnecessarily loading relationships or calculating expensive values inside map().

For example, this can introduce repeated database queries:

public function map($order): array
{
    return [
        $order->id,
        $order->customer?->name,
    ];
}

If the related customer isn't loaded, accessing it may trigger additional queries.

Consider an appropriately scoped eager load or a database join. Select the approach based on the actual relationships and the size of the export.

If the spreadsheet contains extensive styling, formulas, images, or very wide rows, PhpSpreadsheet's workbook memory requirements may become the limiting factor even though database queries are chunked.

For tabular reports that don't require XLSX features, CSV may be a better format.

Queue jobs run but the output is incomplete

Queued exports rely on multiple jobs processing the same workbook.

On a multi-server deployment, check whether workers have access to shared temporary files. Laravel Excel supports configuring a remote temporary-files disk for this situation.

For complex queries containing groupBy, the standard query count may not reflect the number of result rows. In that situation, Laravel Excel's WithCustomQuerySize concern can supply the correct row count for queued job calculation.

Also check for records being inserted, deleted, or modified during a long-running export. Ordinary chunked queries don't automatically provide a consistent database snapshot.

A MySQL data error appears during report preparation

Exporting rows normally reads data rather than inserting it. But some systems first populate staging or reporting tables before generating spreadsheets.

If that preparatory process produces a Data truncated for column error, fix the database value or column definition separately. It isn't solved by changing the Excel chunk size.

See Data Truncated for Column at Row 1: Cause and Fix for that related database issue.

Expected result: You can distinguish memory exhaustion, request timeouts, failed workers, missing temporary files, and source-data errors instead of treating them as the same problem.

6. Verify that the chunked export contains every order

A successful queue response doesn't prove that the final spreadsheet is complete.

Verification should include the stored file, the number of exported rows, and a check of sample records.

For the controller example, wait until the queue worker finishes, then run:

php artisan tinker

Inside Tinker:

use Illuminate\Support\Facades\Storage;

Storage::disk('local')->exists('exports/orders.xlsx');

Expected output after a successful export:

true

Check the file size:

Storage::disk('local')->size('exports/orders.xlsx');

A positive size proves that a file exists, but not that every expected record was written.

For a smaller verification dataset, open the spreadsheet and compare its exported data rows with the database query:

\App\Models\Order::query()->count();

Since the example contains one heading row, the spreadsheet should have one more row than the number of exported orders, provided that each order maps to exactly one row.

You can also test that the controller dispatches a queued export without generating a real spreadsheet. Laravel Excel provides a facade fake for this purpose.

Example feature test:

<?php

namespace Tests\Feature;

use App\Models\User;
use Illuminate\Foundation\Testing\RefreshDatabase;
use Maatwebsite\Excel\Facades\Excel;
use Tests\TestCase;

class OrderExportTest extends TestCase
{
    use RefreshDatabase;

    public function test_orders_export_is_queued(): void
    {
        Excel::fake();

        $user = User::factory()->create();

        $this->actingAs($user)
            ->post(route('orders.export'))
            ->assertRedirect();

        Excel::assertQueued(
            'exports/orders.xlsx',
            'local'
        );
    }
}

Run it using:

php artisan test --filter=OrderExportTest

This verifies that the application queues the intended export. It does not prove that the actual workbook is complete or that the queue worker can process it.

For that, perform an integration test with a real worker and compare the file contents against a controlled dataset.

Next steps

Once the export works reliably, add unique filenames, export progress tracking, completion notifications, and secure download links. Measure query duration, peak memory, worker runtime, and final workbook size before tuning chunk settings. For particularly large reports, consider streaming or background-generated CSV files instead of creating a heavily formatted XLSX workbook.

FAQ

Does Laravel Excel automatically export data in chunks?

Yes, when you use the FromQuery concern, Laravel Excel processes the returned database query in chunks. You don't need to manually call Eloquent's chunk() method. This differs from exporting an already-loaded collection, which may consume significant memory before spreadsheet generation begins.

What is the best chunk size for Laravel Excel exports?

There is no single best chunk size for every application. The right value depends on the size of each record, query complexity, available memory, and whether the export runs through a queue. Start with a reasonable value, such as the example's 1000 records, then measure performance and adjust.

Why does Laravel Excel still run out of memory with FromQuery?

FromQuery reduces the amount of database data retrieved at once, but XLSX generation still requires memory for spreadsheet processing. Large cell contents, styling, formulas, relationships, or other workbook operations can increase memory usage. Try reducing chunk size and unnecessary processing; consider CSV for very large, mostly unformatted datasets.

Can I use WithChunkReading to export records?

No. WithChunkReading is intended for importing large spreadsheets into Laravel. For database exports, use FromQuery; if you need to control the export chunk size, use WithCustomChunkSize. Keeping import and export concerns separate prevents one of the most common implementation mistakes.

How do I export millions of records without a browser timeout?

Use a queued FromQuery export so that the HTTP request only starts the background work. Ensure that queue workers, temporary storage, and completion handling are configured correctly. For extremely large datasets, a CSV export or splitting the output into multiple files may be more practical than one XLSX workbook. If your goal is to export large data with chunk in laravel-excel, start with FromQuery and queueing, then choose the output format based on measured memory usage and actual reporting requirements.

Originally published at headsntail.com.

Fix curl (35) ssl3_get_record:wrong version number on Nginx

Faizan — Sat, 17 Oct 2026 11:09:38 +0000

curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number

You run curl https://example.com against your Nginx server and get the error above instead of a page. If you searched for "nginx error https . curl: (35) error:1408f10b:ssl routines:ssl3_get_record:wrong version number", the cause is almost always one of these three:

Nginx listens on 443 without ssl. The port is open, but it serves plain HTTP.
You're calling https:// on a plain HTTP port. Examples are :80, :8080 or php artisan serve on :8000.
A proxy setting is wrong. https_proxy points at https://... while the proxy itself only speaks plain HTTP.

Short answer: curl sent a TLS handshake, and the server answered with plain HTTP. OpenSSL read the first bytes of that reply (HTTP/1.1 ...) as a TLS record header, found a "version" that makes no sense, and stopped. To fix it, make the port speak TLS (listen 443 ssl; with a certificate), or use http:// for that port.

Quick fix: add `ssl` to the 443 listen directive

In my experience this solves most cases. Someone writes listen 443;, adds the certificate lines, and expects Nginx to switch on TLS by itself. It doesn't. The ssl parameter on the listen line is what enables TLS on that socket.

Find your listen directives:

sudo nginx -T 2>/dev/null | grep -n "listen"

If you see listen 443; or listen [::]:443; without ssl, fix the server block:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name example.com www.example.com;

    ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    root /var/www/example.com/public;
    index index.php index.html;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

Test the config, then reload:

sudo nginx -t && sudo systemctl reload nginx
curl -I https://example.com

If your config uses the old standalone ssl on; directive, replace it with the listen ... ssl form. That directive was deprecated a long time ago, and recent Nginx releases reject it.

What causes the nginx error https . curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number

Go through each cause in turn. Each one has a quick check, so you aren't guessing.

Cause 1: Port 443 serves plain HTTP

How to confirm: request port 443 with plain HTTP.

curl -v http://example.com:443/

If this returns your normal page or a normal Nginx response, port 443 is not doing TLS. The access log also shows it clearly. Nginx logs the raw TLS handshake bytes as a broken request line:

sudo tail -n 20 /var/log/nginx/access.log

203.0.113.5 - - [...] "\x16\x03\x01\x02\x00\x01\x00\x01\xFC\x03\x03..." 400 157 "-" "-"

\x16\x03\x01 is the start of a TLS ClientHello. If you see it in the access log, your 443 listener is plain HTTP.

Fix: add ssl as shown in the quick fix. Check every server block that listens on 443, not just the one you edited, and pay special attention to any default_server block. Also check that the site is actually enabled:

ls -l /etc/nginx/sites-enabled/

If your HTTPS site exists in sites-available but has no symlink in sites-enabled, a different block is answering on 443. Create the link:

sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Cause 2: `https://` used on an HTTP-only port

This catches a lot of Laravel developers. php artisan serve and most dev servers only speak plain HTTP, so curl https://127.0.0.1:8000 gives exactly this error. Use http://127.0.0.1:8000 instead. If the dev server won't start in the first place, see php artisan serve: Failed to Listen on 127.0.0.1:8000.

The same applies to https://example.com:80 or to any app port behind Nginx, such as Node or Gunicorn on :3000 or :8080.

How to confirm: remove the s.

curl -I http://example.com:8080/

If that works, the port is plain HTTP.

Fix: use the correct scheme for that port. To expose the app over HTTPS, let Nginx handle TLS on 443 and forward to the app over plain HTTP:

location / {
    proxy_pass http://127.0.0.1:8080;
    proxy_set_header Host $host;
    proxy_set_header X-Forwarded-Proto $scheme;
}

The proxy_pass target must be http:// unless the backend really serves TLS. Pointing proxy_pass https://... at a plain backend produces the same "wrong version number" error, and it shows up in Nginx's error log.

Cause 3: Docker or another service owns port 443

A Docker mapping like -p 443:80 forwards host port 443 to the container's plain HTTP port. In that case no TLS ever happens, even though the port number looks right.

How to confirm:

sudo ss -tlnp | grep ':443'
docker ps --format '{{.Names}}\t{{.Ports}}'

Fix: map 443 to a container port that actually terminates TLS. Alternatively, keep the container on an internal HTTP port and let host Nginx handle 443 with ssl.

Cause 4: Wrong `https_proxy` value

Modern curl can talk TLS to the proxy itself. If your environment has https_proxy=https://proxy.local:3128 and the proxy only speaks HTTP, the handshake fails before your server is even contacted.

How to confirm:

env | grep -i proxy
curl -v --noproxy '*' https://example.com

If the request works with --noproxy, the proxy setting is the problem.

Fix: point the variable at the proxy using http://. It still tunnels HTTPS traffic with CONNECT:

export https_proxy=http://proxy.local:3128

Variations of the "wrong version number" error

The wording depends on your OpenSSL version. On OpenSSL 3 you will usually see:

curl: (35) OpenSSL/3.0.13: error:0A00010B:SSL routines::wrong version number

It has the same meaning and the same fixes. PHP's curl_exec(), Guzzle and Laravel's Http:: client report the same underlying error, often as cURL error 35.

If nothing worked: gather the evidence

Collect these before you change anything else:

# Full handshake view from the client side
curl -v https://example.com 2>&1 | head -n 30

# What the server actually answers on 443
openssl s_client -connect example.com:443 -servername example.com </dev/null

# Effective config, exactly as Nginx loaded it
sudo nginx -T 2>/dev/null | grep -nE "server_name|listen|ssl_certificate"

# Recent errors
sudo tail -n 50 /var/log/nginx/error.log

If openssl s_client prints wrong version number and no certificate, the listener isn't doing TLS at all. Go back to Cause 1 or Cause 3. If it shows a certificate chain, the server side is fine, and the problem is on the client side: a proxy, a wrong port in the URL, or a stale DNS record pointing to a different machine. Running dig +short example.com quickly rules out that last one.

FAQ

What does "wrong version number" mean in curl?

curl expected a TLS record but got something else, usually a plain HTTP response. OpenSSL reads those bytes as a protocol version and rejects them. Despite the name, it is almost never a real TLS version mismatch.

Does `curl -k` fix this error?

No. -k only skips certificate verification, and this error happens before any certificate is exchanged. The handshake itself fails, so you have to fix the port or scheme.

Why does the site open in my browser but fail with curl?

The browser and curl are probably not hitting the same thing. The browser may follow a redirect from port 80, use different proxy settings, or show a cached page. Run curl -v with the exact URL from the address bar to compare.

Is error 0A00010B the same as 1408F10B?

Yes. 0A00010B is the OpenSSL 3 code for the same "wrong version number" condition that OpenSSL 1.1 reports as 1408F10B. The causes and fixes are identical.

To sum up: the nginx error https . curl: (35) error:1408F10B:SSL routines:ssl3_get_record:wrong version number means TLS went in and plain HTTP came back. Find which listener is answering on that port, give it listen 443 ssl with a certificate, or use http://, and the error goes away.

Originally published at headsntail.com.

php artisan serve: Failed to Listen on 127.0.0.1:8000 (reason: ?)

Faizan — Sat, 17 Oct 2026 09:04:28 +0000

The most common mistake with this error is assuming port 8000 is busy and trying --port=8001, then 8002, then 8080, and getting the same error every time. When php artisan serve (failed to listen on 127.0.0.1:8000 (reason: ?)) shows up, the question mark means PHP didn't report a reason, and that missing reason is a clue in itself.

Here's what you'll see in the terminal:

Failed to listen on 127.0.0.1:8000 (reason: ?)

It usually comes from one of three things:

variables_order in php.ini is missing the E, which breaks how artisan serve starts PHP's built-in server. This is the most common cause on Windows.
Another process is already using the port. Often it's an old artisan serve running in a terminal you forgot about.
Windows has reserved the port. Hyper-V, WSL or Docker can block whole port ranges, and the port looks free when you check it.

Short answer: Open the php.ini used by your command line, find variables_order = "GPCS", and change it to "EGPCS". Then run php artisan serve again. If it still fails, check what's using port 8000 with netstat, and on Windows check the reserved port ranges with netsh.

I'll use one setup throughout this article: a Laravel project at C:\xampp\htdocs\shop on Windows with XAMPP. I've added the macOS and Linux commands where they're different.

Quick Fix: Change variables_order in php.ini

First, find out which php.ini your terminal actually uses. This isn't always the one you'd expect, especially if you have more than one PHP installed:

php --ini

Check the line Loaded Configuration File. On a default XAMPP install it's C:\xampp\php\php.ini.

Now check the current value:

php -r "echo ini_get('variables_order');"

If it prints GPCS, that's your problem. Open that php.ini, search for variables_order, and change it:

; before
variables_order = "GPCS"

; after
variables_order = "EGPCS"

Save the file, open a new terminal so nothing from the old session is reused, and try again:

cd C:\xampp\htdocs\shop
php artisan serve

You should now see Server running on [http://127.0.0.1:8000].

Why this one setting matters

artisan serve doesn't serve your app directly. It starts a separate php -S process and passes environment variables to it. The E in variables_order tells PHP to fill $_ENV. Without it, Laravel can't pass those variables to the new process properly, the child process fails to start, and PHP has no specific reason to report. So you get the question mark.

To be clear about what's tested and what isn't: changing GPCS to EGPCS is a widely reported fix for this exact error, and it's the first thing I check. I'm not sure every Laravel and PHP version behaves the same way, so if the value already says EGPCS, move on to the next causes.

While you're editing php.ini, keep it open. Upload limits and POST size live in the same file, and the PHP POST capacity limit guide covers those settings if you need them later.

Diagnosing "Failed to Listen on 127.0.0.1:8000" Cause by Cause

Cause 1: Something is already using port 8000

How to confirm it on Windows:

netstat -ano | findstr :8000

If you see a LISTENING line, the last column is the process ID. Look it up:

tasklist /FI "PID eq 12345"

On macOS or Linux:

lsof -i :8000

The fix: If it's an old php.exe from an earlier artisan serve, stop it:

taskkill /PID 12345 /F

On macOS or Linux, use kill 12345.

If it's something you want to keep running (another dev server, a Docker container), just pick a different port:

php artisan serve --port=8080

One detail worth knowing: when you don't pass --port, newer versions of Laravel try the next few ports automatically if 8000 is taken. So if you see the error even though Laravel moved through several ports, the port itself probably isn't the issue. Go back to the quick fix or check Cause 2.

Cause 2: Windows has reserved the port

This one is frustrating. netstat shows nothing on port 8000, but Windows still won't let PHP bind to it. Hyper-V, WSL 2 and Docker Desktop can reserve blocks of ports, and those ports are off-limits even though nothing is using them.

How to confirm: Open Command Prompt as Administrator:

netsh interface ipv4 show excludedportrange protocol=tcp

If 8000 falls inside one of the ranges listed, that's your cause.

The fix: The simplest option is to choose a port outside every listed range:

php artisan serve --port=8888

If you really need 8000, restarting the Windows NAT service often frees the reservations. In an Administrator prompt:

net stop winnat
net start winnat

Stopping winnat briefly interrupts networking for WSL and Docker, so close those first. The reserved ranges can come back after a reboot. Personally, I just keep my Laravel projects on a port I know is outside the ranges and don't worry about it.

Cause 3: Laravel is using a different PHP than you think

XAMPP, Laragon, Herd, Chocolatey and manual installs can all add their own php.exe to your PATH. You might fix the right php.ini for the wrong PHP.

How to confirm:

where php
php -v

On macOS or Linux, use which php.

If where php lists more than one path, the first one is what runs. Check that php --ini points to the file you edited.

The fix: Edit the php.ini that belongs to the first PHP in the list, or reorder your PATH in Windows environment variables so the PHP you want comes first. Open a new terminal afterwards. Terminals that are already open keep the old PATH.

Cause 4: Firewall, antivirus or host binding

A security tool that blocks php.exe from opening a port can produce the same vague error. And if localhost resolves to IPv6 on your machine, binding to it can behave differently from 127.0.0.1.

How to confirm: Try binding explicitly to a different address:

php artisan serve --host=127.0.0.1 --port=8080
php artisan serve --host=0.0.0.0 --port=8080

If 0.0.0.0 works and 127.0.0.1 doesn't, something on your machine is blocking the loopback address. If neither works and the earlier causes check out, temporarily allow php.exe in your firewall or antivirus and test again. Turn the protection back on afterwards and add a proper exception instead of leaving it off.

If Nothing Worked: Find Out Whether It's Laravel or PHP

This is the most useful test of the lot. It skips Laravel entirely and starts PHP's built-in server directly:

cd C:\xampp\htdocs\shop
php -S 127.0.0.1:8000 -t public

If this works, PHP can listen on the port, and the problem is in how artisan serve starts the server. That almost always points back to variables_order or to the PHP version mismatch in Cause 3.
If this also fails, PHP prints a real reason this time (something like "Address already in use" or an access-permissions message). That points to Cause 1, 2 or 4.

For more detail from Laravel itself, run the command in verbose mode:

php artisan serve -vvv

And if you're asking someone for help on Stack Overflow or in a team chat, include the output of these commands. They answer most of the follow-up questions straight away:

php -v
php --ini
php -r "echo ini_get('variables_order');"
where php
netstat -ano | findstr :8000

Once the server is running, your next local issue is usually the database. The migrate:fresh --seed troubleshooting guide picks up from there.

FAQ

What does "reason: ?" mean in php artisan serve?

It means PHP failed to start the server but didn't give a specific reason. With a busy port you'd normally see "Address already in use". The question mark usually means the problem happened while starting the server process, which is why the variables_order setting is the first thing to check.

Can I change the default port for php artisan serve?

Yes. Pass --port=8080 on the command line. You can also set SERVER_PORT=8080 in your .env file, and newer Laravel versions use it as the default. If you're not sure your version supports that, the --port flag always works.

Is it safe to set variables_order to "EGPCS"?

For local development, yes, and it's PHP's own built-in default. The production php.ini template leaves out E to save a bit of memory, but on your local machine that doesn't make a noticeable difference. Don't change it on a production server without checking with whoever manages that server.

Why does php artisan serve (failed to listen on 127.0.0.1:8000 (reason: ?)) only happen on Windows?

It can happen anywhere, but Windows causes two of the three common triggers. XAMPP and other Windows PHP bundles often ship a php.ini with variables_order = "GPCS", and Windows reserves port ranges for Hyper-V and WSL. On macOS and Linux, the cause is almost always a process already using the port, which lsof -i :8000 finds quickly.

Originally published at headsntail.com.