Hostwinds Blog

Zoekresultaten voor:

Huis

405 Fout uitgelegd: Oorzaken, fixes en preventietips

door: Hostwinds Team / augustus 27, 2025

Elke HTTP -statuscode vertelt een verhaal over wat er gebeurt tussen een client (bijv. Webbrowser) en een server.Sommige verhalen zijn eenvoudig;200 betekent succes, 404 betekent dat de pagina niet bestaat.Maar als je 405 -methode niet toegestaan ziet, is het verhaal iets interessanter.

Laten we afbreken wat de 405 -fout betekent, waarom deze gebeurt en hoe ze het kunnen oplossen

Wat de 405 -statuscode betekent

De 405 -methode is niet toegestaan om respons gebeurt wanneer een client (zoals uw browser of een API -tool) een verzoek indient met behulp van een HTTP -methode die de server niet toestaat voor die bron.

Bijvoorbeeld:

Een formulierinzending stuurt een NA Verzoek, maar de server accepteert alleen KRIJGEN voor die URL.
Een script verzendt een NEERZETTEN verzoek, maar het eindpunt is geconfigureerd om alleen toe te staan NA en VERWIJDEREN.

Het belangrijke detail is dat de pagina die u probeert te bereiken bestaat, maar de aanvraagmethode die wordt gebruikt om ermee te interageren is niet toegestaan door de server.

Wat kan een 405 -fout veroorzaken

De 405 -fout heeft niet altijd een enkele, voor de hand liggende oorzaak.Het kan voortkomen uit de manier waarop een verzoek wordt gedaan, hoe de server is geconfigureerd, of zelfs van extra beveiligingslagen.Hier zijn de meest voorkomende situaties die het zouden activeren:

1. Verkeerde HTTP -methode

Elke bron op een server is ingesteld om bepaalde HTTP -methoden te accepteren.Bijvoorbeeld:

Een productpagina kan het toelaten KRIJGEN (om details op te halen) maar afwijzen NA (om gegevens in te dienen).
Een API -eindpunt kan het toelaten NA Om een nieuw item te maken, maar retourneer een 405 als u het probeert VERWIJDEREN.

Een gemeenschappelijk scenario is wanneer een ontwikkelaar een NA verzoek om een URL die alleen is ontworpen om te hanteren KRIJGEN.De server herkent de bron, maar omdat de methode niet wordt ondersteund, reageert deze met 405.

Dit is een van de meest voorkomende oorzaken, vooral bij het werken met vormen, API's of scripts die interageren met webservices.

2. Verkeerd geconfigureerde serverregels

Webservers zoals Apache, Nginx en IIS geven beheerders controle over welke HTTP -methoden zijn toegestaan.Configuratierichtlijnen zoals de limiet van Apache of Limit_Except van Nginx kunnen bepaalde werkwoorden expliciet blokkeren.

Bijvoorbeeld:

Een serverbeheerder kan een site configureren om alleen toe te staan KRIJGEN en NA, blokkeren NEERZETTEN en VERWIJDEREN voor beveiliging.
Als de regels te streng (of verkeerd worden geschreven), kunnen legitieme verzoeken worden afgewezen met een 405.

Dit kan vaak gebeuren na wijzigingen in .htaccess Bestanden, serverblokken of IIS -aanvraagfilterinstellingen.Zelfs een kleine typefout- of over het hoofd gezien richtlijn kan ertoe leiden dat methoden onbedoeld worden geblokkeerd.

3. API -beperkingen

API's zijn ontworpen met strikte methoderegels.In een RESTful API komen verschillende HTTP -werkwoorden meestal overeen met specifieke acties:

KRIJGEN → Gegevens ophalen
NA → Maak nieuwe gegevens maken
Put/Patch → Update bestaande gegevens
VERWIJDEREN → gegevens verwijderen

Als een ontwikkelaar een eindpunt roept met de verkeerde methode, zoals het verzenden van een NEERZETTEN naar een URL die het alleen toestaat NA, de server reageert met een 405.

Dit is opzettelijk, omdat API's bedoeld zijn om consistente interactiepatronen af te dwingen.De API van GitHub kan je bijvoorbeeld niet VERWIJDEREN Een repository per ongeluk via een verkeerde methodeaanroep, het vereist het juiste werkwoord, of u krijgt een 405 -reactie.

