This is really simple. You can just follow the instructions on the Installation page again, but DON'T RUN--makeconf. Your configuration won't be deleted. If you'd like to make a backup before, however, you can backup ZNC's config folder. It is usually located at ~/.znc. You can use tar to make a backup, like this: tar cfvj znc-backup.tar.gz ~/.znc.

Your existing configuration will be upgraded to new version when you start it. If new ZNC will complain about few missing modules, you may need to remove them from znc.conf. That can happen if some modules which were loaded to your ZNC are removed in new version. See ChangeLog for details.

ZNC is like any other software, it has bugs and security issues that are fixed in new versions and also gets improvements. By not upgrading you risk all kinds of security issues, don't trust your distribution to patch old releases as ZNC's code has changed so much that it's often impossible to apply patch from newer version to older version.

For reasons to upgrade, take a look at ChangeLogs starting from the next version to what you are currently running to the newest version.

Starting from ZNC 1.6.0 there have been two branches, e.g. 1.6.x gets only bug/security fixes and later becomes 1.6.1 which distributions can package as bugfix release.

These are only the main points and might not be up-to-date when new versions are released. It's also entirely possible that there are security issues that haven't been found yet, but are fixed in newer versions.

I've installed znc, but when i try to compile modules it says that there is no command znc-buildmod[edit]

Why do I get an "Incorrect Password" every time I connect even though my pass is correct?[edit]

There're few ways to supply password:

If you have decent IRC client, you can just use "username" (or "ident") field for username, optional client identifier and network (for example User@phone/freenode) and "server password" field for password.

You can supply all four in the password field like "user@phone/network:pass" (without quotes)

Just do "/quote pass PA$$WORD" manually every time you connect to ZNC

Also, make sure you did not accidentally load one of the cyrusauth or imapauth modules.

Avoid using special character : in your password, as this can cause errors when trying to parse the password field to look for username, client, network, and password (user@client/network:pass). If the password has : in it, everything before first : is considered to be username (also network and client), and the username sent in the normal way is ignored.

@client-identifier was added with 1.6.0 and is entirely optional. It's used by modules such as chanfilter or clientbuffer.

How can I restart ZNC automatically (in case of a machine reboot, crash, etc.)?[edit]

If you installed ZNC using your distribution's package manager, it may have came with a set of scripts or configuration files for the distribution's init system. For systemd, run:

sudo systemctl enable znc.service

(Note that this does not work on the packages in the repositories of Debian; those do not include an init script)

If you installed ZNC manually (from a tarball), you can add a cron entry to execute ZNC regularly. If there is already one copy of ZNC running on a particular config file, new copies won't be spawned. Example cron entry:

*/10 * * * * /usr/local/bin/znc >/dev/null 2>&1

This will check if ZNC is running every 10 minutes. If you load a module (like awaystore) that needs user input to run, you can add the input to the LoadModule line in your config file (ie. LoadModule = awaystore yourpassword).

Of course, ZNC isn't magic. Like any other software, it doesn't run when you turn off or sleep your PC.

If you want to stay connected while your own device is off/sleeping, ZNC must be running on some other machine somewhere. That could be an always-on PC/server in your home, a remote server that you control, or a ZNC server run by someone else. If you were going to run it on your home PC—which you often power-off or sleep—consider getting a VPS or using a ZNC provider instead. That way you can stay connected even when your device is off or sleeping.

I added several different servers, but ZNC connects only to one of them![edit]

You need to have separate user per IRC network (see previous question).
(Note: since 0.207 it has been changed, user can have several networks now, see Networks)
Additional servers for the same user are for fallback.
If one server doesn't work, ZNC tries to connect to another server.
So you can add several servers of one network to server list of one user.

This happens if you use "many" channels, due to IRC clients flooding the server with commands upon reattach. A workaround is decreasing size of buffer for each channel. (You should experiment how many is enough.)

Enable Flood settings and/or set them to be less generous (by increasing their values). Disabling Flood settings may lead to some cases where you are simply sending too much information to the server. This can be done via the Web Panel

Every time I connect to my BNC, I see the channel buffers from the last time I connected![edit]

