Laravel Login Issue: "Not Found" Error After Deployment on GCP

I'm facing a login issue with my Laravel application deployed on Google Cloud Platform (GCP) Compute Engine. The database is also deployed on the same infrastructure. Here's what happens:

  1. I access the application using the external IP address and see the login screen successfully.
  2. After entering valid credentials, I receive a "Not Found" error with the following message:

Not Found The requested URL was not found on this server. Apache/2.4.52 (Ubuntu) Server at 34.30.69.122 Port 80

I suspect the issue might be related to my database configuration. My current .env file likely has DB_HOST=localhost, which wouldn't work when the application is deployed.

Here's what I've tried so far:

  • Checked Laravel logs: No clear errors related to database connection or authentication.
  • Cleared cache: php artisan config:clear and php artisan cache:clear.

I would appreciate any guidance on how to troubleshoot this further. Any suggestions on what might be causing the "Not Found" error after login and how to resolve it?

Solved Solved
0 31 1,495
1 ACCEPTED SOLUTION

 

Based on the configuration you've shared, there are a couple of points that stand out and could potentially be causing the issue:

Your Apache configuration snippet shows <VirtualHost *:79>, which means Apache is listening on port 79 for this virtual host. This is unusual because HTTP traffic typically runs over port 80 (or port 443 for HTTPS). Unless you have a specific reason for using port 79 and have configured your network and application to use this port, this might be the source of the problem.

Solution: If you intended to use the standard HTTP port, change the VirtualHost directive to listen on port 80:

 
<VirtualHost *:80>

After making this change, restart Apache to apply the configuration:

 
sudo systemctl restart apache2

If you're using a non-standard port by design, ensure that your requests to the Laravel application are explicitly targeting port 79 (e.g., http://34.171.170.110:79). If not, and there's no specific reason to use port 79, switching back to the default port 80 (as mentioned above) is recommended.

Check Apache and Laravel Logs

  • Apache Logs: Check the Apache error logs (${APACHE_LOG_DIR}/error.log) for any specific errors that could indicate why the request was not found. The error log might provide more details on what's going wrong.

  • Laravel Logs: Also, review the Laravel application logs in storage/logs/laravel.log for any application-specific errors that might not be related to Apache but could cause the routing to fail.

Ensure Apache and PHP are Correctly Configured

  • PHP Module: Ensure that the PHP module is enabled in Apache. You can check this by running a2enmod php<version> (replace <version> with your PHP version, e.g., php7.4).

  • Server Restart: Every time you change the Apache configuration or enable a module, remember to restart Apache to apply the changes.

Firewall or Port Blocking

  • If you're using a non-standard port (like 79), ensure that your server's firewall or any network firewalls (including cloud provider firewalls) are configured to allow traffic on that port.

If the issue persists after verifying the port and ensuring Apache is correctly configured and restarted, consider simplifying the setup to diagnose the problem:

  • Static HTML File: Temporarily place a simple index.html file in the /var/www/html/public directory with basic content (e.g., <h1>Hello World</h1>) and try accessing it via your browser. This can help confirm whether the issue lies with Apache serving files from the DocumentRoot or if it's more related to Laravel's routing.

View solution in original post

31 REPLIES 31

The "Not Found" error after entering login credentials suggests a problem with routing the request to the correct controller or view in your Laravel application. This could be due to route configuration issues, Apache server configuration, or less likely, database connectivity problems. Here's how to troubleshoot:

Database Connection:

  • Verify DB_HOST: If your database is hosted on the same Compute Engine instance as your Laravel application, DB_HOST=localhost is correct. This configuration allows your application to communicate with the database through the local machine.

  • Credentials: Confirm that your database credentials (DB_USERNAME, DB_PASSWORD) in the .env file are accurate.

  • Test Connectivity: You can test database connectivity directly from your Compute Engine instance using a command like mysql -u yourusername -p -h localhost yourdatabase to ensure there's no broader connectivity issue.