4. Onjuiste vorm of Ajax -instelling

Webformulieren en JavaScript (AJAX) -verzoeken zijn een andere veel voorkomende bron van 405 fouten:

Een formulier kan de Method = "Post" kenmerk, maar de server staat het alleen toe KRIJGEN op die url.
JavaScript's ophalen() of Xmlhttprequest Kan worden gecodeerd om een putverzoek te verzenden wanneer de backend alleen post ondersteunt.

Aangezien browsers automatisch omgaan met formulier en AJAX -inzendingen, zelfs een kleine mismatch in hoe een verzoek wordt gecodeerd versus hoe de server verwacht dat het deze fout kan activeren.

Beginners komen dit vaak tegen bij het leren instellen van formulieren in PHP of bij het werken met frontend frameworks die API -oproepen voeren.

5. Beveiligingstools

Zelfs wanneer een server correct is geconfigureerd, kunnen beveiligingslagen ingrijpen en aanvragen blokkeren.Voorbeelden zijn:

Web Application Firewalls (WAFS): Deze volgen inkomend verkeer en kunnen methoden zoals Put, Delete of Trace afwijzen om het risico op aanvallen te verminderen.
Beveiligingsplug -ins: In platforms zoals WordPress schakelen sommige plug-ins bepaalde methoden op locatie-brede uit om ongeautoriseerde verzoeken te voorkomen.

In deze gevallen kan de server zelf de methode ondersteunen, maar het verzoek wordt onderschept voordat het de toepassing bereikt.Dit leidt vaak tot verwarring omdat logboeken de server de methode kunnen "afwijzen", terwijl het in werkelijkheid een beveiligingslaag is die het filteren doet.

Hoe 405 verschilt van vergelijkbare statuscodes

Op het eerste gezicht kan de 405 -fout worden aangezien voor Andere client- en serverfouten.Maar de details zijn belangrijk, en het kennen van de verschillen zal u helpen het correct te diagnosticeren.

404 Niet Gevonden

Wat het betekent: De server kan de bron niet vinden die u aanvraagt.
Voorbeeld: U probeert voorbeeld.com/page.html te bezoeken, maar de pagina bestaat helemaal niet.
Belangrijk verschil van 405: Met een 404 is het probleem de bron zelf die er niet is, terwijl met een 405 de bron bestaat - u gebruikt gewoon de verkeerde methode om ermee te communiceren.

403 verboden

Wat het betekent: De bron bestaat, maar de server blokkeert u om er toegang toe te hebben.
Voorbeeld: Mogelijk probeert u een privémap te bekijken zonder de juiste machtigingen.
Belangrijk verschil van 405: Een 403 gaat over toegangsrechten, terwijl een 405 gaat over methodebeperkingen.

501 niet geïmplementeerd

Wat het betekent: De server herkent of ondersteunt de HTTP -methode helemaal niet, voor elke bron.
Voorbeeld: Een server die geen patch -aanvragen ondersteunt, gooit deze fout, ongeacht welke bron u probeert.
Belangrijk verschil van 405: Een 501 is van toepassing op de hele server, terwijl een 405 alleen van toepassing is op een specifieke bron.

Diagnose van de 405 -fout

Het kan lastig zijn om de 405 te diagnosticeren omdat de server erkent dat de bron bestaat, maar het weigert het verzoek te verwerken zoals het is verzonden.Om de oorzaak op te sporen, helpt het om stap voor stap het probleem op te lossen.

1. Controleer de toegestane methoden

Wanneer een server een 405 retourneert, moet het antwoord een koptekstverlijsting bevatten welke methoden worden ondersteund voor die bron.Dit is de manier van de server om te zeggen: "Dat kan je niet doen, maar dit is wat je kunt doen."

Voorbeeld:

HTTP/1.1 405 Method Not Allowed
Allow: GET, POST

Als je het probeert te put, vertelt dit antwoord je dat alleen krijgen en post geldig zijn.
U kunt dit zien met behulp van browserontwikkelaarstools (netwerktabblad) of een tool zoals Postman.
Het automatiseren van koptekstcontroles in een foutopsporingsworkflow kan snel het gebruik van een verkeerd uitgelijnde methode over meerdere eindpunten benadrukken.