If you have a large channel buffer, it may be annoying to see the channel buffer every time you reconnect. To have ZNC erase the channel buffer every time you connect, set AutoClear Chan Buffer and AutoClear Query Buffer to true using either the webadmin or controlpanel module.

This will result in only the missed messages being played back to you upon reconnecting. Be careful if you use more than one client as znc will still see you as connected when one drops off and messages will not be buffered. Also, if your connection to znc dies unnaturally, znc might take a little bit to realize you're gone and thus not buffer a few of the messages that you haven't yet seen. The external playback module can help with this if your client supports it.

If AutoClear Chan Buffer and AutoClear Query Buffer (commonly referred as AutoClear*Buffer) are true, ZNC clears the buffers after they have been sent to client. This has some drawbacks such as sometimes the messages getting lost when client has lost network connection or another client not receiving messages, because one was already running and clearing buffers.

̈́VHOSTS were renamed into BINDHOSTs very long time ago, if you still see it in your ZNC, upgrade immediately!

ZNC bindhost option controls the IP address ZNC will attempt to make connections to the IRC servers from. For this to be successful the computer you're running ZNC on must have this IP address configured and usable for your user. For it to show up as a host name on IRC there must be matching forward and reverse DNS in place. You can check this with:

If you find you are unable to connect to IRC after attempting to set bindhost options then it is likely you have set an IP address or host name that is not available on your computer. The easiest way to resolve this and get connected to IRC is to

/msg *status ClearUserBindhost

and try to connect again.

To get rid of several misunderstandings vhost was renamed to bindhost since version 0.096.

I get 'Could not find znc-config. Please (re)install' when using znc-buildmod[edit]

I keep getting a lot of stuff like /who replies when connected with multiple clients to one znc-user[edit]

By default webadmin runs on the same PORT as your ZNC is accessible. So if you connect your IRC client to ZNC with server example.com and port 6667, then you would access webadmin by opening your web browser and going to the address http://example.com:6667.