Apache Configuration:

  • Document Root: Ensure the Apache document root is correctly set to the public directory of your Laravel installation. This is crucial for proper routing in Laravel.

  • mod_rewrite: Confirm that Apache's mod_rewrite module is enabled, as it's essential for Laravel's routing. Enable it with sudo a2enmod rewrite if necessary.

  • Restart Apache: After making changes to the configuration, don't forget to restart Apache using sudo service apache2 restart.

Laravel Configuration:

  • Environment: Make sure the APP_ENV in your .env file is set to production and APP_DEBUG is set to false to avoid exposing sensitive information.

  • Routes: Check your routes with php artisan route:list to ensure they are defined correctly.

  • Config and Route Cache: Clear your config and route cache with php artisan config:clear and php artisan route:clear to make sure Laravel is using the latest configuration.

Permissions:

  • File Permissions: Verify that the web server user (e.g., www-data) has the necessary read and write permissions on the storage and bootstrap/cache directories.

Debugging:

  • Laravel Logs: Increase the verbosity of your Laravel logs by checking the storage/logs/laravel.log file for any errors that might have been missed.

  • Browser Dev Tools: Use the Network tab in your browser's developer tools to inspect the request that's failing. This can provide clues about the issue.

Additional Tips:

  • APP_URL Setting: Use the APP_URL setting in your .env file to specify the full URL of your application, which can affect asset and route generation.

  • Version Control Review: If you're using version control (like Git), review recent changes to configuration files or routes that might have introduced the issue.

  • Load Balancer Configuration: If your deployment includes a load balancer, ensure it's correctly configured to forward requests to your Compute Engine instance(s).

I did most of them and already had most configured as you indicated in the
post would you like to review my code ? to better assist me

for the  APP_URL I added the external ip of the vm 

 when i run this line : php artisan route:list

i get 

   ReflectionException 

 

  Class "App\HTTP\Controllers\pendingcaseController" does not exist

 

  at vendor/laravel/framework/src/Illuminate/Foundation/Console/RouteListCommand.php:234

    230▕             if ($this->isFrameworkController($route)) {

    231▕                 return false;

    232▕             }

    233▕ 

  ➜ 234▕             $path = (new ReflectionClass($route->getControllerClass()))

    235▕                                 ->getFileName();

    236▕         } else {

    237▕             return false;

    238▕         }

 

      +3 vendor frames 

  4   [internal]:0

      Illuminate\Foundation\Console\RouteListCommand::Illuminate\Foundation\Console\{closure}()

 

      +17 vendor frames 

  22  artisan:35

      Illuminate\Foundation\Console\Kernel::handle()

but when i change the folder name app to App i see all the routes but i need to keep it as app in order to get the login screen to load. if it is okay with you would you like to do a teamviewer session with me to better assist me ? I would be very grateful for that 

The error you're seeing with php artisan route:list usually means Laravel can't find your pendingcaseController. This is often due to a mismatch between namespaces, class names, and the way Laravel expects your files to be organized:

  • Namespaces: Laravel's default namespace for your main project code is App\. A controller named pendingcaseController should live within the namespace App\Http\Controllers\pendingcaseController.
  • Case Sensitivity: Many web servers are case-sensitive. "app" and "App" are different folders! Double-check that your directory names and filenames use the correct capitalization.

