+
+### (OPTIONAL) Reverse-proxying and HTTPS
+
+Friendica looks for some well-known HTTP headers indicating a reverse-proxy
+terminating an HTTPS connection.
+While the standard from RFC 7239 specifies the use of the `Forwarded` header.
+
+ Forwarded: for=192.0.2.1; proto=https; by=192.0.2.2
+
+Friendica also supports a number on non-standard headers in common use.
+
+ X-Forwarded-Proto: https
+
+ Front-End-Https: on
+
+ X-Forwarded-Ssl: on
+
+It is however preferable to use the standard approach if configuring a new server.
+
+## Troubleshooting
+
+### "System is currently unavailable. Please try again later"
+
+Check your database settings.
+It usually means your database could not be opened or accessed.
+If the database resides on the same machine, check that the database server name is "localhost".
+
+### 500 Internal Error
+
+This could be the result of one of our Apache directives not being supported by your version of Apache. Examine your apache server logs.
+You might remove the line "Options -Indexes" from the `.htaccess` file if you are using a Windows server as this has been known to cause problems.
+Also check your file permissions. Your website and all contents must generally be world-readable.
+
+It is likely that your web server reported the source of the problem in its error log files.
+Please review these system error logs to determine what caused the problem.
+Often this will need to be resolved with your hosting provider or (if self-hosted) your web server configuration.
+
+### 400 and 4xx "File not found" errors
+
+First check your file permissions.
+Your website and all contents must generally be world-readable.
+
+Ensure that mod-rewite is installed and working, and that your `.htaccess` file
+is being used. To verify the latter, create a file `test.out` containing the
+word "test" in the top directory of Friendica, make it world readable and point
+your web browser to
+
+ http://yoursitenamehere.com/test.out
+
+This file should be blocked. You should get a permission denied message.
+
+If you see the word "test" your Apache configuration is not allowing your
+`.htaccess` file to be used (there are rules in this file to block access to any
+file with .out at the end, as these are typically used for system logs).
+
+Make certain the `.htaccess` file exists and is readable by everybody, then look
+for the existence of "AllowOverride None" in the Apache server configuration for your site.
+This will need to be changed to "AllowOverride All".
+
+If you do not see the word "test", your `.htaccess` is working, but it is likely
+that mod-rewrite is not installed in your web server or is not working.
+
+On most Linux flavors:
+
+ % a2enmod rewrite
+ % /etc/init.d/apache2 restart
+
+Consult your hosting provider, experts on your particular Linux distribution or
+(if Windows) the provider of your Apache server software if you need to change
+either of these and can not figure out how. There is a lot of help available on
+the web. Search "mod-rewrite" along with the name of your operating system
+distribution or Apache package (if using Windows).
+
+### Unable to write the file config/local.config.php due to permissions issues
+
+Create an empty `config/local.config.php`file and apply world-write permission.
+
+On Linux:
+
+ % touch config/local.config.php
+ % chmod 664 config/local.config.php
+
+Retry the installation. As soon as the database has been created,
+
+******* this is important *********
+
+ % chmod 644 config/local.config.php
+
+### Suhosin issues
+
+Some configurations with "suhosin" security are configured without an ability to
+run external processes. Friendica requires this ability. Following are some notes
+provided by one of our members.
+
+> On my server I use the php protection system Suhosin [http://www.hardened-php.net/suhosin/].
+> One of the things it does is to block certain functions like proc_open, as
+> configured in `/etc/php5/conf.d/suhosin.ini`:
+>
+> suhosin.executor.func.blacklist = proc_open, ...
+>
+> For those sites like Friendica that really need these functions they can be
+> enabled, e.g. in `/etc/apache2/sites-available/friendica`:
+>
+> <Directory /var/www/friendica/>
+> php_admin_value suhosin.executor.func.blacklist none
+> php_admin_value suhosin.executor.eval.blacklist none
+> </Directory>
+>
+> This enables every function for Friendica if accessed via browser, but not for
+> the cronjob that is called via php command line. I attempted to enable it for
+> cron by using something like:
+>
+> */10 * * * * cd /var/www/friendica/friendica/ && sudo -u www-data /usr/bin/php \
+> -d suhosin.executor.func.blacklist=none \
+> -d suhosin.executor.eval.blacklist=none -f bin/worker.php
+>
+> This worked well for simple test cases, but the friendica-cron still failed
+> with a fatal error:
+>
+> suhosin[22962]: ALERT - function within blacklist called: proc_open()
+> (attacker 'REMOTE_ADDR not set', file '/var/www/friendica/friendica/boot.php',
+> line 1341)
+>
+> After a while I noticed, that `bin/worker.php` calls further PHP script via `proc_open`.
+> These scripts themselves also use `proc_open` and fail, because they are NOT
+> called with `-d suhosin.executor.func.blacklist=none`.
+>
+> So the simple solution is to put the correct parameters into `config/local.config.php`:
+>
+> 'config' => [
+> //Location of PHP command line processor
+> 'php_path' => '/usr/bin/php -d suhosin.executor.func.blacklist=none \
+> -d suhosin.executor.eval.blacklist=none',
+> ],
+>
+> This is obvious as soon as you notice that the friendica-cron uses `proc_open`
+> to execute PHP scripts that also use `proc_open`, but it took me quite some time to find that out.
+> I hope this saves some time for other people using suhosin with function blocklists.
+
+### Unable to create all mysql tables on MySQL 5.7.17 or newer
+
+If the setup fails to create all the database tables and/or manual creation from
+the command line fails, with this error:
+
+ ERROR 1067 (42000) at line XX: Invalid default value for 'created'
+
+You need to adjust your my.cnf and add the following setting under the [mysqld]
+section:
+
+ sql_mode = '';
+
+After that, restart mysql and try again.
+
+### Your worker never or rarely runs
+
+Friendica is coded to always play nice.
+It checks whether the host machine is idle enough and if it _seems_ to be overloaded, it intermittently refuses to process the worker queue.
+
+Such checks originate from the days of single-user single-core machines and involves thresholds that you should adjust based on the number of exclusive CPU cores you have.
+See this issue for more information:
+
+* https://github.com/friendica/friendica/issues/10131
+
+If you want to be neighborly and are using a shared web hosting PaaS provider, especially within the free tier, you need to set `maxloadavg` to say twice the maximum value of `/proc/loadavg` during peak hours.
+
+If you have the whole (virtual) machine for yourself such as in case of an IaaS VPS, you can set it to orders of magnitude higher than its commonly observed value, such as 1000.
+
+You should instead enact limits in your web server configuration based on the number of entry processes to cap the concurrent memory usage of your PHP processes.
+See `RLimitMEM`, `RLimitCPU`, `RLimitNPROC`, `StartServers`, `ServerLimit`, `MaxRequestsPerChild`, `pm.max_children`, `pm.start_servers` and related options in your server.
+
+### Error uploading even small image files
+
+You tried to upload an image up to 100kB and it failed.
+
+You may not have the ownership or file mode set correctly if you are using the file system storage backend.
+
+Change the backend to database.
+If this solves it, that is what needs to be fixed.
+
+Verify in your PHP ini:
+
+* `file_uploads`: should be `1`
+* `upload_tmp_dir`: should be writable (falls back to system default temp) and not blocked by `open_basedir`
+
+### Error uploading large files
+
+You may find `413 Request Entity Too Large` or `500 Internal Error` in the network inspector of the browser if the file is too large, for example if it is a video.
+
+First try to upload a very small file, up to 100kB.
+If that succeeds, you will need to increase limits at multiple places, including on any web proxy that you are using.
+Which one applies to you depends on your installation.
+
+In your PHP ini:
+
+* `upload_max_filesize`: defaults to 2MB
+* `post_max_size`: defaults to 8MB, must be greater than `upload_max_filesize`
+* `memory_limit`: defaults to 128MB, must be greater than `post_max_size`
+* `max_input_time`: time limit of an upload, defaults to -1, meaning it uses `max_execution_time` instead
+* `max_execution_time`: defaults to 30 seconds, should be enough if you also set `max_input_time`
+
+You should verify whether you changed them in the _right file_ by checking the web interface at the end of the overview on the `Admin` panel.
+
+In your Apache2 config:
+
+* `LimitRequestBody`: defaults to unlimited
+* `FcgidMaxRequestLen`: defaults to 128kB
+* `SSLRenegBufferSize`: defaults to 128kB, only if your site uses TLS and perhaps only when using `SSLVerifyClient` or `SSLVerifyDepth`
+* Remove `LoadModule reqtimeout_module modules / mod_reqtimeout.so` or adjust `RequestReadTimeout`: defaults to 20 seconds and >= 500 byte/second
+
+In your nginx config:
+
+* `client_max_body_size`: defaults to 1MB
+
+If you are using the database backend for storage, increase this in your SQL configuration:
+
+* `max_allowed_packet`: defaults to 32MB
+
+In your ModSecurity WAF config:
+
+* `SecRequestBodyLimit`: defaults to 12MB
+* `SecRequestBodyNoFilesLimit`: defaults to 128kB, should not apply to Friendica
+
+In the end, you will need to restart all services that you have changed configuration for.
+If you don't know which ones these are, just reboot.
+
+### Diaspora support is not activated
+
+You get this error when you try to add a Diaspora contact.
+
+You can enable it from the web interface in `Admin -> Site -> Policies -> Enable diaspora* support`.
+You may also set it manually in the config file or in the database within the `diaspora_enabled` key of the `system` category.
+
+### Upgrade failed due to DB migration timeout
+
+Altering of a table may fail if it contains a large number of rows.
+First verify the existing timeout (50s by default):
+
+`show global variables like "innodb_lock_wait_timeout";`
+
+Then increase it:
+
+`set global innodb_lock_wait_timeout=600;`