Http error 504 zimbra

Ошибка при отправке почты в Zimbra

Столкнулись с такой проблемой. При отправке почты подвисает веб-морда, выдает ошибку данного содержания.

Ошибка сети. method: SendMsgRequest msg: Ошибка сети. code: CSFE_SVC_ERROR detail: HTTP response status 504

Подскажите, что делать в такой ситуации?

Версия зимбры? Что меняли?

Версия 8.6. Не меняли ничего. Тупо установили.

И зачем сейчас ставить изначально старую версию, внедряли бы уже 8.7

Смотреть общий ход в смысле. Логи нгинкса, прокси самой зимбры.

Нашел интересный вариант решения. 504 Gateway Timeout: The most common reason for this is that the upstream mailstore server took longer than the configured timeout value and hence the client closed the upstream connection. Try changing the timeout values to a higher value if its expected to take longer for specific kind of requests.

Я так понимаю, что здесь рекомендуется изменить таймаут на более высокое значение. Не подскажите, как это сделать?

Источник

Http error 504 zimbra

Post by SecretiveNickname » Wed May 10, 2017 11:13 am

Hello Forum

we are running Release 8.7.7.GA.1787.UBUNTU14.64 UBUNTU14_64 FOSS edition currently on a single Amazon EC2 instance. We are experiencing some Errors in the WebUI, see Screenshot attached. We are getting this Error in the WebUI when trying to view emails every now and then (around once a day). We have around 25 people working with the zimbra in our office. We also installed zextras.

We found this thread viewtopic.php?t=60298 and tried to disable the DOS filter like so:

$ zmprov mcf +zimbraHttpThrottleSafeIPs 1.2.3.4/32

But it did not help Some more info on the subject: https://wiki.zextras.com/wiki/ZeXtras_S . _DoSFilter and https://wiki.zimbra.com/wiki/DoSFilter

The nginx log shows logs like these when the error occures:

1.2.3.4:55286 — — [10/May/2017:11:10:06 +0200] «POST /service/soap/BatchRequest HTTP/1.1» 502 1332 «https://mail.example.com/» «Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.81 Safari/537.36» «»

Re: 8.7.7 FOSS: CSFE_SVC_ERROR HTTP response status 504 when viewing Mails in the WebUI

Post by SecretiveNickname » Wed May 10, 2017 1:37 pm

As the screenshot upload didn’t seem to work out, here is the error message we get in the Browser (I translated it from german)

Error in the network service
method: Search request
code: CSFE_SVC_ERROR
detail: HTTP response status 504

Источник

Http error 504 zimbra

Post by Hardijs » Wed Jul 27, 2016 2:14 pm

Please help to resolve a problem, why 2x — 3x times a day Zimbra webmail issued 504 error.