If ZNC listens using SSL, use the HTTPS protocol (https://) instead of just HTTP (http://). If your web interface won't come up, please ensure that you are using the correct protocol for connecting.

Examples

Plaintext port on IPv4 localhost: http://127.0.0.1:8080

SSL port on IPv6 localhost: https://[::1]:8081

Note: Using a well-known port such as 6667 may lead to issues in some browsers, which block accessing websites over a port that is usually associated with a non-website service. It's recommended to run ZNC on a custom port (not 6667/6697), or add a custom webadmin port—but you can also often work around this in the browser.

If you are using Google Chrome and keep getting an Error 312 (net::ERR_UNSAFE_PORT), then try calling Chrome with the parameter --explicitly-allowed-ports=<ZNC's port>.

If you are using Mozilla Firefox and keep getting the error This address is restricted, visit about:config and edit or create the setting network.security.ports.banned.override with a comma-separated list of ports over which ZNC's webadmin can be accessed—for example, 6667,6697.

The best way is NOT to change znc.conf and other files manually while ZNC is running.
Use webadmin or controlpanel instead, or use /msg *status help

If you really need to do something in znc.conf, stop ZNC, make your changes and start it again.

If you really need to rehash config from file without restart, there're 2 ways to do that: from IRC (/msg *status rehash)
and from shell (pkill -SIGHUP znc). But don't complain if something is broken (because it will be broken for sure)

Socket error 10053 can be caused by attempting to connect without SSL to a znc bouncer with SSL enabled (or vice versa). Refer to your IRC-client's documentation on how to establish a SSL-secured connection to a server.

How to store private messages even when user is attached, so other clients can see them?[edit]

When you supply your username to ZNC in your client, you can include the network as `username/network`. If you send your username in the server password field you can use `username/network:password`.

There needs to be one connection between the client and the ZNC if you wish to connect to multiple networks at the same time.

As every IRC client is slightly different, please consult the documentation for your IRC client on where to put the server password, or if you wish to configure autoconnect when the IRC client starts.

Examples for mIRC, irssi, and HexChat:

Note: Where 1.2.3.4 is an IP your ZNC instance is listening on, 7777 and 7778 are the port numbers the listeners are using, ZNCUser is the name of the ZNC user account, and PassWord is the password. In these examples, the second line uses SSL whereas the first one does not.

Note: The network name is arbitrarily defined when setting it up in ZNC, though many users will use the name of the actual network for clarity.

No, ZNC doesn't use stupid tags for networks, which mix up different channels and nick together to one big network with prefixes.
Instead, you should connect to ZNC multiple times, once for each network, see previous question on how to do that.
Also you may switch between networks on the fly via /msg *status JumpNetwork command.

If ZNC ever supports connecting to all networks together, it will be done properly, without those prefixes, but via an IRC protocol extension instead.
Also that extension should be standardized at IRCv3, to allow client developers to support it easier.

This question is very difficult to answer because it depends highly on how much you use it. However, personal ZNC instances, where you are the only user, are unlikely to require a great deal of memory to run.

In an effort to give a better idea of how much memory ZNC may use in different situations, a page with anecdotal reports from users has been added. It may be found here: ZNC Memory Usage

Your ZNC password is hashed in the config file as ZNC doesn't have to know your password, because when you login your password is hashed and compared to the hash in the config file. ZNC cannot do hashing or anything else to other passwords without losing ability to use them.

In theory storing passwords encrypted some way would be possible, but that would require password inputting during ZNC startup preventing starting ZNC automatically and your passwords would still be readable from memory.

If you are using a provider and do not trust them with your credentials, seek a different provider or host ZNC yourself.

Note also that cert isn't any more secure then password if you don't trust the provider. Malicious provider can use it to identify as you and do everything as you including changing your password.

The exact answer is impossible, other than check znc -D for what happens. Most likely there was connection issue between ZNC and the server.

Keepnick should always take your primary nick when it becomes free. Alternatively if you want to get your primary nick on connect you can configure SASL and set perform to regain your nick (with Atheme IRC services) /msg *perform add NICKSERV REGAIN %defnick%.

The primary reason ZNC exists is to keep you connected to IRC while your client is disconnected. However, some people have found other uses for ZNC and want it to disconnect or even shut down when their IRC client isn't connected.

You can use the external modulesimple_disconnect to cause ZNC to disconnect from the IRC server when your client quits. If, for whatever reason, ZNC doesn't connect to the IRC network the next time you connect your IRC client to ZNC, simply issue the command /znc connect to manually initiate the connection between ZNC and the IRC network.

You probably just want to disconnect ZNC rather than shut it down (see previous section). You can make ZNC quit when you disconnect, but you will then need to access the host machine (via physical access or SSH) and restart ZNC to connect your IRC client to ZNC again; obviously you can't connect your client to ZNC if ZNC is not running.

You can use the external moduleantiperform to issue commands at the time your IRC client disconnects from ZNC. Add the antiperform command PRIVMSG *status :shutdown to quit ZNC upon disconnecting your IRC client from ZNC. To reconnect, you must first re-launch ZNC on the host machine (for example, ssh user@host.com 'znc') before connecting your IRC client to ZNC again.

Recursively backup/copy the ~/.znc directory (or appropriate alternate DATADIR directory, if it is not ~/.znc) to the new machine, and recursively chown (chown -R newuser:newgroup ~/.znc) the new directory if needed. You will also need to recompile any third-party modules located in ~/.znc/modules/, if you have any.

What are the different module load levels? (Global vs User vs Network)[edit]

Network modules are loaded on a per-network basis, meaning they only affect the network they are loaded on. *nickserv and *sasl are examples of network-level modules; they need to be loaded on each network, and do not affect other networks.

User modules affect the ZNC user they are loaded on, as well as all networks for that user. They do not affect other users or other networks for other users.

Global modules affect the entire ZNC instance, which includes all users and all networks for those users.

Some modules can be loaded at more than one level, so it's important to note for which level you are loading a module. For example, *perform can be loaded at both the user and network level. If it is loaded at the user level, it will affect all networks for that user identically, which may cause problems as not all networks behave the same way, and you may not want to perform the same actions on all networks for that user.

Another good example of a multiple-level module is *log. *log can be loaded at all three levels, global, user, and network. Loading *log for a single network will log only that network. Loading *log for a user will log all networks for that user. Loading *log globally will log all networks for all users. NOTE: Be careful of loading the *log module at more than one level, because you will be wasting disk space by saving duplicate logs.