Shopware 6 – Suche in Storefront zeigt „Leider ist etwas schiefgelaufen“ / Store-API 401 bzw. 404/405 Fehler

Shopware 6 (German)
1

Hallo zusammen,

ich habe ein Problem mit meiner Shopware 6 Installation (Domain: https://doitauto.de).
Die Produktsuche im Frontend bricht mit der Meldung „Leider ist etwas schiefgelaufen“ ab.

Schritte, die ich bereits geprüft habe:

  1. Domain & Verkaufskanal:

    • In Shopware ist die Domain https://doitauto.de korrekt im Verkaufskanal eingetragen.

    • API-Zugangsschlüssel (Access-Key) vorhanden.

  2. Nginx-Konfiguration:

    • Root zeigt auf /www/wwwroot/doitauto.de/public.

    • Rewrite-Regeln auf Shopware 6 angepasst:

      location / {
    try_files $uri $uri/ /index.php?$query_string;
}

  3. Indizes & Cache:

    • bin/console cache:clear ausgeführt.

    • bin/console dal:refresh:index erfolgreich durchgelaufen (alle Indexer zu 100 %).

  4. API-Test via Curl:

    • Ohne Access-Key:

      curl -i -X POST https://doitauto.de/store-api/search -d '{"search":"bmw"}'

      → Ergebnis: 401 Unauthorized (Header "sw-access-key" is required) → korrekt.

    • Mit Access-Key aus Verkaufskanal:

      curl -i -X POST https://doitauto.de/store-api/search \
  -H "Content-Type: application/json" \
  -H "sw-access-key: SWSCSG01Cxxxxx" \
  -d '{"search":"bmw"}'

      → Ergebnis: zeitweise 404 oder 405 Method Not Allowed (Allow: POST).

  5. Logs:

    • In var/log/prod-*.log erscheinen bei der Suche keine neuen Einträge.

    • Nginx-Error-Log zeigt keine relevanten Fehler.

Frage:

Hat jemand eine Idee, warum die Storefront-Suche im Browser mit „Leider ist etwas schiefgelaufen“ endet, obwohl:

  • der Verkaufskanal korrekt eingerichtet ist,

  • der Access-Key gültig ist,

  • die API über Curl grundsätzlich erreichbar ist,

  • und die Nginx-Rewrites auf Shopware 6 angepasst wurden?

Kann es sein, dass hier noch etwas im Zusammenspiel von Access-Key, Store-API Headern oder Proxy/WAF (aaPanel / ModSecurity) blockiert?
Welche zusätzlichen Tests oder Einstellungen (z. B. Trusted Hosts, Proxy-Header) sind sinnvoll?

:backhand_index_pointing_right: Könnt ihr mir bitte sagen, ob hier noch eine bekannte Einstellung fehlt, damit die Storefront automatisch den richtigen Access-Key mitschickt und die Suche wieder funktioniert?

Vielen Dank!

Bildschirmfoto 2025-08-21 um 21.50.14
Bildschirmfoto 2025-08-21 um 21.50.142378×1328 225 KB

2
3

das ist nicht die Lösung

4

Eventuell auch mal im Serverlog geschaut ob es dort noch Hinweise gibt? Alternativ vielleicht den Shop mal in Wartungsmodus setzen und in DEV-Modus schalten und dann mal eine Suche per Browser-URL nachstellen.

https://doitauto.de/suggest?search=456
5

Ich habe sämtliche logs überprüft und habe außer das hier nichts :frowning:

Failed to load resource: the server responded with a status of 404 (Not Found)

6

Ok, mal überprüft ob dieses Verhalten bei deaktivierten Plugins (alle) und Standard-Theme auch der Fall ist?

7

noch aktuell? @doitauto Läuft bei mir tadellos.

8

Häää???

https://doitauto.de/suggest?search=Kabel

Nix läuft da.

9

Shop in dev Mode setzen, dann wird der Fehler auch angezeigt. Am besten an einer Testumgebung und nicht in der Live.

10

jo, jetzt habe ich es auch, hier wurde vermutlich an der Suche manipuliert.

image
image1690×1064 117 KB

11

Keine Ahnung, aber ohne die hier bereites erwähnten Maßnahmen wird sich die Ursache nicht finden.

12

Problem: Shopware Suche / Suggest liefert 404

Umgebung

  • Shopware 6.x (Produktivmodus)

  • Ubuntu 22.04 mit aaPanel

  • nginx + PHP-FPM 8.3

  • Shop liegt unter /www/wwwroot/doitauto.de/public

Symptome

  • Die Suche in der Storefront liefert im Frontend einen 404.

  • Test mit curl:

curl -v -H 'X-Requested-With: XMLHttpRequest' \
  'https://doitauto.de/suggest?search=test'

→ Ergebnis: 404 Not Found

  • Test mit Store-API:
curl -v -H 'Content-Type: application/json' \
  -H 'sw-access-key: <AccessKey>' \
  --data-binary '{"search":"test"}' \
  'https://doitauto.de/store-api/search-suggest'
  • → Antwort: 405 Method Not Allowed („GET received, POST expected“)

Bisherige Maßnahmen

  1. nginx-Konfiguration angepasst

    • Alle @rewrite und rewrite ^ /index.php last; entfernt

    • location / sieht jetzt so aus:

location / {
    try_files $uri /index.php$is_args$args;
}
  • Für die Store-API ein eigener Block:
location ^~ /store-api {
    try_files $uri /index.php$is_args$args;
}
  • root zeigt korrekt auf /www/wwwroot/doitauto.de/public
  1. Shopware-Cache geleert und Themes kompiliert
bin/console cache:clear
bin/console theme:compile

  2. Router geprüft

bin/console debug:router | grep -i suggest
  1. → zeigt: frontend.search.suggest (/suggest, GET, Ajax=true)
bin/console router:match '/suggest' --method=GET --host=doitauto.de --scheme=https

  1. → matched korrekt auf frontend.search.suggest

  2. Verkaufskanal-Domain geprüft

Auffälligkeiten

  • curl -I bzw. HEAD-Anfragen liefern 404 (normal, da Route nur GET akzeptiert).

  • Auch mit GET + X-Requested-With: XMLHttpRequest bleibt /suggest?search=test 404.

  • Im prod.log erscheint bei /store-api/search-suggest:

Method Not Allowed – No route found for "GET /store-api/search-suggest" (Allow: POST)

  • → nginx oder ein Layer wandelt POST in GET um?

    Aber: location ^~ /store-api { try_files $uri /index.php$is_args$args; } ist gesetzt.

Fragen an die Community

  • Nutzt Shopware 6.7 noch /suggest für die Ajax-Suche, oder muss /widgets/search/suggest genutzt werden?

  • Kann es sein, dass Shopware beim Ajax-Request zwingend bestimmte Headers erwartet (X-Requested-With, Referer etc.)?

  • Hat jemand Erfahrung, warum trotz korrekter try_files ein POST im Store-API als GET durchgereicht wird?

  • Gibt es in Shopware 6.7 eine Änderung, dass frontend.search.suggest abgeschaltet wurde und nur noch die Store-API (/store-api/search-suggest) gültig ist?

13

“Nutzt Shopware 6.7 noch /suggest für die Ajax-Suche”

Ja