We use Zimbra Release 8.6.0.GA.1153.FOSS on UBUNTU14_64 edition (ProxMox enviroment) with Zextras ZxMobile. All installations we made as Zimbras wiki suggested and hardware comply with min requirements. When user tries to open the Zimbras webmail page and 504 error occurs, at this time previously opened sessions and mobile sync (through Zextras Zxmobile) still works. Also is not possible to connect Zimbra directly through 8443 port without proxy ( https://FQDN:8443 ) and only after «zmmailboxdctl restart» the webmail starts working again. During this time we observed one process:

/opt/zimbra/java/bin/java -Dfile.encoding=UTF-8 -server -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -Djdk.tls.client.protocols=TLSv1,TLSv1.1,TLSv1.2 -Djava.awt.headless=true -Dsun.net.inetaddr.ttl=60 -Dorg.apache.jasper.compiler.disablejsr199=true -XX:+UseConcMarkSweepGC -XX:PermSize=128m -XX:MaxPermSize=350m -XX:SoftRefLRUPolicyMSPerMB=1 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime -XX:-OmitStackTraceInFastThrow -Xloggc:/opt/zimbra/log/gc.log -XX:-UseGCLogFileRotation -XX:NumberOfGCLogFiles=20 -XX:GCLogFileSize=4096K -Djava.net.preferIPv4Stack=true -Xss256k -Djava.security.krb5.conf=/opt/zimbra/mailboxd/etc/krb5.ini -Djava.security.auth.login.config=/opt/zimbra/mailboxd/etc/spnego.conf -Djavax.security.auth.useSubjectCredsOnly=false -Xms256m -Xmx256m -Xmn64m -Djava.io.tmpdir=/opt/zimbra/mailboxd/work -Djava.library.path=/opt/zimbra/lib -Djava.endorsed.dirs=/opt/zimbra/mailboxd/common/endorsed -Dzimbra.config=/opt/zimbra/conf/localconfig.xml -Djetty.home=/opt/zimbra/mailboxd -DSTART=/opt/zimbra/mailboxd/etc/start.config -jar /opt/zimbra/mailboxd/start.jar —module=zimbra,server,servlet,servlets,jsp,jmx,resources,websocket,ext,plus,rewrite,monitor,continuation,webapp,setuid jetty.home=/opt/zimbra/mailboxd /opt/zimbra/mailboxd/etc/jetty.xml

totally loaded 3-5 cpu cores out of 8, but RAM remains unchanged (we even tried to increase the RAM up to 16GB, but, of course nothing changed).
If we kill this process, then webmail start working again.
Typically, such a situation occurs at the beginning of a working day and around the lunch time, but there have also been cases after working hours.
We reviewed all the log files to find some explanation for the problem, but did not find anything.

What could be the reason? Maybe someone had similar problem?

Re: Zimbra webmail issued 504 error

Post by tushar.niras » Thu Jul 28, 2016 12:50 am

Hardijs wrote: Please help to resolve a problem, why 2x — 3x times a day Zimbra webmail issued 504 error.

We use Zimbra Release 8.6.0.GA.1153.FOSS on UBUNTU14_64 edition (ProxMox enviroment) with Zextras ZxMobile. All installations we made as Zimbras wiki suggested and hardware comply with min requirements. When user tries to open the Zimbras webmail page and 504 error occurs, at this time previously opened sessions and mobile sync (through Zextras Zxmobile) still works. Also is not possible to connect Zimbra directly through 8443 port without proxy ( https://FQDN:8443 ) and only after «zmmailboxdctl restart» the webmail starts working again. During this time we observed one process:

/opt/zimbra/java/bin/java -Dfile.encoding=UTF-8 -server -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2 -Djdk.tls.client.protocols=TLSv1,TLSv1.1,TLSv1.2 -Djava.awt.headless=true -Dsun.net.inetaddr.ttl=60 -Dorg.apache.jasper.compiler.disablejsr199=true -XX:+UseConcMarkSweepGC -XX:PermSize=128m -XX:MaxPermSize=350m -XX:SoftRefLRUPolicyMSPerMB=1 -verbose:gc -XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintGCApplicationStoppedTime -XX:-OmitStackTraceInFastThrow -Xloggc:/opt/zimbra/log/gc.log -XX:-UseGCLogFileRotation -XX:NumberOfGCLogFiles=20 -XX:GCLogFileSize=4096K -Djava.net.preferIPv4Stack=true -Xss256k -Djava.security.krb5.conf=/opt/zimbra/mailboxd/etc/krb5.ini -Djava.security.auth.login.config=/opt/zimbra/mailboxd/etc/spnego.conf -Djavax.security.auth.useSubjectCredsOnly=false -Xms256m -Xmx256m -Xmn64m -Djava.io.tmpdir=/opt/zimbra/mailboxd/work -Djava.library.path=/opt/zimbra/lib -Djava.endorsed.dirs=/opt/zimbra/mailboxd/common/endorsed -Dzimbra.config=/opt/zimbra/conf/localconfig.xml -Djetty.home=/opt/zimbra/mailboxd -DSTART=/opt/zimbra/mailboxd/etc/start.config -jar /opt/zimbra/mailboxd/start.jar —module=zimbra,server,servlet,servlets,jsp,jmx,resources,websocket,ext,plus,rewrite,monitor,continuation,webapp,setuid jetty.home=/opt/zimbra/mailboxd /opt/zimbra/mailboxd/etc/jetty.xml

totally loaded 3-5 cpu cores out of 8, but RAM remains unchanged (we even tried to increase the RAM up to 16GB, but, of course nothing changed).
If we kill this process, then webmail start working again.
Typically, such a situation occurs at the beginning of a working day and around the lunch time, but there have also been cases after working hours.
We reviewed all the log files to find some explanation for the problem, but did not find anything.

What could be the reason? Maybe someone had similar problem?

This issue seems really confusing but I will try my best. Can you please verify following checklist:

Источник

Http error 504 zimbra

Post by eaperezh » Tue May 28, 2019 6:53 pm

Good day,
Server: Quad core 3.20Ghz
Ram: 8GB
users while testing: none logged in

after upgrading from 8.6 to 8.12 the AJAX clients can login and see/read emails, but cannot send.
While trying to send the following popup appears:

The server or the network is slow to respond. to cancel your request, press Cancel Request.
A network service error has ocurred
method: SendMsgRequest
msg: Se ha producido un error en el servicio de red.
code: CSFE_SVC_ERROR
detail: HTTP response status 504

Also, in the nginx.log

[zimbra@correo tmp]$ tail /opt/zimbra/log/nginx.log
2019/05/28 13:46:53 [info] 8896#0: *25323 epoll_wait() reported that client prematurely closed connection, so upstream connection is closed too while sending request to upstream, client: 172.16.1.5, server: correo.binal.ac.pa, request: «POST /service/soap/SendMsgRequest HTTP/1.1», upstream: «https://172.16.1.7:7443/service/soap/SendMsgRequest», host: «correo.binal.ac.pa»
2019/05/28 13:46:53 [warn] 8894#0: *25332 a client request body is buffered to a temporary file /opt/zimbra/data/tmp/nginx/client/0000000174, client: 172.16.1.5, server: correo.binal.ac.pa, request: «POST /service/upload?fmt=raw HTTP/1.1», host: «correo.binal.ac.pa»
2019/05/28 13:47:01 [info] 8894#0: *25335 client 172.16.1.5 closed keepalive connection
2019/05/28 13:47:20 [info] 8892#0: *25162 epoll_wait() reported that client prematurely closed connection, so upstream connection is closed too while sending request to upstream, client: 172.16.1.5, server: correo.binal.ac.pa, request: «POST /service/soap/NoOpRequest HTTP/1.1», upstream: «https://172.16.1.7:7443/service/soap/NoOpRequest», host: «correo.binal.ac.pa», referrer: «https://correo.binal.ac.pa/zimbra/»
2019/05/28 13:47:23 [info] 8894#0: *25332 epoll_wait() reported that client prematurely closed connection, so upstream connection is closed too while sending request to upstream, client: 172.16.1.5, server: correo.binal.ac.pa, request: «POST /service/soap/SendMsgRequest HTTP/1.1», upstream: «https://172.16.1.7:7443/service/soap/SendMsgRequest», host: «correo.binal.ac.pa»
2019/05/28 13:47:23 [warn] 8894#0: *25341 a client request body is buffered to a temporary file /opt/zimbra/data/tmp/nginx/client/0000000175, client: 172.16.1.5, server: correo.binal.ac.pa, request: «POST /service/upload?fmt=raw HTTP/1.1», host: «correo.binal.ac.pa»
2019/05/28 13:47:34 [info] 8892#0: *25347 client closed connection while waiting for request, client: 172.16.1.5, server: 0.0.0.0:443
2019/05/28 13:47:34 [info] 8892#0: *25344 client 172.16.1.5 closed keepalive connection
2019/05/28 13:47:53 [info] 8894#0: *25341 epoll_wait() reported that client prematurely closed connection, so upstream connection is closed too while sending request to upstream, client: 172.16.1.5, server: correo.binal.ac.pa, request: «POST /service/soap/SendMsgRequest HTTP/1.1», upstream: «https://172.16.1.7:7443/service/soap/SendMsgRequest», host: «correo.binal.ac.pa»
2019/05/28 13:48:23 [info] 8894#0: *25365 epoll_wait() reported that client prematurely closed connection, so upstream connection is closed too while sending request to upstream, client: 172.16.1.5, server: correo.binal.ac.pa, request: «POST /service/soap/SendMsgRequest HTTP/1.1», upstream: «https://172.16.1.7:7443/service/soap/SendMsgRequest», host: «correo.binal.ac.pa»
[zimbra@correo tmp]$

Also, in zmmailboxd.out

[zimbra@correo tmp]$ tail /opt/zimbra/log/zmmailboxd.out
[32075.986s][info][gc] GC(129) Pause Young (Normal) (GCLocker Initiated GC) 730M->241M(1972M) 52.900ms
[32334.139s][info][gc] GC(130) Pause Young (Normal) (G1 Evacuation Pause) 729M->245M(1972M) 44.564ms
2019-05-28 13:27:41.966:WARN:oejh.HttpParser:qtp1647809929-4237: parse exception: java.lang.IllegalStateException: too much data seeking EOF in CLOSE for HttpChannelOverHttp@4de941d7
[32576.519s][info][gc] GC(131) Pause Young (Normal) (G1 Evacuation Pause) 721M->244M(1972M) 58.943ms
2019-05-28 13:31:15.233:WARN:oejh.HttpParser:qtp1647809929-4282: parse exception: java.lang.IllegalStateException: too much data seeking EOF in CLOSE for HttpChannelOverHttp@3f94fdab
[32834.787s][info][gc] GC(132) Pause Young (Normal) (G1 Evacuation Pause) 731M->251M(1972M) 88.410ms
[33021.483s][info][gc] GC(133) Pause Young (Normal) (G1 Evacuation Pause) 722M->245M(1972M) 63.917ms
2019-05-28 13:38:49.032:WARN:oejh.HttpParser:qtp1647809929-4391: parse exception: java.lang.IllegalStateException: too much data seeking EOF in CLOSE for HttpChannelOverHttp@2ed7fd1a
2019-05-28 13:42:21.046:WARN:oejh.HttpParser:qtp1647809929-4415: parse exception: java.lang.IllegalStateException: too much data seeking EOF in CLOSE for HttpChannelOverHttp@19dca78f
[33583.578s][info][gc] GC(134) Pause Young (Normal) (G1 Evacuation Pause) 721M->246M(1972M) 68.033ms
[zimbra@correo tmp]$

I have enabled proxy on the web part. This is a default install with no parameters changed during upgrade.
Connecting from LAN allows me to open the AJAX client. But connecting from WAN gives timeouts. No firewall rule has been added/changed.

Any other place I can check the logs or perhaps a parameter to check?

Источник

Http error 504 zimbra

Post by FredKarno » Sat Oct 10, 2015 5:50 am

I’ve just started migrating from Exchange 2007 to Zimbra 8.6 on CentOS 7.5 and I’ve run into this issue. All services are running, I can get to the admin page of the Web GUI just fine. I was working through the installation tasks and set up a test account then tried to access the webmail. The login screen appears just fine, but after logging in I get a long wait followed by the time out message below. I’ve tried the test account and my admin account — same result. I’ve disabled SELinux on the server and I’m stumped! This didn’t happen when I installed a test server with an evaluation license last year (Sadly, I’ve deleted that VM now).

Could anyone shed some light?

BTW, this is the licensed version.

HTTP ERROR 504

Problem accessing ZCS upstream server. Reason: Cannot connect to the ZCS upstream server. Connection timeout.
Possible reasons:

• upstream server is blocked by a firewall
• upstream server is failing to send back the response in time
• upstream server is down

Please contact your ZCS administrator to fix the problem.
Powered by Nginx-Zimbra://

New Install: Problem accessing ZCS upstream server.

Post by jorgedlcruz » Sat Oct 10, 2015 6:01 am

Did you manage to read the next article?

Did you install all services, proxy and memcached? Do you have all the DNS properly configured?

New Install: Problem accessing ZCS upstream server.

Post by FredKarno » Sat Oct 10, 2015 6:23 am

OK, thanks for the replies 🙂

I’m behind a firewall, but it shouldn’t be getting between me and the Zimbra server — we’re both on the same subnet.

DNS is being handled by a W2008 server which is running AD. I’ve set up a hairpin DNS on the firewall and local entries on the 08 server so mail.mydomain resolves fine.

I’m working through the article above, my hosts file looks off (I’ve already modified it to remove IPv6 because that caused another error) so I’ll check it out. I’m confused that the admin pages work but the webmail ones don’t, I had assumed (!) that they work on the same routes.

New Install: Problem accessing ZCS upstream server.

Post by FredKarno » Sat Oct 10, 2015 6:44 am

Here’s the Dig any for MyDomain. I’m not sure why Phat is advertising iSCSI connections, but hey.

There are two MX because I’ve still got the exchange server running. Is that likely to be a problem? I’m only using a single server install.

; > DiG 9.9.4-RedHat-9.9.4-18.el7_1.5 > MyDomain.co.uk any

;; global options: +cmd

;; ->>HEADER > DiG 9.9.4-RedHat-9.9.4-18.el7_1.5 > MyDomain.co.uk mx

;; global options: +cmd

New Install: Problem accessing ZCS upstream server.

Post by FredKarno » Sat Oct 10, 2015 7:27 am

No, I haven’t configured a split domain. I’m not looking to run both servers in parallel, but to migrate everyone from Exchange to Zimbra and then remove Exchange from the mx records and our mail routing (mail is routed via a spam scanning proxy anyway).

I haven’t migrated any accounts yet, I was just trying out the webmail interface before going any further.

I seem to have confused myself!

To answer two of your earlier questions:

Did I install the proxy service? I’m not sure. If it is installed as part of the install script then yes and there’s a service called proxy that is running on the server. If is is an extra module that needs separate attention, then no.

Did I install memcached ? same answer, I guess.

Here’s the status at the moment.

service webapp Running

zimbra webapp Running

zimbraAdmin webapp Running

zimlet webapp Running

New Install: Problem accessing ZCS upstream server.

Post by FredKarno » Sat Oct 10, 2015 12:28 pm

I think this has to do with authentication.

I’ve reverted to a snapshot of a plain, unconfigured Zimbra and the webmail client worked perfectly (tested with the default admin account). So I’m confident that DNS etc is set up properly.

I worked my way through the tasks again, and checked the webclient at each stage. The webmail worked perfectly until I logged out and tried to log in again. If you log in with a shortcut direct to your inbox, fine. If you logout and return to the login screen, you can’t log in again. (same error as before).

At least I managed to migrate a user account from Exchange, that worked OK — if slowly. Shame I can’t see what the data looks like in Zimbra! 🙂

Stuck now, I need to find out how authentication is breaking or it will just do it again. I’ve got External AD configured and that tests OK. I notice that the migration wizard didn’t associate the account I migrated with its AD account for authentication. I’ve put the user name in the External Authentication/External LDAP account for Authentication: box — no joy atm.

Any replies appreciated! (Including, how do I activate my Premium Support at the weekend? the phones were dead all day).

Источник

With our Zimbra/8.8.15_GA webmail randomly get non responsive while trying to send email. We were getting the below error with webmail. This has been happening once in every two weeks now. When the issue is there all webmail users will have the same problem while trying to send. We have to force restart the service and everything is back normal. Our system is production one and we have 80 email users in the system. This issue has become really annoying now. Zimbra is running on ec2 instance with 2 core 16GB ram CentOS Linux release 8.5.2111. I have checked the logs in detail and below are my findings. Has some one here faced the same issue? Can some one help me to resolve the case?

A network service error has occurred.
method: SendMsgRequest
msg: A network service error has occurred.
code: CSFE_SVC_ERROR
detail: HTTP response status 504

I have checked the zimbra logs in detail and i could see the below information in /opt/zimbra/log/mailbox.log

Иногда при посещении отдельных страниц сайта мы сталкиваемся с тем, что на экране вместо желаемого контента появляется сообщение об ошибке с цифровым кодом. Для «непосвященного» пользователя это просто набор цифр, но на самом деле в этих цифрах заложена определенная информация. Все они группируются по видам причин возникновения сбоя. 

Сообщения, кодирующиеся в формате 5хх, говорят о проблеме на стороне сервера, например, когда невозможно выполнить запрос из-за нарушения связи между несколькими серверами. Ошибка 504 Gateway Time Out не является распространенной, но это не значит, что на нее не стоит обращать внимания, особенно владельцу сайта. Рассмотрим некоторые причины возникновения данной ошибки и способы ее устранения как на стороне обычного посетителя, так и администратором веб-ресурса.

Ошибка 504 Gateway Time Out – это код состояния HTTP, который появляется, когда в течение заданного периода времени один сервер не получает своевременный ответ от другого сервера, который действует как шлюз или прокси.

Описания ошибки могут иметь различную форму:

• 504 Gateway Timeout nginx
• Gateway Timeout Error
• HTTP Error 504
• 504 Gateway Time-out – The server didn’t respond in time
• HTTP Error 504 – Gateway Timeout

Наличие дополнительного словесного описания помогает конкретизировать причину возникновения сбоя. 

Что делать посетителю сайта при возникновении ошибки 504 

Итак, вы столкнулись с появлением на экране сообщения «error 504». Не спешите уходить с сайта, ведь возникновение сбоя может говорить о неправильной работе вашего браузера или даже наличии более серьезных проблем на уровне пользовательского софта. Попробуйте произвести довольно простые действия, чтобы убедиться, что с вашим программным обеспечением и настройками все в порядке. 

1. Перезагрузите проблемную страницу или текущий браузер. Если проблема устранилась и не повторяется вновь, особенно при посещении других сайтов, о ней можно просто забыть. При регулярном возникновении однотипных ошибок во время посещения разных ресурсов стоит покопаться в настройках собственного ПО поглубже.
2. Зайдите на тот же самый сайт, где возникла ошибка сервера 504, используя альтернативный браузер. В случае, когда страница во время тестирования открылась корректно, обновите браузер, в котором случился сбой, до последней версии.
3. Проверьте, как открываются страницы этого же сайта с другого компьютера или смартфона. Это позволит вам понять, не связано ли появление ошибки 504 с ПО конкретного устройства.
4. При регулярном появлении HTTP ошибок, в т.ч. с кодом 504, очистите кэш браузера, удалите файлы cookies. Со временем в любом браузере накапливается много «мусора». Произведя очистку, вы поможете программе работать более корректно и даже быстрее.
5. Произведите сброс настроек роутера или модема, отключив оборудование на некоторое время от сети. Данная операция вряд ли приведет к устранению ошибки 504, но может улучшить качество интернет-соединения. Провайдеры регулярно вносят изменения в настройки собственного софта, обновляют его. Иногда это приводит к конфликту в корректном взаимодействии пользовательского оборудования и серверов оператора. Перезагрузка устройства по питанию в большинстве случаев решает такие проблемы.
6. Очистите кэш DNS. Данная операция кажется сложной для обычного пользователя, но на деле выполнить ее достаточно легко. Способ очистки зависит от вашей операционной системы, найдите соответствующий мануал в интернете.
7. Для опытных пользователей подойдет рекомендация временно переключить DNS-сервер на Google Public DNS, что как минимум поможет определить, возник ли ошибочный код состояния HTTP по причине DNS проблемы. 

Если после проведения всех вышеозначенных рекомендаций любая ошибка, в т.ч. 504 Gateway Time Out, продолжает возникать регулярно, обратитесь в техподдержку проблемного интернет-ресурса. 

Решение проблем с появлением ошибки сервера 504 администратором веб-ресурса 

Некорректная работа сайта чаще всего просто раздражает посетителя и приводит к тому, что пользователь находит альтернативный ресурс. Для владельца сайта такие сбои могут носить более глобальные последствия. Поэтому очень важно своевременно обнаруживать баги и максимально быстро устранять их. Для раннего мониторинга стоит использовать все возможные инструменты: 

• проводить регулярную симуляцию пользовательского поведения на сайте;
• настроить автоматизированный мониторинг работоспособности ресурса как встроенными инструментами администрирования, так и с использованием специальных скриптов;
• обеспечить качественную работу службы технической поддержки сайта, своевременную обработку всех поступающих сообщений, особенно связанных с информацией о появлении разного рода ошибок на стороне пользователя. 

Соблюдение последнего правила не только позволит практически без дополнительных затрат отслеживать все возможные проблемы, которые возникают при посещении сайта. Своевременная обработка пользовательских запросов, быстрый ответ, выдача рекомендаций и публичное обсуждение повышают лояльность и создают дополнительный PR-эффект.

Почти все ошибки с кодом 5хх, возникающие из-за невозможности обработки определенного количества запросов, поступающих на сервер, решаются методом апгрейда железа (использованием высокопроизводительного хостинга) либо оптимизацией работы программного обеспечения. Второй способ зависит от вида движка, на котором создан конкретный сайт. При использовании условно-бесплатных программ (WordPress, OpeneCart и других) все проблемы придется решать на уровне администрирования, с привлечением конкретного веб-программиста, разработавшего данный сайт. Если баги возникают на платных платформах (1С-Битрикс, UMI.CMS, NetCat CMS), напишите об ошибке 504 Gateway Time Out в техподдержку разработчика. Отправить сообщение о проблеме следует и разработчикам платных скриптов, если они установлены на вашем сайте, и вы считаете, что сбои возникают по причине их некорректного исполнения. 

Вот некоторые причины, приводящие к возникновению ошибки 504 Gateway Time Out

• Резкий скачок нагрузки на сайт вследствие поступления большого количества внешних запросов, вызванного DDoS-атаками или действиями вирусного ПО, пиковым посещением сайта, например, в момент проведения различных акций в интернет-магазине, или единовременной загрузкой на сайт большого объема контента (импорт информации из CSV- или XML-файлов).
• Некорректная работа скриптов, плагинов и дополнений, конфликтующих как между собой, так и внутри.
• Превышение лимита доступных ресурсов при использовании виртуального хостинга.

Еще одна возможная причина возникновения ошибки 504 – исполняемый скрипт не укладывается в отведенный лимит времени. Это бывает, когда скрипт обращается к другим сайтам либо просто выполняет тяжелую операцию, например, строит поисковый индекс.

Рекомендации по устранению ошибки 504 Gateway Time Out методами администрирования сайта

Ошибка 504 Gateway Time Out может быть вызвана недавними изменениями или обновлениями на сайте. Если после отката к состоянию, предшествующему изменениям, баг исчез, следует найти конкретное действие, повлекшее возникновение ошибки. Для этого необходимо проверить журнал ошибок соответствующей CMS. Пользователи WordPress могут включить журналирование ошибок в файле wp-config.php добавлением следующих строк: 

define( 'wp_debug', true );

define( 'wp_debug_log', true );

define( 'wp_debug_display', false )

Все возникающие варианты ошибок будут записаны в файле wp-contents/debug.log.

Для проверки работоспособности плагинов и расширений попробуйте отключить те, которые вызывают подозрение как источники возникновения ошибки 504. В первую очередь это касается устаревших скриптов, но причиной могут оказаться и обновления. Если проблема исчезла, далее следует найти некорректный плагин или дополнение и устранить или исправить его. Один из способов улучшения работы исполняемого скрипта – увеличить значение параметра PHP max_execution_time или облегчить скрипт.

При использовании CDN для более быстрого получения контента, в частности CloudFlare, который работает как CDN и как сервис предотвращения негативных последствий от DDoS, вы можете столкнуться с двумя типами ошибок 504. В случае возникновения проблемы на стороне CloudFlare лучшим решением будет связаться с поддержкой CloudFlare или отключить его. Второй вариант – когда сбой возникает на стороне хостинг-провайдера. В этой ситуации также необходимо обратиться в службу поддержки хостера.

Часто ошибку 504 можно видеть на серверах, где используется VPS-хостинг и установлен Nginx в качестве фронтенда и Apache в качестве бэкенда. Для устранения проблемы в Apache можно увеличить значение timeout по умолчанию в файле httpd.conf:

# Timeout: The number of seconds before receives and sends time out.

Timeout 600

Также увеличить лимит в max_execution_time в php.ini: 

После внесения изменений следует перезапустить Apache. Ошибка 504 Gateway Time Out должна исчезнуть.

Аналогичным образом проблема с появлением ошибки HTTP 504 решается пользователями Nginx. Попробуйте увеличить такие параметры в файле /etc/nginx/conf.d/timeout.conf:

proxy_connect_timeout 600;

proxy_send_timeout 600;

proxy_read_timeout 600;

send_timeout 600;

Также рекомендуется увеличить max_execution_time в php.ini:

Далее перезапустите Nginx и откройте сайт. 

И далее внести соответствующие изменения.

Аналогичным способом проблема устраняется и при использовании альтернативных панелей управления хостингом – Ajenti, CentOS Web Panel, ISPmanager и других.

Если вы считаете, что появление 504 Gateway Timeout вызвано превышением лимита использования ресурсов серверного железа, оптимальным решением будет аренда выделенного сервера или VPS. Когда ваш сайт уже размещен на виртуальном хостинге, но ни одна из рекомендаций не привела к исправлению error 504, обратитесь к хостинг-провайдеру. В этом случае подробно опишите причины, которые, как вы полагаете, привели к появлению сбоя.

Заключение

В данной статье мы рассмотрели основные причины возникновения ошибки HTTP 504 Gateway Timeout и популярные способы устранения неполадки. Уверен, некоторые администраторы веб-ресурсов сталкивались с подобными проблемами, выходящими за рамки приведенных примеров и рекомендаций.

Буду благодарен, если вы поделитесь своим опытом в комментариях.

0. Используемые порты. Zimbra активно использует различные сетевые порты как для внешних, так и для внутрисистемных подключений. Именно поэтому наиболее оптимальным для нее станет создание так называемого «Белого списка» в правилах брандмауэра. То есть администратор сперва запрещает любые подключения к каким-либо портам на сервере, а затем открывает лишь те, которые необходимы для нормальной работы сервера. И именно на этом этапе администратор сервера Zimbra неизменно сталкивается с вопросом о том, какие порты следует открыть, а какие лучше всего не трогать. Давайте посмотрим, какие порты и для чего использует Zimbra, чтобы вам было проще принимать решение о составлении собственного «белого списка» в брандмауэре.

Для внешних подключений Zimbra может использовать до 12 портов, среди которых:

25 Порт для входящей почты в postfix
80 Порт для незащищенного подключения к веб-клиенту Zimbra
110 Порт для получения почты с удалённого сервера по протоколу POP3
143 Порт для доступа к электронной почте по протоколу IMAP
443 Порт для защищенного подключения к веб-клиенту Zimbra
587 Порт для входящей почты с защитой соединения
993 Порт для защищенного доступа к электронной почте по протоколу IMAP
995 Порт для защищенного получения почты с удалённого сервера по протоколу POP3
5222 Порт для подключения к серверу по протоколу XMPP
5223 Порт для защищенного подключения к серверу по протоколу XMPP
9071 Порт для защищенного подключения к администраторской консоли

Как уже было упомянуто, помимо внешних подключений, в Zimbra Collaboration Suite осуществляется и масса внутренних подключений, которые также происходят на различных портах. Поэтому при включении таких портов в «белый список» стоит следить за тем, чтобы возможность подключения к ним была только у локальных пользователей.

389 Порт для незащищенного подключения к LDAP
636 Порт для защищенного подключения к LDAP
3310 Порт для подключения к антивирусу ClamAV
5269 Порт для общения между серверами, находящимися в одном кластере по протоколу XMPP
7025 Порт для локального обмена почтой по протоколу LMTP
7047 Порт, используемый сервером для конвертирования вложений
7071 Порт для защищенного доступа к администраторской консоли
7072 Порт для обнаружения и аутентификации в nginx
7073 Порт для обнаружения и аутентификации в SASL
7110 Порт для доступа к внутренним службам POP3
7143 Порт для доступа к внутренним службам IMAP
7171 Порт для доступа к демону конфигурации Zimbra zmconfigd
7306 Порт для доступа к MySQL
7780 Порт для доступа к службе проверки правописания
7993 Порт для защищенного доступа к внутренним службам IMAP
7995 Порт для защищенного доступа к внутренним службам POP3
8080 Порт для доступа к внутренним службам HTTP
8443 Порт для доступа к внутренним службам HTTPS
8735 Порт для общения между почтовыми ящиками
8736 Порт для доступа к службе распределенной настройки Zextras
10024 Порт для общения Amavis с Postfix
10025 Порт для общения Amavis с OpenDKIM
10026 Порт для настройки политик Amavis
10028 Порт для общения Amavis с фильтром контента
10029 Порт для доступа к архивам Postfix
10032 Порт для общения Amavis со спам-фильтром SpamAssassin
23232 Порт для доступа к внутренним службам Amavis
23233 Порт для доступа к snmp-responder
11211 Порт для доступа к memcached

Отметим, что если в случае, когда Zimbra работает только на одном сервере, можно обойтись минимальным набором открытых портов. Но если на вашем предприятии Zimbra установлена на несколько серверов, то вам придется открыть 14 портов с номерами 25, 80, 110, 143, 443, 465, 587, 993, 995, 3443, 5222, 5223, 7071, 9071. Такой набор открытых для подключения портов обеспечит нормальное взаимодействие между серверами. При этом администратору Zimbra всегда необходимо помнить, что, к примеру, открытый порт для доступа к LDAP, является серьезной угрозой для информационной безопасности предприятия.

Часть поста: https://habr.com/company/zimbra/blog/427729/

1. Веб-интерфейс, вход. По умолчанию вход через веб-интерфейс по https. Регуляция данного обстоятельства:

zmtlsctl [mode]

где mode = <http, https, both, mixed, redirect>

Однако штатный proxy, который теперь (с версии 8.6, по-моему) обязателен к применению, имеет собственное мнение на этот счёт. Вот его комментарий на команду zmtlsctl redirect в свежеустановленной Zimbre:

Error: When zimbraReverseProxyMailMode (on the proxy server) is https, the only valid settings for zimbraMailMode are both or https.

2. Нет доставки внешней почты. После установки и настройки всего и вся, у меня никак не хотела доставляться внешняя почта, лечится так:

sudo su zimbra
zmlocalconfig -e postfix_lmtp_host_lookup=native
zmprov ms domain.com zimbraMtaLmtpHostLookup native
zmmtactl restart

Источник: http://wiki.zimbra.com/wiki/Incoming_Mail_Problems

3. Веб-интерфейс, «ошибка сети». После увеличения количества пользователей Zimbra появились жалобы, что при входе в веб интерфейс появляется «Ошибка сети». Эта проблема связана с работой встроенного в Zimbra 8.0 и старше метода защиты от DoS

Пользователи начали жаловаться, что периодически при попытке входа возникает «Ошибка сети». Анализ логов выявил следующее сообщение:

2016-04-12 09:22:30,489 INFO [qtp509886383-3765:http://127.0.0.1:80/service/soap/AuthRequest] [] misc — Access to IP 1.2.3.4 suspended, for repeated failed login.

Выяснилось, что это срабатывает встроенная, начиная с версии 8.0 защита от DoS. Настройка осуществляется с помощью нескольких параметров:

    zimbraHttpDosFilterDelayMillis — задержка, которая применяется ко всем запросам выше лимита, прежде чем они будут рассмотрены. В миллисекундах. Возможны варианты в виде значения от -1,0,1 и более. Где -1 — отклонять запросы сразу. 0 — не выставлять задержку, 1 и более — задержка в мс. По-умолчанию -1.
    zimbraHttpDosFilterMaxRequestsPerSec — Лимит количества запросов в секунду. По-умолчснию 30
    zimbraHttpThrottleSafeIPs — белый список IP, с которых запросы не проверяются на их количество.

Решение проблемы кроется в подкручивании этих ручек до комфортных значений и последующего перезапуска mailbox сервиса (zmmailboxdctl restart)

Однако, есть нюансы, если у Вас так называемая «Multi server» кофигурация, то есть несколько mailbox серверов за proxy.

Что бы все это дело работало, необходимо для начала сделать так, что бы mailbox знали о реальных IP, с которых приходят запросы. По-умолчанию в логах отображается IP proxy.
Это, конечно, логично, но пока я обратил внимание на IP адрес запроса в логах чуть крутилку DoS фильтра не сломал…

Для этого проверяю текущее значение параметра zimbraMailTrustedIP:
$ zmprov gcf zimbraMailTrustedIP
Добавляю IP zimbra-proxy
$ zmprov mcf +zimbraMailTrustedIP 10.202.1.31
выполняю на всех mailbox серверах:
$ zmmailboxdctl restart

После этого в логах будут реальные IP и политики DoS будут применяться к ним и все будет работать как задумано

4. Добавление адресной книги руками. Если вы ходите принудительно добавить пользователям GAL книгу, то можно воспользоваться следующим скриптом:

#!/bin/bash

zmprov -l gaa| while read USER; do zmmailbox -z -m $USER cm —view contact -F# «/Адресная книга предприятия» galsync@yourdomain.com /_zimbra; done

где galsync@yourdomain.com аккаунт синхронизации, /_zimbra — имя раcшариваемой адресной книги.

https://habr.com/post/134981/   Комментарий JStingo

5. Защита порта memcached. Особое внимание следует уделить внимание порту 11211, на котором работает memcached. Именно он задействован в популярной разновидности кибератак memcrashd. Fix для standalone-server:

su — zimbra
 /opt/zimbra/bin/zmprov ms `zmhostname` zimbraMemcachedBindAddress 127.0.0.1
 /opt/zimbra/bin/zmprov ms `zmhostname` zimbraMemcachedClientServerList 127.0.0.1

Инструкция здесь: https://wiki.zimbra.com/wiki/Blocking_Memcached_Attack

6. Блок определённого адреса. Заблокировать получение писем от определённого адреса — несложно.
Есть три пути:
1) блокировать в настройках postfix (Zimbra основана на postfix)
2) блокировать в настройках spamassasin (Zimbra использует Spamassasin если включен антиспам)
3) блокировать в настройках конкретного пользователя (создать фильтр, зайдя пользователем в веб-интерфейс)

Путь №1 самый радикальный:
### команды нужно выполнять из пользователя zimbra
su — zimbra

### создадим файл если его нет, или добавим строчку
echo «baduser@domain.com REJECT» >> /opt/zimbra/conf/postfix_reject_sender
postmap /opt/zimbra/conf/postfix_reject_sender

### добавим в настройки Zimbra Postfix проверку smtpd_sender_restrictions
zmprov ms $(hostname) zimbraMtaSmtpdSenderRestrictions «check_sender_access lmdb:/opt/zimbra/conf/postfix_reject_sender»

### можем подождать 1-2 минуты, пока zmconfigd применит настройку, либо перезапустить Postfix
zmmtactl restart

Источник: https://toster.ru/q/556845?utm_source=tm_habrahabr&utm_medium=tm_block&utm_campaign=questions_post

7. Запрет доставки наружу/снаружи