2. Bekijk serverlogboeken

Logboeken zijn vaak de snelste manier om de oorzaak aan het licht te brengen, omdat ze meestal een directe uitleg geven waarom het verzoek is afgewezen en bevestigen dat het geen diepere connectiviteitsprobleem is.

Apache: Controleer de error_log bestand, meestal in /var/log/apache2/ of /var/log/httpd/.
Nginx: Beoordeling error.log en Access.log, meestal in /var/log/nginx/.
IIS: Open Event Viewer of controleer IIS -logbestanden onder %SystemDrive%\ inetPub \ Logs \ LogFiles \.

Logboeken kunnen vermeldingen tonen zoals:

client sent an unsupported method (PUT) to /index.php

3. Test het eindpunt

Tools zoals Krul of Postbode zijn van onschatbare waarde om te bevestigen welke methoden daadwerkelijk werken.Het testen van eindpunten op deze manier regelt giswerk en geeft u een duidelijke zichtbaarheid van hoe de server op verschillende verzoeken reageert.

Curl gebruiken:

curl -i -X GET https://example.com/resource
curl -i -X POST https://example.com/resource
curl -i -X PUT https://example.com/resource

Als Get en Post slagen, maar faalt met een 405, heb je de mismatch geïdentificeerd.

Postman geeft een visuele interface waar u aanvraagmethoden kunt schakelen en onmiddellijk antwoorden kunt zien, waardoor het meer beginnersvriendelijk is.

4. Controleer uw code

Als de server de methode toestaat, maar u nog steeds een 405 krijgt, kan het probleem in uw applicatiecode staan.

Formulieren: Zorg ervoor dat het kenmerk van het <vorm> element overeenkomt met wat de server verwacht.Voorbeeld:

 <form action="/submit" method="post">

Ajax/fetch: Controleer of de aanvraagmethode correct is ingesteld in JavaScript:

 fetch('/api/data', {
  method: 'POST'
})

Frameworks: Sommige frameworks (zoals Angular, React of Django) kunnen standaard op bepaalde methoden standaard als u ze niet expliciet instelt.Controleer uw client-side en server-side code voor mismatches.

Notitie: Deze stap is vaak waar beginners worden gestruikeld en gegevens naar het juiste eindpunt verzenden, maar met het verkeerde werkwoord.

5. Onderzoek de serverconfiguratie

Als zowel headers als code er goed uitzien, kunnen het probleem beperkingen op serverniveau zijn.Admins blokkeren vaak methoden om veiligheidsredenen, maar als legitieme verzoeken worden gestopt, is het aanpassen van deze instellingen nodig.

Apache: Zoek naar limiet- of limitexcept -richtlijnen in uw .htaccess of hoofdconfiguratie.Voorbeeld:

 <Limit GET POST>
   Require all granted
</Limit>

Als het hier ontbreekt, retourneert elk putverzoek een 405.

Nginx: Controleer limit_except richtlijnen:

 location /api/ {
   limit_except GET POST {
      deny all;
   }
}

Dit zou andere methoden afwijzen dan GET en POST.
IIS: Open de IIS -manager, ga naar het aanvragen van filtering en bekijk het tabblad HTTP werkwoorden.Geblokkeerde werkwoorden zoals Put of Delete verschijnen hier.

Een 405 -fout vaststellen per platform/omgeving

Het repareren van een 405 -fout hangt af van het platform of de omgeving waarop uw website of -applicatie actief is.Aangezien elk servertype en contentbeheersysteem HTTP -aanvragen anders verwerkt, kan de oplossing variëren.Laten we enkele gemeenschappelijke platforms bespreken en door de stappen lopen die we kunnen nemen om configuraties te bekijken en instellingen aan te passen, zodat de juiste HTTP -methoden zijn toegestaan.

Snel pre-controle (is van toepassing op iedereen)

1. Produceer de fout en leest headers

curl -i -X PUT https://example.com/path

2. Als u het toestaan, past u uw verzoek/client aan bij matching aan.Als u dat niet doet, ga dan verder.

Apache

1. Locate configuratie

