Scenario
You run sudo dnf upgrade --refresh and the terminal hangs. The browser loads pages fine, but the package manager refuses to connect. Or maybe you just joined a corporate network and every command-line tool throws a connection error while Firefox works perfectly. The network is up, the cable is plugged in, but something is blocking the traffic. You need a proxy, and Fedora does not have a single magic switch to turn it on everywhere.
How proxy configuration works on Fedora
Linux applications do not share a single proxy configuration. The desktop environment, the package manager, and command-line tools all look for proxy settings in different places. GNOME reads its own settings database. dnf reads a configuration file. curl and wget look for environment variables. If you set the proxy in one place, the others stay blind.
This fragmentation exists because Linux tools are designed to be independent. A server running headless has no desktop settings. A script running as root should not inherit a user's desktop preferences. You have to configure the proxy at the layer that matters for your use case.
Fedora follows the standard Linux convention for configuration files. User modifications belong in /etc/. Files in /usr/lib/ ship with packages and get overwritten on updates. Edits in /etc/ persist across upgrades. Always edit the files in /etc/.
Configure system-wide environment variables
Environment variables are the most reliable way to configure proxies for command-line tools, scripts, and headless servers. Setting variables in /etc/environment applies them to all users and most applications after login.
This command appends the proxy variables to the system environment file. The tee command writes the output to the file while sudo provides the necessary permissions. The heredoc syntax with single quotes around EOF prevents the shell from expanding variables inside the block.
# Append proxy variables to the system environment file.
# This affects all users and most CLI tools after login.
# Uppercase and lowercase variants cover tools that check either convention.
sudo tee -a /etc/environment <<'EOF'
HTTP_PROXY=http://proxy.example.com:8080
HTTPS_PROXY=http://proxy.example.com:8080
NO_PROXY=localhost,127.0.0.1,::1,.internal.example.com
http_proxy=http://proxy.example.com:8080
https_proxy=http://proxy.example.com:8080
no_proxy=localhost,127.0.0.1,::1,.internal.example.com
EOF
Some tools check uppercase variables like HTTP_PROXY, while others check lowercase like http_proxy. Setting both variants prevents surprises. The NO_PROXY variable is critical. It tells tools to bypass the proxy for local addresses. Without localhost and 127.0.0.1 in the list, tools trying to talk to local services will route through the proxy and fail. Use a leading dot for domain suffixes to match subdomains.
sudo runs with a clean environment by default for security. The PAM system loads /etc/environment during authentication, so system variables usually survive sudo. User variables in ~/.bashrc do not. This is why root tools fail when you only set the proxy in your shell profile.
Log out and back in. Environment variables apply to new sessions, not running processes.
Configure per-user shell settings
Use the shell profile when you need the proxy only for your user session, or when you are testing a configuration before making it permanent. Adding variables to ~/.bashrc or ~/.profile exports them for your shell and child processes.
This snippet adds the proxy variables to your shell configuration. The export command makes the variables available to programs started from the shell.
# Add to ~/.bashrc or ~/.profile for current user only.
# This runs every time you open a new terminal.
export HTTP_PROXY=http://proxy.example.com:8080
export HTTPS_PROXY=http://proxy.example.com:8080
export NO_PROXY=localhost,127.0.0.1
Apply the changes to the current session without logging out. This is useful for quick testing.
# Reload the shell configuration to apply variables immediately.
source ~/.bashrc
Use the shell profile for temporary testing. Move to /etc/environment when the configuration becomes permanent.
Configure dnf for package management
dnf has its own configuration file and does not rely on environment variables for repository connections. Configuring the proxy in dnf.conf is the safest method for package management, especially when the proxy requires authentication.
Edit the main configuration file and add the proxy settings. dnf reads this file for all repository operations.
# Add to the bottom of /etc/dnf/dnf.conf
# DNF reads this file for repository connections.
proxy=http://proxy.example.com:8080
# Uncomment and set if the proxy requires credentials.
# proxy_username=myuser
# proxy_password=mypassword
Passwords in environment variables can break when they contain special characters like & or #. The configuration file handles these characters correctly. Storing credentials in /etc/dnf/dnf.conf is standard practice. The file is readable only by root, which matches the security model of the package manager.
Edit /etc/dnf/dnf.conf for package management. DNF ignores desktop settings and environment variables can break with special characters in passwords.
Configure GNOME desktop applications
GUI applications and the desktop environment use GNOME's proxy settings. This configuration affects GTK applications and integrates with browsers that respect system proxy settings.
These commands set the proxy mode to manual and define the host and port. The gsettings tool modifies the GNOME configuration database from the command line.
# Set GNOME to manual proxy mode.
# This affects GTK applications and the browser integration.
gsettings set org.gnome.system.proxy mode 'manual'
gsettings set org.gnome.system.proxy.http host 'proxy.example.com'
gsettings set org.gnome.system.proxy.http port 8080
gsettings set org.gnome.system.proxy.https host 'proxy.example.com'
gsettings set org.gnome.system.proxy.https port 8080
Some browsers like Firefox and Chrome have their own network settings that override GNOME. Check the browser preferences if the desktop proxy is set but the browser still fails to connect. The GNOME proxy settings do not apply to terminal tools or root sessions.
Run gsettings commands to fix GUI applications. The desktop proxy does not fix the terminal.
Configure NetworkManager with PAC files
Corporate networks often provide a Proxy Auto-Config (PAC) file that defines proxy rules dynamically. NetworkManager can read these files and propagate the settings to GNOME and compatible tools.
This command modifies the active connection profile to use automatic proxy configuration. Replace the connection name with your actual connection identifier.
# Configure NetworkManager to use a PAC file for the active connection.
# This propagates settings to GNOME and some network tools.
nmcli connection modify "Wired connection 1" proxy.method auto \
proxy.pac-url http://wpad.example.com/proxy.pac
NetworkManager applies PAC settings to the connection profile. When you reconnect, the settings take effect. This method is ideal for environments where the proxy address changes based on the network location.
Use PAC files when the network infrastructure dictates the proxy rules. Manual configuration drifts when the network changes.
Verify the configuration
Run a test command to confirm the proxy is active. The curl command with verbose output shows the connection details.
# Check if curl routes through the proxy.
# Look for "Connected to proxy.example.com" in the output.
curl -v https://fedoraproject.org 2>&1 | head -20
The output should contain a line indicating the connection to the proxy server. If you see Connected to proxy.example.com, the environment variables are working. If curl connects directly to the target server, the proxy configuration is missing or NO_PROXY is blocking the request.
Test dnf separately to ensure package management works.
# Verify dnf can reach repositories through the proxy.
# This checks repository metadata without downloading packages.
sudo dnf check-update
Verify with curl. If the output shows the proxy IP, the configuration is active.
Common pitfalls
The NO_PROXY variable must include localhost. Without it, tools trying to talk to local services will route through the proxy and fail. This breaks local development servers and internal metadata lookups.
DNF passwords with special characters break in environment variables. Use /etc/dnf/dnf.conf for credentials. The configuration file parser handles special characters correctly, while environment variables can misinterpret symbols.
GNOME proxy settings do not apply to root sessions or scripts. sudo drops the user environment by default. Configure /etc/environment or dnf.conf for root tools. Setting the proxy only in GNOME leaves the package manager blind.
Browser settings can override system proxy configuration. Firefox and Chrome maintain their own network preferences. Check the browser settings if the system proxy is configured but the browser fails to connect.
Choose the right method
Use /etc/environment when you need CLI tools and scripts to use the proxy for all users. Use ~/.bashrc when you are testing a proxy configuration temporarily for your user session. Use /etc/dnf/dnf.conf when the proxy requires authentication or you need to ensure package management works reliably. Use gsettings when GUI applications and the desktop browser need proxy access. Use nmcli with a PAC file when the network provides automatic proxy configuration. Stay on manual configuration when the proxy address is static and you control the machine.