Here are some trouble shooting steps you can take:

  1. Check Namespace & Class Name: Make sure your controller file is named PendingCaseController.php (note the capitalization) and the class inside is declared as PendingCaseController within the App\Http\Controllers namespace.

  2. Verify Directory: Your controller file should reside in the app/Http/Controllers directory (if you haven't changed the default).

  3. Fix 'app' vs. 'App' Issue: The easiest fix is to rename your app directory to App. If there's a specific reason you need to keep it lowercase, you'll have to delve into more complex configuration changes in composer.json.

  4. Clear Cache & Regenerate Autoload: After any changes, run these commands:

    • php artisan cache:clear
    • composer dump-autoload

thanks for your reply in your statement 

  • Case Sensitivity: Many web servers are case-sensitive. "app" and "App" are different folders! Double-check that your directory names and filenames use the correct capitalization.


    i am very aware of this but as i have indicated when i changed app to App i see the routes list but when i trying to access the login screen i dont get it . on the local machine (windows 10, vs code editors , phpmyadmin, apache) it works i dont know why its different on the compute engine. would you like to schedule some time maybe we can zoom and we can go over it together it would be a great learning opportunity for me 

this sounds more resonable : If there's a specific reason you need to keep it lowercase, you'll have to delve into more complex configuration changes in composer.json.

In a Laravel project, by default, the folder name for the application code (including controllers, models, and other PHP classes) is app, not App

sources: https://laravel.com/docs/5.0/structure

from chatgpt 

Danny69_1-1710289361722.png

 

I mentioned case sensitive as possibility but the error is more likely related to the namespace declaration within your controller file or how you're referencing it in your routes or other parts of your application

The "Class not found" error, specifically "ReflectionException Class 'App\HTTP\Controllers\pendingcaseController' does not exist", typically indicates a mismatch in how your controller is defined versus how it's being referenced. Key areas to check include:

  • Namespace: The namespace at the top of your pendingcaseController.php file should be namespace App\Http\Controllers;. This declaration is crucial for Laravel to locate the file within its directory structure.

  • Class and File Names: PHP conventions dictate the use of PascalCase for class names (e.g., PendingCaseController). The file name must exactly match the class name (PendingCaseController.php), including case sensitivity.

  • Route Definition: In Laravel 8 and later, the way you reference your controller in routes should accurately reflect the namespace and class name.

  • Autoloading: Changes to class organization or naming necessitate running composer dump-autoload to update Laravel's internal class mappings.

Troubleshooting Steps with an Emphasis on Case Sensitivity

  1. Namespace Check:

    • Open pendingcaseController.php.
    • Confirm the namespace is namespace App\Http\Controllers;.
  2. Class and File Name Scrutiny:

    • The class name should be PendingCaseController, adhering to PascalCase.
    • The file name must be PendingCaseController.php. Note that many systems are case-sensitive; thus, pendingcasecontroller.php is not equivalent to PendingCaseController.php.
  3. Route Verification:

    • In your route file, use the following format:
       
       use App\Http\Controllers\PendingCaseController; 
       Route::get('/pending-case', [PendingCaseController::class, 'methodName']); 
      
      • Replace 'methodName' with the actual method name in your controller.
  4. Refresh Autoloading:

    • Execute composer dump-autoload in your terminal.

would you like too check it with me via zoom share screen on the weekend ?

I was doing some debugging and I notice something 

on the compute engine i  added the following line of code in the controller that manages my login 

 

$dbConnection = Config::get('database.default');
$dbConfig = config("database.connections.$dbConnection");
dd($dbConfig);


and I get this

array:13 [ // app/Http/Controllers/AuthManager.php:25
  "driver" => "mysql"
  "url" => null
  "host" => "localhost"
  "port" => "3306"
  "password" => "specialpassword"
  "unix_socket" => ""
  "charset" => "utf8mb4"
  "collation" => "utf8mb4_unicode_ci"
  "prefix" => ""
  "prefix_indexes" => true
  "strict" => true
  "engine" => null
  "options" => []]
notice we did not see database name or username

but when i test the same code on the localhost I see the username and database name listed . so this is can conclude that the database is not being linked properly but the password and all other parameters are correct in the .env file 

The discrepancy you're observing in the configuration array between your local environment and the Compute Engine instance is indeed peculiar, especially since the database name and username are missing in the output on the Compute Engine instance. This suggests an issue with how the .env file or the environment variables are being read or parsed in your production environment. Here are some steps to help you diagnose and resolve this issue:

Potential Causes

Incorrect .env Entries:

  • Typo Check: Carefully check for typos in the .env variables:
    • DB_DATABASE=your_database_name
    • DB_USERNAME=your_database_username
  • Spacing: Ensure there are no extra spaces around the = signs. Note that values should not be surrounded by quotes unless they contain spaces.

Caching:

  • Config Caching: If you've used php artisan config:cache, your application might be relying on cached configuration values. To clear the config cache, run:
     
    php artisan config:clear

Environment Detection:

  • Check Environment Detection: Ensure your Compute Engine environment is correctly detected. A mismatch could lead to incorrect .env values being used.

Troubleshooting Steps

  1. Verify .env File:

    • Double-check your .env file for any typos or incorrect formatting, especially around the DB_DATABASE and DB_USERNAME entries.
    • Confirm the .env file is present in your deployment environment, as it might be excluded by file transfer or version control systems.
  2. Clear Caches:

    • Execute the following commands to ensure all configurations are up-to-date:
       
      php artisan config:clear php artisan cache:clear
  3. Restart Servers (if applicable):

    • Restart your web server and PHP-FPM to apply changes. This is crucial for environments using PHP-FPM with Nginx or Apache. Use a command like sudo systemctl restart php7.4-fpm, adjusting for your PHP version.
  4. Environment Check:

    • Use php artisan tinker and run dump(env('DB_DATABASE')); to directly check if the .env values are correctly loaded by Laravel.

Additional Consideration

  • File Permissions: Verify that the .env file has the correct permissions to be readable by the web server or PHP process.

  • Debugging Tools: Consider using Laravel's logging capabilities (Log::info()) or temporarily inserting dd() at strategic points to verify the application's runtime behavior regarding .env value loading.

in response to : ''he discrepancy you're observing in the configuration array between your local environment and the Compute Engine instance is indeed peculiar, especially since the database name and username are missing in the output on the Compute Engine instance. This suggests an issue with how the .env file or the environment variables are being read or parsed in your production environment. Here are some steps to help you diagnose and resolve this issue:''

I recently fixed this isssue now i see the username and database name 

i tried this line fo code : dump(env('DB_DATABASE'))  i get null in response 

Here are a few potential reasons and solutions for why env('DB_DATABASE') might return null:

1. Configuration Caching

One of the most common reasons for this behavior is Laravel's configuration caching. When you run php artisan config:cache, Laravel caches the configuration values, and subsequent calls to env() outside of configuration files will return null. This is because, with configuration caching enabled, Laravel expects all environment variables to be accessed through the config files rather than directly via env() calls.

Solution: Use the configuration value instead of the environment variable directly. For example, instead of env('DB_DATABASE'), use config('database.connections.mysql.database'). If you need to clear the configuration cache, you can run php artisan config:clear.

2. Incorrect .env File Location or Permissions

If the .env file is not in the root directory of your Laravel project or if it has incorrect permissions, Laravel might not be able to read it properly.

Solution: Ensure the .env file is located in the root directory of your Laravel project and has the correct permissions (usually readable by the web server or PHP process).

3. .env File Parsing Issues

Sometimes, the .env file might have formatting issues that prevent certain variables from being parsed correctly, such as spaces around the = sign or missing values.

Solution: Double-check the .env file for any formatting issues. Ensure there are no spaces around the = sign, and all variables are correctly defined.

4. Overridden Environment Variables

In some server environments or through certain deployment processes, environment variables might be set or overridden at the server level or through other mechanisms outside of the .env file.

Solution: Check your server's environment variable settings and any deployment scripts to ensure they are not overriding the DB_DATABASE value.

5. Laravel Version Specific Issues

If you're using a specific version of Laravel, there might be version-specific issues or changes in how environment variables are handled.

Solution: Check the Laravel release notes for your version for any known issues or changes related to environment variable handling. Updating to the latest version of Laravel might also resolve the issue.

After checking these potential issues, remember to clear your configuration cache (php artisan config:clear) to ensure your changes take effect. If you continue to experience issues, consider reviewing Laravel's documentation on configuration and environment variable handling for further insights.

here is a pic 

post.png

The error message you're encountering when attempting to use Log::info(); in Laravel's Tinker is due to calling the info method without any arguments. The Log::info() method expects at least one argument: the message you want to log. This is why you're seeing the "Too few arguments to function" error.

Regarding the env("DB DATABASE") returning null, it seems there's a typo in your command. Instead of a space, you should use an underscore (_) to match the environment variable name as defined in your .env file. So, it should be env("DB_DATABASE").

Here is how to address both issues:

Correcting the Log::info() Usage

To use Log::info() correctly, you need to pass a message to it. Here's an example:

Log::info('This is a log message.');

This will log the message "This is a log message." to your default log channel, which is typically defined in your config/logging.php file.

Correcting the env() Usage

Make sure you're using the correct environment variable name with underscores instead of spaces. For example:

dump(env("DB_DATABASE"));

This should return the name of your database as defined in your .env file, assuming that your configuration cache isn't causing issues (as mentioned in previous responses, env() calls will return null for any variable if the configuration is cached).

Additional Notes

  • Checking Database Configuration: Your use of config('database.connections.mysql.database') correctly returned the database name ("crf_db"), indicating that your Laravel application is successfully reading the database configuration from your config/database.php file, which in turn reads from the .env file or cached configuration.

  • Typo in config() Calls: Be cautious of typos in your config() calls (e.g., config('database.connectons.mysql. database') seems to have a space before database and misspells connections as connectons). Typos can lead to unexpected null values because Laravel cannot find the specified configuration value.

  • Undefined Configuration Keys: Attempting to access a configuration value that doesn't exist (like config('database.connections.mysql.status')) will return null because there is no status key in the default database connection configuration array.

can we run a live chat on a discord server or maybe zoom, google meets where  I could share my screen with you cause I dont feel comfortable sharing sensitive information on here I sent you a private message some time ago did you find it? it was a link to my discord server. here is a pic of my .env and log attempt on tinker 

tinker.pngenv.png


Based on the output and issues you've encountered while using Laravel Tinker, here is how to address each point:

1. env("DB_DATABASE") Returning null

The env("DB_DATABASE") returning null despite the .env file having a DB_DATABASE entry can be attributed to Laravel's configuration caching. When configuration caching is enabled (php artisan config:cache), direct calls to env() from your code or Tinker will return null because Laravel loads environment variables into configuration values at the time of caching, and then env() calls are not supposed to be used directly outside of configuration files.

Solution: Always access configuration values using the config() helper function instead of env() outside of the config files. For example, use config('database.connections.mysql.database') to get the database name.

2. Logging Attempt in Tinker

Your attempt to log a message using Log::info('this is a log message.') is syntactically correct. If you're not seeing the log entry, ensure you're checking the correct log file based on your LOG_CHANNEL setting. Since your .env shows LOG_CHANNEL=stack, Laravel logs messages in the storage/logs directory, typically within a file named laravel.log.

3. Parse Error in Tinker

The parse error you encountered (PARSE ERROR PHP Parse error: Syntax error, unexpected T_ENCAPSED AND_WHITESPACE) seems to be caused by a syntax mistake in your Tinker command. Ensure your commands are syntactically correct and try again. For example, the correct syntax to retrieve the database name from the configuration would be:

config('database.connections.mysql.database')

4. Correcting .env File Entries

Your .env file snippet shows some variables with spaces around the = sign (e.g., APP_DEBUG= true). The correct format for .env entries does not include spaces around the equals sign. It should be like APP_DEBUG= true. Ensure your .env file follows this format to avoid issues.

5. After Making Changes to .env

After making any changes to your .env file:

  • Run php artisan config:clear to clear the configuration cache.

  • Run php artisan cache:clear to clear the application cache.

  • Optionally, if you're in a local or safe development environment, you can run php artisan config:cache to regenerate the configuration cache with the updated values.

6. Verifying Log Entries

To verify that logging works as expected, after running Log::info('this is a log message.'); in Tinker, check the storage/logs/laravel.log file for the new log entry. Ensure you have the necessary permissions to view and modify files in the storage/logs directory.

Adjust your .env file to correct the format, use config() instead of env() for accessing configuration values, especially after caching the configuration, and ensure your Tinker commands are syntactically correct to avoid parse errors.

I did as you said here. I made the changes you described however using tinker again after cleaning the cache and config.I still get null when i try to log a message but in the sotrage/logs/laravel.log  I see the log messages 

logs.JPG

It looks like you've successfully resolved the issue with logging messages in Laravel. The fact that you're seeing the log messages in storage/logs/laravel.log confirms that the Log::info() method is working as expected. The null you see in Tinker after executing Log::info('this is a log message.'); is normal and not indicative of a problem. In Laravel Tinker, when you execute a command or call a method that doesn't return a value (or returns null), Tinker will display null. This behavior is by design and is simply Tinker's way of indicating that the command was executed without a return value.

Here is what's happening:

  • Logging Works: Your log messages are correctly written to the log file, which means the logging system is configured and working as expected.

  • Tinker's Output: When you use Log::info(), it doesn't return a value (or more accurately, it returns null), which is why Tinker displays null. This doesn't mean the logging failed; it's just how Tinker represents the absence of a return value.

  • Logging is Functional: You can confidently use Laravel's logging features in your application. The presence of log entries in storage/logs/laravel.log is proof of successful logging.

  • Understanding Tinker Output: Remember that null in Tinker's output doesn't necessarily indicate an error; it often just means a command didn't return a value. This is expected behavior for many methods, including logging.

well I now learned something new today. I am avaliable. if you are free I could give you access to my discord server where you can help me get to the bottom of the problem. here is an invite : https://discord.gg/3w3qZByu

I made a break through in sucessfully connecting the laravel app to the database on compute engine . I can query the db from the app . so it is a sign that it is connected . however I still get the same issues after adding the dd("hello from login controller"); 

i did not get result it just went to 

Not Found

The requested URL was not found on this server.


Apache/2.4.52 (Ubuntu) Server at 34.171.170.110 Port 80

i think the issues is related to the routing  

Given that you have been able to connect the Laravel application to the database on the Compute Engine and still encountering a "Not Found" error after adding dd("hello from login controller");, it indeed suggests that the issue might be related to routing or the web server configuration rather than the database connection.

Troubleshooting Steps:

  1. Verify Laravel Routes:

    • Carefully examine your routes in routes/web.php or routes/api.php.
    • Use the php artisan route:list command to get a clear list of all registered routes. Make sure your login route is defined correctly.
  2. Check Controller Namespace:

    • If your route is fine, ensure the namespace of your controller is accurate, especially if it's located in a non-standard place.
  3. Review .htaccess (for Apache):

    • Make sure you have the correct .htaccess file in your Laravel's public directory.
    • Verify that its contents match the standard Laravel .htaccess file (see below).
  4. Enable mod_rewrite (Apache):

    • Run sudo a2enmod rewrite.
    • Restart Apache: sudo systemctl restart apache2.
  5. Document Root Configuration (Apache):

    • In your Apache configuration, ensure the DocumentRoot points to your Laravel application's public directory.
    • Verify that the <Directory> block for your project has AllowOverride All.
  6. Clear Laravel Caches:

    • php artisan config:clear
    • php artisan route:clear
    • php artisan cache:clear
  7. Check for Typos:

    • Look for potential typos in route definitions, controller names, or method names.

Example .htaccess file (Apache):

 
<IfModule mod_rewrite.c>
   <IfModule mod_negotiation.c>
       Options -MultiViews -Indexes
   </IfModule>

   RewriteEngine On

   # Redirect Trailing Slashes...
   RewriteRule ^(.*)/$ /$1 [L,R=301]

   # Handle Front Controller...
   RewriteCond %{REQUEST_FILENAME} !-d
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteRule ^ index.php [L]
</IfModule> 

I did all of that and still no luck 
/etc/apache2/sites-enabled$ cat 000-default.conf
<VirtualHost *:79>
# The ServerName directive sets the request scheme, hostname and port that
# the server uses to identify itself. This is used when creating
# redirection URLs. In the context of virtual hosts, the ServerName
# specifies what hostname must appear in the request's Host: header to
# match this virtual host. For the default virtual host (this file) this
# value is not decisive as it is used as a last resort host regardless.
# However, you must set it for any further virtual host explicitly.
#ServerName www.example.com

ServerAdmin webmaster@localhost
DocumentRoot /var/www/html/public

<Directory /var/www/html/public>
AllowOverride All
Require all granted
</Directory>

# Available loglevels: trace8, ..., trace1, debug, info, notice, warn,
# error, crit, alert, emerg.
# It is also possible to configure the loglevel for particular
# modules, e.g.
#LogLevel info ssl:warn

ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log combined

# For most configuration files from conf-available/, which are
# enabled or disabled at a global level, it is possible to
# include a line for only one particular virtual host. For example the
# following line enables the CGI configuration for this host only
# after it has been globally disabled with "a2disconf".
#Include conf-available/serve-cgi-bin.conf
</VirtualHost>

# vim: syntax=apache ts=4 sw=4 sts=4 sr noet



 

Based on the configuration you've shared, there are a couple of points that stand out and could potentially be causing the issue:

Your Apache configuration snippet shows <VirtualHost *:79>, which means Apache is listening on port 79 for this virtual host. This is unusual because HTTP traffic typically runs over port 80 (or port 443 for HTTPS). Unless you have a specific reason for using port 79 and have configured your network and application to use this port, this might be the source of the problem.

Solution: If you intended to use the standard HTTP port, change the VirtualHost directive to listen on port 80:

 
<VirtualHost *:80>

After making this change, restart Apache to apply the configuration:

 
sudo systemctl restart apache2

If you're using a non-standard port by design, ensure that your requests to the Laravel application are explicitly targeting port 79 (e.g., http://34.171.170.110:79). If not, and there's no specific reason to use port 79, switching back to the default port 80 (as mentioned above) is recommended.

Check Apache and Laravel Logs

  • Apache Logs: Check the Apache error logs (${APACHE_LOG_DIR}/error.log) for any specific errors that could indicate why the request was not found. The error log might provide more details on what's going wrong.

  • Laravel Logs: Also, review the Laravel application logs in storage/logs/laravel.log for any application-specific errors that might not be related to Apache but could cause the routing to fail.

Ensure Apache and PHP are Correctly Configured

  • PHP Module: Ensure that the PHP module is enabled in Apache. You can check this by running a2enmod php<version> (replace <version> with your PHP version, e.g., php7.4).

  • Server Restart: Every time you change the Apache configuration or enable a module, remember to restart Apache to apply the changes.

Firewall or Port Blocking

  • If you're using a non-standard port (like 79), ensure that your server's firewall or any network firewalls (including cloud provider firewalls) are configured to allow traffic on that port.

If the issue persists after verifying the port and ensuring Apache is correctly configured and restarted, consider simplifying the setup to diagnose the problem:

  • Static HTML File: Temporarily place a simple index.html file in the /var/www/html/public directory with basic content (e.g., <h1>Hello World</h1>) and try accessing it via your browser. This can help confirm whether the issue lies with Apache serving files from the DocumentRoot or if it's more related to Laravel's routing.

when i change it to 80 

i get :

404
NOT FOUND

apache error logs 

/var/log/apache2$ cat error.log
[Wed Mar 27 00:00:15.522399 2024] [mpm_prefork:notice] [pid 36887] AH00163: Apache/2.4.52 (Ubuntu) configured -- resuming normal operations
[Wed Mar 27 00:00:15.522530 2024] [core:notice] [pid 36887] AH00094: Command line: '/usr/sbin/apache2'
[Wed Mar 27 06:08:17.083345 2024] [php:error] [pid 42882] [client 159.89.171.190:54594] script '/var/www/html/upl.php' not found or unable to stat
[Wed Mar 27 06:08:19.035019 2024] [php:error] [pid 42886] [client 159.89.171.190:54634] script '/var/www/html/1.php' not found or unable to stat
[Wed Mar 27 06:08:20.982714 2024] [php:error] [pid 42883] [client 159.89.171.190:33340] script '/var/www/html/password.php' not found or unable to stat
[Wed Mar 27 06:08:21.468143 2024] [php:error] [pid 42884] [client 159.89.171.190:33350] script '/var/www/html/info.php' not found or unable to stat
[Wed Mar 27 08:27:04.902661 2024] [php:error] [pid 42886] [client 83.97.73.245:48246] script '/var/www/html/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php' not found or unable to stat
[Wed Mar 27 08:32:01.629545 2024] [php:error] [pid 45493] [client 83.97.73.245:40722] script '/var/www/html/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php' not found or unable to stat
[Wed Mar 27 19:38:23.498199 2024] [mpm_prefork:notice] [pid 36887] AH00170: caught SIGWINCH, shutting down gracefully
[Wed Mar 27 19:38:23.673514 2024] [mpm_prefork:notice] [pid 123697] AH00163: Apache/2.4.52 (Ubuntu) configured -- resuming normal operations
[Wed Mar 27 19:38:23.673624 2024] [core:notice] [pid 123697] AH00094: Command line: '/usr/sbin/apache2'
[Wed Mar 27 20:53:17.151001 2024] [mpm_prefork:notice] [pid 123697] AH00170: caught SIGWINCH, shutting down gracefully
[Wed Mar 27 20:53:17.290753 2024] [mpm_prefork:notice] [pid 128178] AH00163: Apache/2.4.52 (Ubuntu) configured -- resuming normal operations
[Wed Mar 27 20:53:17.290872 2024] [core:notice] [pid 128178] AH00094: Command line: '/usr/sbin/apache2'

laravel logs

[stacktrace]
#0 /var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Console/RouteListCommand.php(234): ReflectionClass->__construct()
#1 /var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Console/RouteListCommand.php(156): Illuminate\\Foundation\\Console\\RouteListCommand->isVendorRoute()
#2 /var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Console/RouteListCommand.php(125): Illuminate\\Foundation\\Console\\RouteListCommand->getRouteInformation()
#3 [internal function]: Illuminate\\Foundation\\Console\\RouteListCommand->Illuminate\\Foundation\\Console\\{closure}()
#4 /var/www/html/vendor/laravel/framework/src/Illuminate/Collections/Arr.php(560): array_map()
#5 /var/www/html/vendor/laravel/framework/src/Illuminate/Collections/Collection.php(768): Illuminate\\Support\\Arr::map()
#6 /var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Console/RouteListCommand.php(124): Illuminate\\Support\\Collection->map()
#7 /var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Console/RouteListCommand.php(110): Illuminate\\Foundation\\Console\\RouteListCommand->getRoutes()
#8 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(36): Illuminate\\Foundation\\Console\\RouteListCommand->handle()
#9 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/Util.php(41): Illuminate\\Container\\BoundMethod::Illuminate\\Container\\{closure}()
#10 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(93): Illuminate\\Container\\Util::unwrapIfClosure()
#11 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/BoundMethod.php(35): Illuminate\\Container\\BoundMethod::callBoundMethod()
#12 /var/www/html/vendor/laravel/framework/src/Illuminate/Container/Container.php(661): Illuminate\\Container\\BoundMethod::call()
#13 /var/www/html/vendor/laravel/framework/src/Illuminate/Console/Command.php(183): Illuminate\\Container\\Container->call()
#14 /var/www/html/vendor/symfony/console/Command/Command.php(326): Illuminate\\Console\\Command->execute()
#15 /var/www/html/vendor/laravel/framework/src/Illuminate/Console/Command.php(152): Symfony\\Component\\Console\\Command\\Command->run()
#16 /var/www/html/vendor/symfony/console/Application.php(1078): Illuminate\\Console\\Command->run()
#17 /var/www/html/vendor/symfony/console/Application.php(324): Symfony\\Component\\Console\\Application->doRunCommand()
#18 /var/www/html/vendor/symfony/console/Application.php(175): Symfony\\Component\\Console\\Application->doRun()
#19 /var/www/html/vendor/laravel/framework/src/Illuminate/Console/Application.php(102): Symfony\\Component\\Console\\Application->run()
#20 /var/www/html/vendor/laravel/framework/src/Illuminate/Foundation/Console/Kernel.php(155): Illuminate\\Console\\Application->run()
#21 /var/www/html/artisan(35): Illuminate\\Foundation\\Console\\Kernel->handle()
#22 {main}
"}

wait I think I got it to work cause i placed a dd() in the login controller and I saw it responed

If you are not able to clear the cache of the application from command line, then you can also delete this cache files and folders manually, for this you follow the guide:(URL Removed by Staff)