Site Config: /etc/apache2/sites-available/*.conf of /etc/httpd/conf.d/*.conf
Regels per Dir: project .htaccess

2. Maak een back -up van het bestand dat u bewerkt

sudo cp /etc/apache2/sites-available/site.conf /etc/apache2/sites-available/site.conf.bak

3. Zoek naar methodebeperkingen

Zoeken naar <Limit ...>, <Limitexcept ...>, of Herschrijver patronen die werkwoorden blokkeren.

# Example: only GET/POST allowed here
<LimitExcept GET POST>
  Require all denied
</LimitExcept>

4. Voeg de benodigde methode (s) toe of verwijder het beperkende blok

<LimitExcept GET POST PUT>
  Require all denied
</LimitExcept>

5. Valideren en opnieuw laden

sudo apachectl -t
sudo systemctl reload apache2   # or: sudo systemctl reload httpd

6. opnieuw testen met krul

curl -i -X PUT https://example.com/path

7. Indien nog steeds geblokkeerd, controleert u beveiligingslagen (bijv. Mod_security Audit Logs) en VirtualHost -voorrang.

Nginx

1. Open het serverblok voor uw site

Algemene paden: /etc/nginx/sites-beschikbare/, /etc/nginx/conf.d/*.conf

2. Maak een back -up van het bestand

sudo cp /etc/nginx/sites-available/site.conf /etc/nginx/sites-available/site.conf.bak

3. Zoek naar limit_except blokken

location /api/ {
  limit_except GET POST {
    deny all;
  }
}

4. Voeg de benodigde methode (s) toe of verwijder het blok indien onnodig

location /api/ {
  limit_except GET POST PUT {
    allow all;
  }
}

5. Test en herladen

sudo nginx -t
sudo systemctl reload nginx

6. opnieuw testen met krul

curl -i -X PUT https://example.com/api/resource

7. Als u naar een app -server proxy gaat, bevestigt u stroomopwaarts ook de methode mogelijk.

IIS (Windows Server)

Open IIS -manager → Selecteer de site.
Ga naar Verzoek filtering → http werkwoorden.
Verwijder eventuele vermeldingen voor werkwoorden die u nodig hebt (bijv. Plaats, verwijder) of voeg toestanden toe als uw beleid expliciet toestaat toestaat.
Controleren Handler -toewijzingen: als Webdav is geïnstalleerd en onderscheppen werkwoorden die u nodig hebt, verwijder of schakel de WebDAV -handler voor die site (of verwijder WebDAV indien niet nodig).
Indien aanwezig, bekijk Web.Config voor:

<system.webServer>
  <handlers> ... </handlers>
  <security>
    <requestFiltering>
      <verbs>
        <!-- Remove Deny for verbs you need -->
        <add verb="PUT" allowed="true" />
      </verbs>
    </requestFiltering>
  </security>
</system.webServer>

6. Recycle de app -pool of start de site opnieuw.

7. opnieuw testen met Curl/Postman.

WordPress & andere CMS -platforms

Reading Permalinks opnieuw
- Instellingen → Permalinks → Wijzigingen opslaan (Dit vernieuwt de regels herschrijven).
Test op plug -inconflicten
- Schakel alle plug -ins tijdelijk uit.
- Een voor een opnieuw inschakelen om de dader te vinden (beveiligings-, rust-/API-, caching- en firewall-plug-ins zijn veel voorkomende oorzaken).
Controleer door platform gegenereerde regels
- Apache: .htaccess -secties toegevoegd door plug -ins.
- Nginx: Serverblokken toegevoegd voor caching/beveiliging die limit_except of methode filters kunnen bevatten.
Als u de CMS REST API gebruikt, verifieert u geaccepteerde methoden op het eindpunt en pas de client of route -configuratie dienovereenkomstig aan.
Retenteer belangrijke acties (formulieren, aanmeldingen, beheerdersacties) na elke wijziging.

API's (algemeen)

1. Bevestig het contract

Controleer de API -documenten voor de toegestane methoden en verwachte paden van elk eindpunt.

2, onderzoek het eindpunt

# Discover allowed methods (if supported)
curl -i -X OPTIONS https://api.example.com/v1/items/123
# Then try the method you intend
curl -i -X PATCH https://api.example.com/v1/items/123

3. Client of server repareren (voorbeelden)

Clientfix: stuur de methode die het eindpunt daadwerkelijk ondersteunt (bijv. Post in plaats van Put).
Express (node.js)

 app.post('/items', createItem);
app.put('/items/:id', updateItem);
// If PUT not defined, add it—or switch your client to POST if that's the design.

Kolf (Python)

 @app.route('/items/<id>', methods=['GET','POST','PUT','DELETE'])
def item(id): ...

4. Stel een nuttige 405 in met de koptekst (server-side)

Als uw framework het niet automatisch instelt, voegt u de toegestane koptekstmethoden toe.

5. Indien fronted door een API Gateway/WAF, beoordelingsmethode filterregels daar ook.

6. opnieuw testen met Postman/Curl en bevestig de verwachte 2xx/3xx/4xx -stroom.

Na de oplossing: snelle verificatielijst

De actie retourneert nu een succes of de juiste fout (niet 405).
Handtekst toestaan vermeldt toegestane methoden nauwkeurig.
Logboeken tonen normale afhandeling, geen geblokkeerd werkwoord.
Geautomatiseerde tests (als u ze hebt) hebben betrekking op het gecorrigeerde pad en de methode.

In de toekomst 405 fouten voorkomen

Het oplossen van een 405 -fout wanneer deze verschijnt, is slechts de helft van de uitdaging - het voor het weer aan de hand is wat u op de lange termijn tijd en frustratie bespaart.Door de juiste praktijken te plaatsen tijdens de ontwikkeling en configuratie, kunt u de kansen op gebruikers of applicaties verkleinen die niet -ondersteunde methoden worden uitgevoerd.Hier zijn verschillende benaderingen die helpen voorkomen dat 405 fouten terugkerende problemen worden.

Valideer methoden in code

Bij het schrijven van formulieren, scripts of API-oproepen, controleer dubbele controle dat u alleen HTTP-methoden gebruikt die de server toestaat.Als uw server bijvoorbeeld post accepteert voor het verzenden van gegevens, zorg er dan voor dat u niet per ongeluk GET of PIT gebruikt.Validatiemethoden vroeg in de ontwikkeling helpen ook fouten te vangen voordat ze de productie bereiken.Veel frameworks laten u toegestane methoden direct in routes of controllers definiëren, waardoor het gemakkelijker wordt om correct gebruik af te dwingen.

Documentserverregels

Servers hebben vaak methodebeperkingen gedefinieerd in hun configuratiebestanden (zoals .htaccess-, nginx.conf- of API -gateway -instellingen).Door een registratie te houden van welke methoden worden ondersteund, wordt het voor zowel ontwikkelaars als beheerders gemakkelijker om de limieten te begrijpen.Deze documentatie is vooral handig in grotere teams of projecten op lange termijn, waarbij serverregels anders na verloop van tijd verloren kunnen gaan of vergeten.

Foutafhandeling

Zelfs met een zorgvuldige planning kunnen niet -ondersteunde methodeaanvragen doorlopen.Daarom is het handig om duidelijke foutmeldingen te geven wanneer een 405 optreedt.In plaats van een vage "methode die niet is toegestaan", neemt het antwoord aan, zodat de gebruiker of ontwikkelaar begrijpt wat er mis is gegaan en hoe deze te corrigeren - bijvoorbeeld door de lijst met toegestane methoden in de responskop op te nemen of de juiste methode in uw documentatie voor te stellen.

Volg de normen

Als u API's bouwt, maakt het vasthouden aan REST best practices en HTTP -normen het voor klanten gemakkelijker om te weten wat u kunt verwachten.Als u bijvoorbeeld een eindpunt ontwerpt voor het bijwerken van een resource, gebruik Put of Patch consequent.Deze voorspelbaarheid vermindert het risico dat niet -ondersteunde methoden worden verzonden en helpt externe ontwikkelaars om correct met uw API te communiceren.

Afsluiten

De 405 -methode is niet toegestaan om fout te vertellen dat de server weet dat de bron bestaat, maar de methode die u hebt geprobeerd niet toestaat.

De belangrijkste afhaalmaaltijd: Controleer de header toestaan, bekijk logboeken en zorg ervoor dat uw code- en serverregels overeenkomen met de methoden die u van plan bent te ondersteunen.

Geschreven door Hostwinds Team / augustus 27, 2025